Subject: Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS and COMMENT)

From: Alvaro Retana <[email-masked]>
Date: Fri, 8 Jan 2021 17:46:29 -0500

Ben:

Hi!

The proposed changes are reflected in -22.  Please take a look.

Thanks!

Alvaro.

On December 17, 2020 at 4:45:23 PM, Alvaro Retana ([email-masked])
wrote:

Ben:

Hi!

Any thoughts on this?

Thanks!

Alvaro.

On December 11, 2020 at 10:43:40 AM, John Scudder ([email-masked]) wrote:

Hi Ben,

In this reply I’ll just address your open Discuss:

On Dec 4, 2020, at 12:08 AM, Benjamin Kaduk <[email-masked]> wrote:

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

I support Erik's discuss.

I see that Roman has already suggested adding normative language
regarding the limitation to a single administrative domain (in addition
to the "MUST filter by default for EBGP sessions"), which I agree with.
However, I think there is an additional consideration regarding the
limitation of use to a single administrative domain, wherein the domain
of use for the tunnel encapsulation attribute may diverge from the
domain of use of segment routing, that seems to place this document in
conflict with the requirements of RFC 8402.  In particular,
RFC 8402 says, for SR-MPLS and SRv6, that boundary routers "MUST filter
any external traffic", and additionally for SRv6 that "explicit routing
information MUST NOT be leaked through the boundaries of the
administrered domain".  In §3.7 of this document, though, we find that
for the Prefix-SID sub-TLV, "the receiving BGP speaker need not even be
in the same Segment Routing Domain as the tunnel's egress endpoint, and
there is no implication that the prefix-SID for the advertised prefix is
the same in the Segment Routing domains of the BGP speaker that
originated the sub-TLV and the BGP speaker that received it", which
seems to suggest violation of the RFC 8402 requirement.  I think we need
to have greater clarity on what relationship is actually intended
between the SR domain and the tunnel encapsulation usage domain, and if
they are to diverge, we need to both somehow rectify this behavior with
RFC 8402 and to very clearly document how the 8402-mandated filtering at
the SR domain boundary is supposed to happen when the boundary includes
tunneled traffic.

We’ll respond to this later, I need to discuss it with my coauthors and
didn’t want to hold up the rest of the response any longer than I have.

Sounds good.  I am not surprised that this one is going to require more
discussion; it seems like a tricky task to figure out the right thing to
do.

We did a review of RFC 8402’s definition of an “SR domain”. Here’s 8402,
from the Terminology section, emphasis added:

   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).*  If multiple protocol instances are
   deployed, the SR domain most commonly includes all of the protocol
   instances in a network.  However, some deployments may wish to
   subdivide the network into multiple SR domains, each of which
   includes one or more protocol instances.  It is expected that all
   nodes in an SR domain are managed by the same administrative entity.

Other parts of 8402 imply other properties of an SR domain. One is that all
the participating routers share a Prefix-SID namespace (this is my
interpretation, not the wording of 8402), another is the text in Section
8.1 you quote above, about filtering external traffic.

The text that bothered you in tunnel-encaps (“need not even be in the same
Segment Routing Domain”) was directed only toward the namespace aspect: the
two ends of the tunnel may be using different prefix-SID namespaces. But as
we see above, the namespace isn’t a defining attribute of the SR domain.
So, I think the best way forward is to strike the offending text from
tunnel-encaps. The paragraph stands just as well (arguably better) without
it:

   The Prefix-SID sub-TLV has slightly different semantics than the
   Prefix-SID attribute.  When the Prefix-SID attribute is attached to a
   given route, the BGP speaker that originally attached the attribute
   is expected to be in the same Segment Routing domain as the BGP
   speakers who receive the route with the attached attribute.  The
   Label-Index tells the receiving BGP speakers what the prefix-SID is
   for the advertised prefix in that Segment Routing domain.  When the

   Prefix-SID sub-TLV is used, the receiving BGP speaker need not even

   be in the same Segment Routing Domain as the tunnel's egress
endpoint, and there is no implication that the prefix-SID for the
   advertised prefix is the same in the Segment Routing domains of the
   BGP speaker that originated the sub-TLV and the BGP speaker that
   received it.

We’d also add something like the following to the Security Considerations
section:

   RFC 8402 specifies that "SR domain boundary routers MUST filter any
   external traffic" ([RFC 8402] Section 8.1). For these purposes,
   traffic introduced into a SR domain using the Prefix-SID sub-TLV lies
   within the SR domain, even though the prefix-SIDs used by the routers
   at the two ends of the tunnel may be different, as discussed in
   Section 3.7. This implies that the duty to filter external traffic
   extends to all routers participating in such tunnels.

What do you think?

Thanks,

—John

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 11 Jan 2021 14:58:08 -0800

Hi John,

Sorry for the delayed reply; I managed to get in a nice relaxing holiday
vacation, but with formal telechats on either side of it I neglected my
inbox...

Thank you for digging into and writing up the subtleties involved here.
I agree with your overall assessment and plan, and will go clear my Discuss
shortly.  I might consider having the §3.7 text read no implication that
the prefix-SID for the advertised prefix is the same as seen by the BGP
speaker that originated the sub-TLV and the BGP speaker that received it"
to talk even less about "Segment Routing domains" in that location, but I
am not 100% confident that would be accurate, so please use your judgment.

Thanks again,

Ben

On Fri, Dec 11, 2020 at 03:43:36PM +0000, John Scudder wrote:
>    Hi Ben,
>    In this reply I'll just address your open Discuss:
> 
>          administrered domain".  In S:3.7 of this document, though, we find
>          that
>        We'll respond to this later, I need to discuss it with my coauthors
>        and didn't want to hold up the rest of the response any longer than I
>        have.
> 
>    We did a review of RFC 8402's definition of an "SR domain". Here's 8402,
>     They may as well be remotely connected to each other (e.g., an
>     enterprise VPN or an overlay).  If multiple protocol instances are
>    Other parts of 8402 imply other properties of an SR domain. One is that
>    all the participating routers share a Prefix-SID namespace (this is my
>    The text that bothered you in tunnel-encaps ("need not even be in the same
>    Segment Routing Domain") was directed only toward the namespace aspect:
>    the two ends of the tunnel may be using different prefix-SID namespaces.
>    But as we see above, the namespace isn't a defining attribute of the SR
>    domain. So, I think the best way forward is to strike the offending text
>    from tunnel-encaps. The paragraph stands just as well (arguably better)
>    without it:
> 
>    We'd also add something like the following to the Security Considerations
>    section:
> 
>  -John