Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-datacenter-gateway-10: (with DISCUSS)

[Warren Kumari <[e-mail]>]

On Wed, May 19, 2021 at 4:47 AM Adrian Farrel <[e-mail]> wrote:

> Hi Warren,
>
> Thanks for this. I'll try to unpick it.
>
> > DISCUSS:
> > ---------------------------------------------------------------
> >
> > I hope that I'm just misunderstanding something obvious, but I strongly
> support
> > John's DISCUSS
>
> So far, so good: we are in discussions with John and believe we will reach
> a resolution that satisfies him.
>
> > when SR was "approved" it was with the understanding that it
> > would only be used within "real" limited domains, and would never be sent
> > outside of closed/limited network.
>
> I fear that there may have been some slipperiness in the discussion that
> led to this understanding.
> I recall pushing back quite a bit on the definition of "SR domain" as it
> appeared in 8402 during IETF last call. But I didn't see a lot of support
> for my view and concluded I was in the rough.
>
> He definition we ended up with specifically allows for tunnelling of SR
> over non-SR parts of the network.


I suspect that part of this is this comes in the use of the term "tunnel"



> And, indeed, the nature of SRv6 is that packets containing the SRH may be
> forwarded "transparently" by non-SR IPv6 routers. The domain is, therefore,
> defined as the collection of interconnected SR-capable nodes. We ended up
> with:
>
>    Segment Routing domain (SR domain): the set of nodes participating in
>    the source-based routing model.  These nodes may be connected to the
>    same physical infrastructure (e.g., a Service Provider's network).
>    They may as well be remotely connected to each other (e.g., an
>    enterprise VPN or an overlay).
>
>
I read "same physical infrastructure (e.g., a Service Provider's network)."
as something like an ISP network, operated by a single "operator"/entiy, so
the SR traffic stays within what would commonly be called a "network".
I read "remotely connected to each other (e.g., an enterprise VPN or an
overlay)." as something where a packet (SR or whatever) is encapsulated as
the payload of a new packet -- e.g a packet from my laptop on my enterprise
VPN is encapsulated in the new packet by the VPN widget/software, and
decapsulated by the other end.



> This may go against your expectations (it may even go against reasonable
> expectations), but it is what it is.
>
> In the light of this, and with the understanding of how overlays are built
> and used (especially for VPNs), we explicitly looked in this document to
> provide a simple way that SR-capable sites may be interconnected using a
> concatenation of tunnels between SR-capable nodes in the wider network.


Yup -- and I'm happy with this as a concatenation of actual tunnels (IPIP,
GRE, IPSEC, etc) - my concern comes in if this is used for "raw" SR traffic
(where the destination is an endpoint, and not a specific decapsulation
device). The document says: "The various ASes that provide connectivity
between the ingress and egress sites 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." - if
this is actually a VPN style or real overlay, I'm fine, but this isn't
clear to me...


> As you'll see from the document, this doesn't involve any changes to SR,
> but does make use of SR's ability to use a SID to identify a node or a
> tunnel. Our only new stuff is to allow BGP to distribute information in a
> way that handles a site having multiple gateways and to cope with multiple
> possible paths between sites. If an ASBR (BGP peer) is unable to process
> the BGP extensions or is not SR-capable, it will not participate.
>
> > The document says: "The solution defined in this document can be seen in
> the
> > broader context of SR domain interconnection in
> > [I-D.farrel-spring-sr-domain-interconnect]. ", which says: " Traffic
> > originating in one SR domain often terminates in another SR domain, but
> must
> > transit a backbone network that provides interconnection between those
> > domains." -- is it unclear to me if this is really what is being
> proposed...
>
> Again (as per the many discussions during IESG review), s/domain/site/
> That was a bad mistake by the authors (who really love the use of the word
> 'domain' as applied in all of the TEAS work).
> To be clear, all interconnected SR sites form part of the same
> 8402-SR-domain.
>
>
Hmmm... This *might* address my concern, but I will need to reread this
definition of domain. I have a horrible feeling that my concern/grump isn't
with this draft, but rather with RFC8402...



> We have fixed the use of site/domain in the working copy (which we hope to
> post later today).
>
> > I'm hoping that I'm really misunderstanding something here -- please
> educate me.
>
> Do you consider yourself educated now, or merely disciplined? 😉
>

Would you settle for "confused"?  :-P

W



>
> Cheers,
> Adrian
>
>

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra