Alvaro Very good points brought up on the limitations on the tunnel encapsulation attribute BGP prefix sid sub tlv. Can only be used with BGP LU AFI / SAFI.
Kind Regards Gyan On Mon, May 17, 2021 at 4:12 PM Alvaro Retana <aretana.i...@gmail.com> wrote: > On May 14, 2021 at 1:04:53 PM, Adrian Farrel wrote: > > > Hi! > > I share some of John's concerns -- quick comment on the first one. > > > ... > > > 1. There’s surprisingly little in this document that seems to be > > > SR-specific (and what there is, has some problems, see below). Is there > > > some reason you rule out interconnecting domains using other tunneling > > > technologies? I ask this question first because if the answer were to > be > > > “oh huh, we don’t need to make this SR-specific after all” some of the > > > other things I’m asking about might go away. > > > > I'm sorry this isn't clear, but the use of other tunnelling technologies > is > > very much in scope. As the Introduction says: > > > > The various ASes that provide connectivity between the Ingress and Egress > > Domains could each be constructed differently and use different > technologies > > such as IP, MPLS with global table routing native BGP to the edge, MPLS > IP > > VPN, SR-MPLS IP VPN, or SRv6 IP VPN. > > > > SR is used to identify the tunnels and provide end-to-end SR paths > because the > > ingress and egress domains are SR domains, and the objective is to > provide an > > end-to-end SR path. > > > > So we are not "making this SR aware" so much as enabling "SR-over-foo" > using > > SIDs to identify the path segments that are tunnels. > > > > I don't know how to make this clearer except maybe using some red paint. > We > > would write... > > > > The various ASes that provide connectivity between the Ingress and Egress > > Domains could each be constructed differently and use different > technologies > > such as IP, MPLS with global table routing native BGP to the edge, MPLS > IP > > VPN, SR-MPLS IP VPN, or SRv6 IP VPN. That is, the Ingress and Egress SR > > Domains can be connected by tunnels across a variety of technologies. > This > > document describes how SR identifiers (SIDs) are use to identify the > paths > > between the Ingress and Egress and the techniques in this document apply > to > > routes of all AFI/SAFIs. > > >From §5: "To achieve this, each Tunnel TLV in the Tunnel Encapsulation > attribute contains a Prefix SID sub-TLV [I-D.ietf-idr-tunnel-encaps] > for X." But rfc9012 restricts the use of the Prefix-SID sub-TLV: > > [RFC8669] only defines behavior when the BGP Prefix-SID attribute is > attached to routes of type IPv4/IPv6 Labeled Unicast Gyan> RFC8669 limitation 3.1 <https://datatracker.ietf.org/doc/html/rfc8669#section-3.1>. Label-Index TLV The Label-Index TLV MUST be present in the BGP Prefix-SID attribute attached to IPv4/IPv6 Labeled Unicast prefixes ([RFC8277 <https://datatracker.ietf.org/doc/html/rfc8277>]). It MUST be ignored when received for other BGP AFI/SAFI combinations. RFC 9012 Tunnel encapsulation attribute 3.7 <https://datatracker.ietf.org/doc/html/rfc9012#section-3.7>. Prefix-SID Sub-TLV (Type Code 11) [RFC8669] defines a BGP path attribute known as the "BGP Prefix-SID attribute". This attribute is defined to contain a sequence of one or more TLVs, where each TLV is either a Label-Index TLV or an Originator SRGB (Source Routing Global Block) TLV. This document defines a Prefix-SID (Prefix Segment Identifier) sub- TLV. The Value field of the Prefix-SID sub-TLV can be set to any permitted value of the Value field of a BGP Prefix-SID attribute [RFC8669 <https://datatracker.ietf.org/doc/html/rfc8669>]. [RFC8669] only defines behavior when the BGP Prefix-SID attribute is attached to routes of type IPv4/IPv6 Labeled Unicast [RFC4760 <https://datatracker.ietf.org/doc/html/rfc4760>][RFC8277], and it only defines values of the BGP Prefix-SID attribute for those cases. Therefore, similar limitations exist for the Prefix-SID sub-TLV: it SHOULD only be included in a BGP UPDATE message for one of the address families for which [RFC8669 <https://datatracker.ietf.org/doc/html/rfc8669>] has a defined behavior, namely BGP IPv4/IPv6 Labeled Unicast [RFC4760 <https://datatracker.ietf.org/doc/html/rfc4760>] [RFC8277 <https://datatracker.ietf.org/doc/html/rfc8277>]. If included in a BGP UPDATE for any other address family, it MUST be ignored. > [RFC4760][RFC8277], and it only defines values of the BGP Prefix-SID > attribute for those cases. Therefore, similar limitations exist for > the Prefix-SID sub-TLV: it SHOULD only be included in a BGP UPDATE > message for one of the address families for which [RFC8669] has a > defined behavior, namely BGP IPv4/IPv6 Labeled Unicast [RFC4760] > [RFC8277]. If included in a BGP UPDATE for any other address family, > it MUST be ignored. > > IOW, even though the overall mechanism could not be SR-specific, the > SR solution can't be implemented in a general way (without more > consideration). > > Alvaro. > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
