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

[Adrian Farrel <[e-mail]>]

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. 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).

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. 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.

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? 😉

Cheers,
Adrian