Subject: Re: [bess] New version: draft-ietf-bess-datacenter-gateway-07.txt

From: Gyan Mishra <[email-masked]>
Date: Mon, 6 Jul 2020 18:33:19 -0400

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-masked]> 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-masked]> wrote:
>
>> Hi,
>>
>> This late-breaking revision just tweaks for the discussion with Boris.
>>
>> Thanks,
>> Adrian
>>
>> -----Original Message-----
>> From: BESS <[email-masked]> On Behalf Of [email-masked]
>> Sent: 04 June 2020 18:33
>> To: [email-masked]
>> Cc: [email-masked]
>> 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-masked]
>> https://www.ietf.org/mailman/listinfo/bess
>>
>> _______________________________________________
>> BESS mailing list
>> [email-masked]
>> 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