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

[Gyan Mishra <[e-mail]>]

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 <[e-mail]> wrote:

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