Hi Adrian Just checking if you had a chance to look at my comments on the draft.
Kind Regards Gyan On Wed, Jun 10, 2020 at 2:55 PM Gyan Mishra <[email protected]> wrote: > Hi Adrian & Authors > > 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. > > 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. > > 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. > > 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. > > 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. > > 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. > > 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 > > > 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. > > 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. > > 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. > > 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. > > 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. > > 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. > > I think leaving out the AS2 AS1 BGP interaction makes it difficult to > follow and connect the dots on the solution. > > Kind regards > > Gyan > > On Thu, Jun 4, 2020 at 1:35 PM Adrian Farrel <[email protected]> wrote: > >> Hi, >> >> This late-breaking revision just tweaks for the discussion with Boris. >> >> Thanks, >> Adrian >> >> -----Original Message----- >> From: BESS <[email protected]> On Behalf Of [email protected] >> Sent: 04 June 2020 18:33 >> To: [email protected] >> Cc: [email protected] >> 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. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> _______________________________________________ >> BESS mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/bess >> >> _______________________________________________ >> BESS mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/bess >> > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > > > *M 301 502-134713101 Columbia Pike *Silver Spring, MD > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
