Hi Eric, | Thank you for the work put into this document. | | I support John Scudder's first DISCUSS point.
Fair enough. What did you think of my response to John >> DISCUSS: >> >> 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 used to identify the paths between the Ingress and Egress > and the techniques in this document apply to routes of all AFI/SAFIs. | Please find below some non-blocking COMMENT points (but replies | would be appreciated), and some nits. | | == COMMENTS == | | -- Section 3 -- | How will the GW identifiers be unique across all interconnected SR domains ? | Section 9 is rather hand waving. There are two issues to be resolved: 1. How will all interconnected SR sites (formerly called domains) use different site identifiers? 2. How will all gateways to the same site consistently use the same identifier? Just like the mechanisms used to assign many other things in networking (IP addresses, AS numbers, VPN IDs, ...) there may be many approaches available (dedicated protocols, piggy-backing on other protocols, management protocols, manual configuration). Not sure why this spec needs to be responsible for defining those distribution/configuration/coordination mechanisms. Section 9 makes it very clear what result must be achieved, and observes that we are not introducing a new problem to the BGP world. Could we make it clearer that the operator is responsible for getting this right? | -- Section 10 -- | Is there any reason why the doc shepherd is not acknowledged ? Of course, we love our shepherd. Matthew, as WG chair, pushed the right people to do reviews, and also pushed the right buttons to advance the document. As shepherd, Matthew wrote: I reviewed Version 8 of the draft. I have no significant comments on the draft. The Acknowledgements section historically thanks people whose comments have helped shape or improve the contents of the document. | == NITS == | | -- Section 1 -- | s/against connection of device failure/against connection or device failure/ ? Ack | I find the use of "ingress" in "source (ingress)" confusing, should the reader | assume that it is "source (SR-domain ingress)" ? Could write "source DC (also known as an ingress DC)" Ditto destination/egress Cheers, Adrian _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
