Re: [mpls] Alvaro Retana's Comments on draft-ietf-mpls-sr-over-ip-03:

["Adrian Farrel" <[e-mail]>]

Hi Alvaro,

Again punting on your Discuss for a moment.

> COMMENT:
>
> Thank you for writing this document!
>
> In general, the use of terminology (defined in rfc8402 and elsewhere)
> needs to be cleaned up throughout the document.

That's a fine aspiration. Could you give us some pointers to terms that are used uncleanly?

> (1) [nit] From the Abstract: "SR-MPLS could be leveraged...while preserving
> backward compatibility with SR-MPLS."  I'm sure you want to say something
> related to making no changes to SR-MPLS for this application...the use of
> backwards compatibility with itself just sounds strange.  The Introduction has
> similar text, but it does go on to clarify a little.

OK. Abstract text becomes...

      SR-MPLS can be leveraged
      to realize a source routing mechanism across MPLS, IPv4, and IPv6 data
      planes by using an MPLS label stack as a source routing instruction set
      while making no changes to SR-MPLS specifications and interworking with
      SR-MPLS implementations.

Similar tweak to the Introduction.

> (2) [nit] §3.1: "the FIB can be used to tell a router how to process packets" 
> The FIB is generally in the router, so no need to tell it anything. ;-)  Maybe:
> "the FIB can be used by the router to process packets".

OK. Changed to:
        Once constructed, the FIB can be used by a router to tell it how to
        process packets.

> (3) §3.2: "Not all of the nodes in an SR-MPLS domain are SR-MPLS capable."  By
> definition, all nodes in an SR domain participate in the source-based routing
> model [rfc8402].  I think that you meant to say that not all nodes in the
> network (or maybe just the domain) are SR-MPLS capable.

The definition of "SR Domain" is a good subject for debate.
"Participating in the source-based routing model" means what?
A transit node in an SRv6 domain routes packets using the IGP to the current DA in the header. Such nodes do not need to be SRH-capable or SRH-aware. But I think they are within the domain.

A similar discussion has been going on in 6man with respect to the phrase "All intra SR Domain packets are of the SR Domain" in draft-ietf-6man-segment-routing-header-17.txt

> Note that the SR domain in the networks in Figure 1, for example, includes both
> the SR-MPLS networks at both sides and the tunneled portion.  If you mean for
> that picture to represent 3 different SR domains, then please don't use
> "SR-MPLS domain" to describe what is happening in the IP network portion.

I think your comments are harsh. The term "domain" is not used in that context. In fact, the term "domain" is not used until section 3.

Maybe we could completely not use the term. But it seems (to me) to be a good term to describe nodes on the path from SR source to SR destination.

> (4) §3.2: "There are six types of node in an SR-MPLS domain..."  Again, I think
> you mean to point at the types of nodes in the network and not in the SR domain.

Nope, the text is accurate and deliberate. The six subsections that follow describe the cases.
All of the node types are within the SR domain (that is, between entry point where encapsulation happens and exit point where decapsulation happens).

> (5) Security Considerations:  Please also point at the considerations in
> rfc8402.

Yes.

Thanks,
Adrian