Hi Gyan,
Thanks so much for casting an eye over this document. Here are some answers to the points you raised. Best, Adrian I support the draft and the problems it is trying to address with SR-TR steering over multiple AS hops and the GW auto discovery features. AF> Thanks. We think it has stood the test of time, and the evolution of SR deployments has confirmed our view. I do have a few questions on the latest draft. I read through the discussion with Boris and has some additional follow on questions. In the Intro section 1 describing the problem statement it is said that load balancing cannot occur as only one best path is chosen which is true. However if you enabled eibgp multipath maximum paths set that both paths as long as BGP path selection all attributes are equal traffic can be easily load balanced between AS2 and egress SR domain. AF> This is true. But the point we were trying to make is that it is hard to load balance between the AS1-AS2 paths and the AS3 path. It is not mentioned if AS2 is IP only or mpls IP VPN domain and if a route reflector exist. I think that is important to mention as this gateway auto discovery feature uses RT extended community set and so if the core is IP VPN used that does complicate the architecture as now SAF 1 now stacked with SAFI 128. I have more questions on that topic discussed further down. AF> What Figure 1 does is give a generic architecture to allow discussion of the possibilities. So, one could have such a network with AS2 as plain IP, with MPLS/IP, with a VPN overlay (although perhaps that is less common for a single AS providing interconnect?), with a route reflector or without. You can make this almost as complicated as you like and BGP can handle it. In that scenario as long as RD is auto on the PEs and eibgp multipath is enabled the RR will reflect multiple paths by unique RF and traffic can be load balanced from AS2 to egress SR domain. For load balancing you would not want to do “add paths” as you would still only have one valid/best path in BGP best path selection. Also as “add paths” is generally used BGP PIC edge to advertise and pre program backup paths but is completely orthogonal to load balancing goal. AF> Yes, I agree that you can do some limited load balancing across one AS and into the egress SR domain. It is more complicated to pick the egress point from AS1 to load balance into the egress domain, and to load balance between the different AS paths. So now the real problem is not that load balancing won’t work in AS2 but rather that the GW1 GW2 next hops are not propagated to AS1. AF> Right. Yes, that’s it. And because they are not propagated, AS1 cannot know to load balance into AS2. What if you used the basic construct from inter-as option C RR to RR eBGP vpn peering and did the same from the SR egress domain GW1 GW2 ebgp multihop with next hop unchanged to AS1 ASBRs transit peers over the AS2 and that would propagate GW1 GW2 next hops. On the ebgp multi hop peers between SR egress domain and AS2 you could mesh the peering so each ASBR in AS2 peers with both GW1 and GW2 and you could enable ebgp multipath to load balance over next hops to both gateways. AF> I believe this gets quite complicated if there is a longer string of ASes or even an AS mesh. It also, as you say, requires the use of route reflectors which, although now common, are not always present. I read through this draft that was referenced and it talks about the concept of DC to DC or any external edge SR domain and traffic steering with SR-TE binding SID end to end steering. In that drafts context the backbone is MPLS or SR-MPLS or IP. https://datatracker.ietf.org/doc/html/draft-farrel-spring-sr-domain-interconnect-05 AF> Yes, I’m quite attached to that draft, but it seems that it got no traction with the SPRING chairs. The intention of that draft was to explain more clearly the deployment and operational possibilities without cluttering this document which tries to focus more on the specific protocol extensions. For the gateway draft for clarity it would be good to specify if the AS2 backbone could actually be the following flavors IP, MPLS with global table routing native BGP to the edge, MPLS IP VPN, SR-MPLS IP VPN, SRv6 IP VPN. Maybe also mention from a topology level with or without Route Reflector in AS2. AF> OK. We can clarify this. Section 3 GW auto discovery questions So each edge SR domain has an SR domain identifier which identifies all GWs in the domain and is unique to the domain and all prefixes exported have RT value for which is the SR domain identifier. Please specify if RT type O, 1, 2 used or any or if it matters. I think AS:NN type 0 or 4 would be appropriate to account for 2 byte and 4 byte ASN - RT nomenclature to embed the domain identifier would make sense as the edges AS could be the X:Y X value and the Y could be the unique domain identifier. AF> I think the use of 0x00 or 0x02 in the high-order octet of the RT Type field are most likely, but there is no reason why 0x01 should not be used if that is how the AS is managed. And this would not make any difference to how the mechanisms in this document work. The scheme you describe is certainly plausible. I noticed SAFI 4 BGP-LU is in the list of SAFI. That is traditionally used for inter-as L3 VPN optC or CsC flavors. In the context of SR as this draft is geared towards if you are using SR-TE with binding sid policy across each AS hop NNI boundary stitching the steered path you would not need BGP-LU. Also if the AS 2 core is MPLS only then would you need BGP-LU and only if using option C. There are caveats with other inter-as options related to multicast MVPN that recommends stacking BGP-LU as well for mLDP inband signaling. Yes. But unless anyone sees a good reason to rule out using SAFI 4, we prefer to keep the option open. If no one uses it, I guess that is OK. That is all the more reason to be crystal clear on the topology of the transit ASs in the mix here - AS 2 and AS 1 and if it’s every possible flavor then we should state that as well. I think from a operators standpoint it would make sense to have the draft account for all AS2 transport backbone flavors that are possible and account for how this solution would work for every flavor as their maybe lots of caveats as you did into the weeds with each flavor. It is certainly our intent to support “all possible flavours” so we will make that clear in the document. The auto-discovery route that each GW advertises consists of the following: o An IPv4 or IPv6 NLRI containing one of the GW's loopback addresses (that is, with an AFI/SAFI pair that is one of 1/1, 2/1, 1/4, or 2/4). Section 3 what seems to be missing in connecting the dots on how this solution would work is that you talk about the GWs import of the RTs which is fine but what is missing is the BGP interaction to backbone AS2 and all the possible variations of the AS2 transport. I think that will really help explain. It is hard to tell but are we doing ebgp multihop over GRE tunneling over AS2 and AS1 which is why we don’t talk about that the middle ASs routing details. The BGP behavior except at the gateways is “as normal”. The data packets are carried over the intervening ASes using tunnels as described by the tunnel encapsulations. Section 5 is the first mention of SR-TE in the draft and starts talking about the SR-MPLS label stack. Both paragraphs are very confusing as more context or a detailed stick diagram would help. What may help is an end to end packet walk on the discovery mechanism. We will work to clarify this text without (re-)defining how SR-TE works. I think leaving out the AS2 AS1 BGP interaction makes it difficult to follow and connect the dots on the solution. This really is “business as usual” for tunnel encapsulation. On Thu, Jun 4, 2020 at 1:35 PM Adrian Farrel <adr...@olddog.co.uk <mailto:adr...@olddog.co.uk> > wrote: Hi, This late-breaking revision just tweaks for the discussion with Boris. Thanks, Adrian -----Original Message----- From: BESS <bess-boun...@ietf.org <mailto:bess-boun...@ietf.org> > On Behalf Of internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> Sent: 04 June 2020 18:33 To: i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org> Cc: bess@ietf.org <mailto:bess@ietf.org> Subject: [bess] I-D Action: draft-ietf-bess-datacenter-gateway-07.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS WG of the IETF. Title : Gateway Auto-Discovery and Route Advertisement for Segment Routing Enabled Domain Interconnection Authors : Adrian Farrel John Drake Eric Rosen Keyur Patel Luay Jalil Filename : draft-ietf-bess-datacenter-gateway-07.txt Pages : 12 Date : 2020-06-04 Abstract: Data centers are critical components of the infrastructure used by network operators to provide services to their customers. Data centers are attached to the Internet or a backbone network by gateway routers. One data center typically has more than one gateway for commercial, load balancing, and resiliency reasons. Segment Routing is a protocol mechanism that can be used within a data center, and also for steering traffic that flows between two data center sites. In order that one data center site may load balance the traffic it sends to another data center site, it needs to know the complete set of gateway routers at the remote data center, the points of connection from those gateways to the backbone network, and the connectivity across the backbone network. Segment Routing may also be operated in other domains, such as access networks. Those domains also need to be connected across backbone networks through gateways. This document defines a mechanism using the BGP Tunnel Encapsulation attribute to allow each gateway router to advertise the routes to the prefixes in the Segment Routing domains to which it provides access, and also to advertise on behalf of each other gateway to the same Segment Routing domain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-datacenter-gateway/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bess-datacenter-gateway-07 https://datatracker.ietf.org/doc/html/draft-ietf-bess-datacenter-gateway-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-datacenter-gateway-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org> . Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ BESS mailing list BESS@ietf.org <mailto:BESS@ietf.org> https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list BESS@ietf.org <mailto:BESS@ietf.org> https://www.ietf.org/mailman/listinfo/bess -- <http://www.verizon.com/> Gyan Mishra Network Solutions Architect M 301 502-1347 13101 Columbia Pike Silver Spring, MD -- <http://www.verizon.com/> Gyan Mishra Network Solutions Architect M 301 502-1347 13101 Columbia Pike Silver Spring, MD
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
