Passa al contenuto principale

RFC 9026 - Multicast VPN Fast Upstream Failover

  • Stato: Proposed Standard
  • Pubblicato: April 2021
  • Stream: IETF
  • Errata: Nessun errata

Abstract​

This document defines Multicast Virtual Private Network (VPN) extensions and procedures that allow fast failover for upstream failures by allowing downstream Provider Edges (PEs) to consider the status of Provider-Tunnels (P-tunnels) when selecting the Upstream PE for a VPN multicast flow. The fast failover is enabled by using "Bidirectional Forwarding Detection (BFD) for Multipoint Networks" (RFC 8562) and the new BGP Attribute, BFD Discriminator. Also, this document introduces a new BGP Community, Standby PE, extending BGP Multicast VPN (MVPN) routing so that a C-multicast route can be advertised toward a Standby Upstream PE.

Questo documento definisce estensioni e procedure per la rete privata virtuale multicast (VPN) che consentono un failover rapido per guasti a monte consentendo ai Provider Edge (PE) a valle di considerare lo stato dei Provider-Tunnel (P-tunnel) quando si seleziona il PE a monte per un flusso multicast VPN. Il failover rapido è abilitato utilizzando "Bidirectional Forwarding Detection (BFD) for Multipoint Networks" (RFC 8562) e il nuovo attributo BGP, BFD Discriminator. Inoltre, questo documento introduce una nuova comunità BGP, Standby PE, estendendo il routing BGP Multicast VPN (MVPN) in modo che una route C-multicast possa essere pubblicizzata verso un PE a monte di standby (Standby Upstream PE).

Status of This Memo​

This is an Internet Standards Track document.

Questo è un documento Internet Standards Track.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Questo documento è un prodotto della Internet Engineering Task Force (IETF). Rappresenta il consenso della comunità IETF. Ha ricevuto una revisione pubblica ed è stato approvato per la pubblicazione dall'Internet Engineering Steering Group (IESG). Ulteriori informazioni sugli standard Internet sono disponibili nella Sezione 2 della RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9026.

Informazioni sullo stato attuale di questo documento, eventuali errori e come fornire feedback su di esso possono essere ottenute all'indirizzo https://www.rfc-editor.org/info/rfc9026.

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright (c) 2021 IETF Trust e le persone identificate come autori del documento. Tutti i diritti riservati.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Questo documento è soggetto alla BCP 78 e alle disposizioni legali dell'IETF Trust relative ai documenti IETF (https://trustee.ietf.org/license-info) in vigore alla data di pubblicazione di questo documento. Si prega di esaminare attentamente questi documenti, poiché descrivono i propri diritti e restrizioni in relazione a questo documento. I componenti di codice estratti da questo documento devono includere il testo della licenza BSD semplificata come descritto nella Sezione 4.e delle disposizioni legali del Trust e sono forniti senza garanzia come descritto nella licenza BSD semplificata.

Table of Contents​

    1. Introduction
    1. Conventions Used in This Document
    1. UMH Selection Based on Tunnel Status
    1. Standby C-Multicast Route
    1. Hot Root Standby
    1. Duplicate Packets
    1. IANA Considerations
    1. Security Considerations
    1. References
  • Acknowledgments
  • Contributors
  • Authors' Addresses

1. Introduction​

It is assumed that the reader is familiar with the workings of multicast MPLS/BGP IP VPNs as described in [RFC6513] and [RFC6514].

Si presume che il lettore abbia familiarità con il funzionamento delle VPN IP MPLS/BGP multicast come descritto in [RFC6513] e [RFC6514].

In the context of multicast in BGP/MPLS VPNs [RFC6513], it is desirable to provide mechanisms allowing fast recovery of connectivity on different types of failures. This document addresses failures of elements in the provider network that are upstream of PEs connected to VPN sites with receivers.

Nel contesto del multicast nelle VPN BGP/MPLS [RFC6513], è auspicabile fornire meccanismi che consentano un rapido ripristino della connettività su diversi tipi di guasti. Questo documento affronta i guasti degli elementi nella rete del provider che si trovano a monte dei PE collegati ai siti VPN con ricevitori.

Section 3 describes local procedures allowing an egress PE (a PE connected to a receiver site) to take into account the status of P-tunnels to determine the Upstream Multicast Hop (UMH) for a given (C-S,C-G). One of the optional methods uses [RFC8562] and the new BGP Attribute, BFD Discriminator. None of these methods provide a "fast failover" solution when used alone but can be used together with the mechanism described in Section 4 for a "fast failover" solution.

La Sezione 3 descrive le procedure locali che consentono a un PE di uscita (un PE collegato a un sito ricevitore) di prendere in considerazione lo stato dei P-tunnel per determinare l'Upstream Multicast Hop (UMH) per un dato (C-S,C-G). Uno dei metodi opzionali utilizza [RFC8562] e il nuovo attributo BGP, BFD Discriminator. Nessuno di questi metodi fornisce una soluzione di "failover rapido" se utilizzato da solo, ma può essere utilizzato insieme al meccanismo descritto nella Sezione 4 per una soluzione di "failover rapido".

Section 4 describes an optional BGP extension, a new Standby PE Community, that can speed up failover by not requiring any Multicast VPN (MVPN) routing message exchange at recovery time.

La Sezione 4 descrive un'estensione BGP opzionale, una nuova comunità Standby PE, che può accelerare il failover non richiedendo alcuno scambio di messaggi di routing Multicast VPN (MVPN) al momento del ripristino.

Section 5 describes a "hot root standby" mechanism that can be used to improve failover time in MVPN. The approach combines mechanisms defined in Sections 3 and 4 and has similarities with the solution described in [RFC7431] to improve failover times when PIM routing is used in a network given some topology and metric constraints.

La Sezione 5 descrive un meccanismo "hot root standby" che può essere utilizzato per migliorare il tempo di failover in MVPN. L'approccio combina i meccanismi definiti nelle Sezioni 3 e 4 e presenta somiglianze con la soluzione descritta in [RFC7431] per migliorare i tempi di failover quando il routing PIM viene utilizzato in una rete date alcune limitazioni di topologia e metrica.

2. Conventions Used in This Document​

2.1. Requirements Language​

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono in maiuscolo, come mostrato qui.

2.2. Terminology​

The terminology used in this document is the terminology defined in [RFC6513] and [RFC6514].

La terminologia utilizzata in questo documento è la terminologia definita in [RFC6513] e [RFC6514].

2.3. Abbreviations​

This document uses the following abbreviations:

Questo documento utilizza le seguenti abbreviazioni:

  • BFD: Bidirectional Forwarding Detection (Rilevamento dell'inoltro bidirezionale)
  • MVPN: Multicast Virtual Private Network (Rete privata virtuale multicast)
  • NLRI: Network Layer Reachability Information (Informazioni sulla raggiungibilità del livello di rete)
  • PE: Provider Edge (Bordo del provider)
  • PMSI: Provider Multicast Service Interface (Interfaccia del servizio multicast del provider)
  • RPT: Rendezvous Point Tree (Albero del punto di incontro)
  • SPT: Shortest Path Tree (Albero del percorso più breve)
  • UMH: Upstream Multicast Hop (Salto multicast a monte)
  • VPN: Virtual Private Network (Rete privata virtuale)
  • VRF: VPN Routing and Forwarding (Routing e inoltro VPN)

3. UMH Selection Based on Tunnel Status​

Section 5.1 of RFC 6513 describes procedures used by an MVPN downstream PE to determine the Upstream Multicast Hop (UMH) for a given (C-S,C-G).

La Sezione 5.1 della RFC 6513 descrive le procedure utilizzate da un PE MVPN a valle per determinare l'Upstream Multicast Hop (UMH) per un dato (C-S,C-G).

For a given downstream PE and a given VRF, the P-tunnel corresponding to a given Upstream PE for a given (C-S,C-G) state is the S-PMSI tunnel advertised by that Upstream PE for that (C-S,C-G) and imported into that VRF or, if there isn't any such S-PMSI, the I-PMSI tunnel advertised by that PE and imported into that VRF.

Per un dato PE a valle e un dato VRF, il P-tunnel corrispondente a un dato PE a monte per un dato stato (C-S,C-G) è il tunnel S-PMSI pubblicizzato da quel PE a monte per quel (C-S,C-G) e importato in quel VRF o, se non esiste alcun S-PMSI, il tunnel I-PMSI pubblicizzato da quel PE e importato in quel VRF.

The procedure described here is optional one, based on a downstream PE taking into account the status of P-tunnels rooted at each possible Upstream PE, for including or not including each given PE in the list of candidate UMHs for a given (C-S,C-G) state. If it is not possible to determine whether a P-tunnel's current status is Up, the state shall be considered "not known to be Down", and it may be treated as if it is Up so that attempts to use the tunnel are acceptable. The result is that, if a P-tunnel is Down (see Section 3.1), the PE that is the root of the P-tunnel will not be considered for UMH selection. This will result in the downstream PE failing over to use the next Upstream PE in the list of candidates. Some downstream PEs could arrive at a different conclusion regarding the tunnel's state because the failure impacts only a subset of branches. Because of that, the procedures of Section 9.1.1 of RFC 6513 are applicable when using I-PMSI P-tunnels. That document is a foundation for this document, and its processes all apply here.

La procedura qui descritta è facoltativa, basata su un PE a valle che tiene conto dello stato dei P-tunnel radicati in ogni possibile PE a monte, per includere o non includere ogni dato PE nell'elenco dei candidati UMH per un dato stato (C-S,C-G). Se non è possibile determinare se lo stato attuale di un P-tunnel è Up, lo stato deve essere considerato "non noto per essere Down" e può essere trattato come se fosse Up in modo che i tentativi di utilizzare il tunnel siano accettabili. Il risultato è che, se un P-tunnel è Down (vedere la Sezione 3.1), il PE che è la radice del P-tunnel non sarà considerato per la selezione UMH. Ciò comporterà il failover del PE a valle per utilizzare il successivo PE a monte nell'elenco dei candidati. Alcuni PE a valle potrebbero giungere a una conclusione diversa riguardo allo stato del tunnel perché il guasto ha un impatto solo su un sottoinsieme di rami. Per questo motivo, le procedure della Sezione 9.1.1 della RFC 6513 sono applicabili quando si utilizzano P-tunnel I-PMSI. Quel documento è una base per questo documento e i suoi processi si applicano tutti qui.

There are three options specified in Section 5.1 of RFC 6513 for a downstream PE to select an Upstream PE.

Ci sono tre opzioni specificate nella Sezione 5.1 della RFC 6513 per un PE a valle per selezionare un PE a monte.

The first two options select the Upstream PE from a candidate PE set based either on an IP address or a hashing algorithm. When used together with the optional procedure of considering the P-tunnel status as in this document, a candidate Upstream PE is included in the set if it either:

Le prime due opzioni selezionano il PE a monte da un set di PE candidati basato su un indirizzo IP o su un algoritmo di hashing. Se utilizzato insieme alla procedura facoltativa di considerare lo stato del P-tunnel come in questo documento, un candidato PE a monte è incluso nel set se:

  • advertises an x-PMSI bound to a tunnel, where the specified tunnel's state is not known to be Down, or,
  • pubblicizza un x-PMSI associato a un tunnel, in cui lo stato del tunnel specificato non è noto per essere Down, o,
  • does not advertise any x-PMSI applicable to the given (C-S,C-G) but has associated a VRF Route Import BGP Extended Community to the unicast VPN route for S. That is necessary to avoid incorrectly invalidating a UMH PE that would use a policy where no I-PMSI is advertised for a given VRF and where only S-PMSIs are used. The S-PMSI can be advertised only after the Upstream PE receives a C-multicast route for (C-S,C-G) / (C-*,C-G) to be carried over the advertised S-PMSI.
  • non pubblicizza alcun x-PMSI applicabile al dato (C-S,C-G) ma ha associato una comunità estesa BGP VRF Route Import alla route VPN unicast per S. Ciò è necessario per evitare di invalidare erroneamente un PE UMH che utilizzerebbe una politica in cui nessun I-PMSI è pubblicizzato per un dato VRF e in cui vengono utilizzati solo S-PMSI. L'S-PMSI può essere pubblicizzato solo dopo che il PE a monte riceve una route C-multicast per (C-S,C-G) / (C-*,C-G) da trasportare sull'S-PMSI pubblicizzato.

If the resulting candidate set is empty, then the procedure is repeated without considering the P-tunnel status.

Se il set di candidati risultante è vuoto, la procedura viene ripetuta senza considerare lo stato del P-tunnel.

The third option uses the installed UMH Route (i.e., the "best" route towards the C-root) as the Selected UMH Route, and its originating PE is the selected Upstream PE. With the optional procedure of considering P-tunnel status as in this document, the Selected UMH Route is the best one among those whose originating PE's P-tunnel is not "down". If that does not exist, the installed UMH Route is selected regardless of the P-tunnel status.

La terza opzione utilizza la route UMH installata (ovvero, la rotta "migliore" verso la C-root) come route UMH selezionata, e il suo PE di origine è il PE a monte selezionato. Con la procedura facoltativa di considerare lo stato del P-tunnel come in questo documento, la route UMH selezionata è la migliore tra quelle il cui P-tunnel del PE di origine non è "down". Se ciò non esiste, la route UMH installata viene selezionata indipendentemente dallo stato del P-tunnel.

3.1. Determining the Status of a Tunnel​

Different factors can be considered to determine the "status" of a P-tunnel and are described in the following subsections. The optional procedures described in this section also handle the case when the downstream PEs do not all apply the same rules to define what the status of a P-tunnel is (please see Section 6), and some of them will produce a result that may be different for different downstream PEs. Thus, the "status" of a P-tunnel in this section is not a characteristic of the tunnel in itself but is the tunnel status, as seen from a particular downstream PE. Additionally, some of the following methods determine the ability of a downstream PE to receive traffic on the P-tunnel and not specifically on the status of the P-tunnel itself. That could be referred to as "P-tunnel reception status", but for simplicity, we will use the terminology of P-tunnel "status" for all of these methods.

Diversi fattori possono essere presi in considerazione per determinare lo "stato" di un P-tunnel e sono descritti nelle seguenti sottosezioni. Le procedure facoltative descritte in questa sezione gestiscono anche il caso in cui i PE a valle non applicano tutti le stesse regole per definire quale sia lo stato di un P-tunnel (vedere la Sezione 6), e alcuni di essi produrranno un risultato che potrebbe essere diverso per diversi PE a valle. Pertanto, lo "stato" di un P-tunnel in questa sezione non è una caratteristica del tunnel in sé ma è lo stato del tunnel, visto da un particolare PE a valle. Inoltre, alcuni dei seguenti metodi determinano la capacità di un PE a valle di ricevere traffico sul P-tunnel e non specificamente sullo stato del P-tunnel stesso. Ciò potrebbe essere definito come "stato di ricezione P-tunnel", ma per semplicità, utilizzeremo la terminologia di "stato" P-tunnel per tutti questi metodi.

Depending on the criteria used to determine the status of a P-tunnel, there may be an interaction with another resiliency mechanism used for the P-tunnel itself, and the UMH update may happen immediately or may need to be delayed. Each particular case is covered in each separate subsection below.

A seconda dei criteri utilizzati per determinare lo stato di un P-tunnel, potrebbe esserci un'interazione con un altro meccanismo di resilienza utilizzato per il P-tunnel stesso, e l'aggiornamento UMH potrebbe avvenire immediatamente o potrebbe dover essere ritardato. Ogni caso particolare è trattato in ciascuna sottosezione separata di seguito.

An implementation may support any combination of the methods described in this section and provide a network operator with control to choose which one to use in the particular deployment.

Un'implementazione può supportare qualsiasi combinazione dei metodi descritti in questa sezione e fornire a un operatore di rete il controllo per scegliere quale utilizzare nella particolare distribuzione.

3.1.1. MVPN Tunnel Root Tracking​

When determining if the status of a P-tunnel is Up, a condition to consider is whether the root of the tunnel, as specified in the x-PMSI Tunnel attribute, is reachable through unicast routing tables. In this case, the downstream PE can immediately update its UMH when the reachability condition changes.

Quando si determina se lo stato di un P-tunnel è Up, una condizione da considerare è se la radice del tunnel, come specificato nell'attributo x-PMSI Tunnel, è raggiungibile tramite tabelle di routing unicast. In questo caso, il PE a valle può aggiornare immediatamente il suo UMH quando cambia la condizione di raggiungibilità.

That is similar to BGP next-hop tracking for VPN routes, except that the address considered is not the BGP next-hop address but the root address in the x-PMSI Tunnel attribute. BGP next-hop tracking monitors BGP nexthops.

Ciò è simile al tracciamento dell'hop successivo BGP per le rotte VPN, tranne per il fatto che l'indirizzo considerato non è l'indirizzo dell'hop successivo BGP ma l'indirizzo root nell'attributo x-PMSI Tunnel. Il tracciamento dell'hop successivo BGP monitora gli hop successivi BGP.

To determine the status of a P-tunnel, the downstream PE can check the status of the link that it uses to reach the Upstream PE. If the link is down, the P-tunnel status is considered Down.

Per determinare lo stato di un P-tunnel, il PE a valle può controllare lo stato del collegamento che utilizza per raggiungere il PE a monte. Se il collegamento è inattivo, lo stato del P-tunnel è considerato Down.

3.1.3. P2MP RSVP-TE Tunnels​

For Point-to-Multipoint (P2MP) RSVP-TE tunnels, the status of the tunnel can be determined by the state of the RSVP-TE Label Switched Path (LSP). If the LSP is down, the P-tunnel status is considered Down.

Per i tunnel RSVP-TE Point-to-Multipoint (P2MP), lo stato del tunnel può essere determinato dallo stato del RSVP-TE Label Switched Path (LSP). Se l'LSP è inattivo, lo stato del P-tunnel è considerato Down.

3.1.4. Leaf-Initiated P-Tunnels​

For leaf-initiated P-tunnels, the status can be determined by the state of the signaling protocol used to set up the tunnel.

Per i P-tunnel avviati da leaf, lo stato può essere determinato dallo stato del protocollo di segnalazione utilizzato per impostare il tunnel.

3.1.5. (C-S,C-G) Counter Information​

The status of a P-tunnel can also be inferred from the traffic statistics for a specific (C-S,C-G). If the traffic rate drops below a certain threshold, the P-tunnel status can be considered Down.

Lo stato di un P-tunnel può anche essere dedotto dalle statistiche del traffico per uno specifico (C-S,C-G). Se la velocità del traffico scende al di sotto di una certa soglia, lo stato del P-tunnel può essere considerato Down.

3.1.6. BFD Discriminator Attribute​

This document defines a new BGP Attribute, BFD Discriminator, which can be used to associate a BFD session with a P-tunnel. The status of the BFD session determines the status of the P-tunnel.

Questo documento definisce un nuovo attributo BGP, BFD Discriminator, che può essere utilizzato per associare una sessione BFD a un P-tunnel. Lo stato della sessione BFD determina lo stato del P-tunnel.

In some cases, it may be useful to associate a BFD discriminator with a specific PE-CE link. This allows the downstream PE to monitor the status of the link to the CE using BFD.

In alcuni casi, potrebbe essere utile associare un discriminatore BFD a uno specifico collegamento PE-CE. Ciò consente al PE a valle di monitorare lo stato del collegamento al CE utilizzando BFD.

3.1.8. Operational Considerations for Monitoring a P-Tunnel's Status​

When monitoring the status of a P-tunnel, care must be taken to avoid false positives and to ensure that the monitoring mechanism does not introduce excessive overhead.

Quando si monitora lo stato di un P-tunnel, è necessario prestare attenzione per evitare falsi positivi e garantire che il meccanismo di monitoraggio non introduca un sovraccarico eccessivo.

4. Standby C-Multicast Route​

This section describes an optional BGP extension, a new Standby PE Community, that can speed up failover by not requiring any Multicast VPN (MVPN) routing message exchange at recovery time.

Questa sezione descrive un'estensione BGP facoltativa, una nuova comunità Standby PE, che può accelerare il failover non richiedendo alcuno scambio di messaggi di routing Multicast VPN (MVPN) al momento del ripristino.

4.1. Downstream PE Behavior​

A downstream PE that supports the Standby PE Community can advertise a C-multicast route to a Standby Upstream PE. This allows the Standby Upstream PE to be pre-programmed with the necessary state to forward traffic for the (C-S,C-G).

Un PE a valle che supporta la comunità Standby PE può pubblicizzare una route C-multicast a uno Standby Upstream PE. Ciò consente allo Standby Upstream PE di essere pre-programmato con lo stato necessario per inoltrare il traffico per il (C-S,C-G).

4.2. Upstream PE Behavior​

An Upstream PE that receives a C-multicast route with the Standby PE Community MUST install the state for the (C-S,C-G) but MUST NOT forward traffic until it is selected as the UMH.

Un Upstream PE che riceve una route C-multicast con la comunità Standby PE DEVE installare lo stato per il (C-S,C-G) ma NON DEVE inoltrare traffico finché non viene selezionato come UMH.

4.3. Reachability Determination​

The downstream PE determines the reachability of the Upstream PE and the Standby Upstream PE using the mechanisms described in Section 3.

Il PE a valle determina la raggiungibilità del PE a monte e dello Standby Upstream PE utilizzando i meccanismi descritti nella Sezione 3.

4.4. Inter-AS​

This section describes the procedures for Inter-AS scenarios.

Questa sezione descrive le procedure per gli scenari Inter-AS.

4.4.1. Inter-AS Procedures for Downstream PEs, ASBR Fast Failover​

In Inter-AS scenarios, the downstream PE can use the Standby PE Community to advertise C-multicast routes to ASBRs.

Negli scenari Inter-AS, il PE a valle può utilizzare la comunità Standby PE per pubblicizzare route C-multicast agli ASBR.

4.4.2. Inter-AS Procedures for ASBRs​

ASBRs can use the Standby PE Community to advertise C-multicast routes to other ASBRs or to Upstream PEs.

Gli ASBR possono utilizzare la comunità Standby PE per pubblicizzare route C-multicast ad altri ASBR o a PE a monte.

5. Hot Root Standby​

This section describes a "hot root standby" mechanism that can be used to improve failover time in MVPN. The approach combines mechanisms defined in Sections 3 and 4 and has similarities with the solution described in [RFC7431] to improve failover times when PIM routing is used in a network given some topology and metric constraints.

Questa sezione descrive un meccanismo "hot root standby" che può essere utilizzato per migliorare il tempo di failover in MVPN. L'approccio combina i meccanismi definiti nelle Sezioni 3 e 4 e presenta somiglianze con la soluzione descritta in [RFC7431] per migliorare i tempi di failover quando il routing PIM viene utilizzato in una rete date alcune limitazioni di topologia e metrica.

6. Duplicate Packets​

When using the fast failover mechanisms described in this document, it is possible for duplicate packets to be delivered to the receiver. This section discusses the implications of duplicate packets and how to mitigate them.

Quando si utilizzano i meccanismi di failover rapido descritti in questo documento, è possibile che vengano consegnati pacchetti duplicati al ricevitore. Questa sezione discute le implicazioni dei pacchetti duplicati e come mitigarle.

7. IANA Considerations​

7.1. Standby PE Community​

IANA has assigned a BGP Community value for the Standby PE Community.

IANA ha assegnato un valore BGP Community per la comunità Standby PE.

7.2. BFD Discriminator​

IANA has assigned a BGP Attribute type code for the BFD Discriminator Attribute.

IANA ha assegnato un codice tipo attributo BGP per l'attributo BFD Discriminator.

7.3. BFD Discriminator Optional TLV Type​

IANA has assigned a Type value for the BFD Discriminator Optional TLV in the BGP Tunnel Encapsulation Attribute.

IANA ha assegnato un valore Type per il BFD Discriminator Optional TLV nell'attributo BGP Tunnel Encapsulation.

8. Security Considerations​

The security considerations for this document are similar to those for [RFC6513] and [RFC6514]. In addition, the use of BFD introduces new security considerations related to the authentication and integrity of BFD packets.

Le considerazioni sulla sicurezza per questo documento sono simili a quelle per [RFC6513] e [RFC6514]. Inoltre, l'uso di BFD introduce nuove considerazioni sulla sicurezza relative all'autenticazione e all'integrità dei pacchetti BFD.

9. References​

9.1. Normative References​

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.

[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, https://www.rfc-editor.org/info/rfc6513.

[RFC6514] Aggarwal, R., Ed., Rosen, E., Ed., Morin, T., Ed., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, https://www.rfc-editor.org/info/rfc6514.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.

[RFC8562] Katz, D., Ward, D., and S. Pallagatti, Ed., "Bidirectional Forwarding Detection (BFD) for Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, April 2019, https://www.rfc-editor.org/info/rfc8562.

9.2. Informative References​

[RFC7431] Karan, A., Wijnands, IJ., Ed., and E. Rosen, "Multicast-Only Fast Reroute", RFC 7431, DOI 10.17487/RFC7431, August 2015, https://www.rfc-editor.org/info/rfc7431.

[RFC7841] Halpern, J., Ed., Resnick, P., Ed., and O. Kolkman, Ed., "RFC Streams, Headers, and Boilerplates", RFC 7841, DOI 10.17487/RFC7841, May 2016, https://www.rfc-editor.org/info/rfc7841.

Acknowledgments​

The authors would like to thank...

Gli autori desiderano ringraziare...

Contributors​

...

Collaboratori...

Authors' Addresses​

Thomas Morin (editor) Orange Email: [email protected]

Robert Kebler (editor) Juniper Networks Email: [email protected]

Greg Mirsky (editor) ZTE Corp. Email: [email protected]

Ultimo aggiornamento il