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 [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
