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

From: Warren Kumari via Datatracker <[email-masked]>
Date: Tue, 18 May 2021 17:03:31 -0700

Warren Kumari has entered the following ballot position for
draft-ietf-bess-datacenter-gateway-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-datacenter-gateway/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I hope that I'm just misunderstanding something obvious, but I strongly support
John's DISCUSS -- 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.

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

I'm hoping that I'm really misunderstanding something here -- please educate me.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 19 May 2021 09:47:16 +0100

Hi Warren,

Thanks for this. I'll try to unpick it.

> DISCUSS:
> ---------------------------------------------------------------
>
> 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

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.

> 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

---

From: Warren Kumari <[email-masked]>
Date: Thu, 20 May 2021 10:42:11 -0400

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

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

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

> Do you consider yourself educated now, or merely disciplined? 😉

Would you settle for "confused"?  :-P

W

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