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

[John Scudder <[e-mail]>]

Hi Ben,

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

On Dec 4, 2020, at 12:08 AM, Benjamin Kaduk <[e-mail]<mailto:[e-mail]>> 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