Re: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-spring-lsp-ping-11: (with COMMENT)

["Carlos Pignataro (cpignata)" <[e-mail]>]

Hi, Alvaro,

Thanks for the review! Please see inline.

On Oct 11, 2017, at 11:52 AM, Alvaro Retana <[e-mail]<mailto:[e-mail]>> wrote:

Alvaro Retana has entered the following ballot position for
draft-ietf-mpls-spring-lsp-ping-11: No Objection

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 IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-spring-lsp-ping/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) I’m surprised that there’s not even a passing reference to
draft-ietf-spring-oam-usecase, given that it points to this draft in several
places, among other things as “adding functionality to the use cases described
by this document”.  I'm not advocating for a web of references, just surprised.


Good point and thanks for bringing it up. Will add a small paragraph to the Intro.

Here’s a draft, what do you think?

<t>
The mechanics of MPLS LSP Ping as specified in <xref target="RFC8029" />
can be applied to segment routing networks in a Topology-Aware MPLS
Data plane Path Monitoring System (PMS) as shown in
<xref target="I-D.ietf-spring-oam-usecase" />. This document specifies
Target FEC Stacks to further enhance MPLS LSP Traceroute including
control plane validation and tracing to non-SR-capable notes pointed to
Adj-SIDs.
</t>


(2) The definition of a field with the name “Protocol” in Section 5. (Segment
ID sub-TLV) got me a little confused when I went looking for a registry and
found the values corresponding to the Downstream Detailed Mapping TLV (Section
6).  The name is ok, but I was wondering:  Can you reuse the existing registry
for the values used on the Segment ID sub-TLV?  If so, then the values for
OSPF/ISIS would change.  If not, then please have IANA set one up.

I think I understand this — but, the main Section 5 does not include any “Protocol”.

Sections 5.1, 5.2, and 5.3 do. This is a different Protocol, as you gathered, than the one from the Downstream Mapping in Section 6.

So, we cannot reuse the values for the SID sub-TLVs, because those include things like LDP and RSVP.

However, we can set up a registry for S 5.1, 5.2, and 5.3’s protocol. Like this:

9.2.  Protocol in the Segment ID sub-TLV

   IANA is requested to create a new "Protocol in the Segment ID sub-
   TLV" (see Section 5) registry under the "Multi-Protocol Label
   Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
   registry.  Code points in the range of 0-250 will be assigned by
   Standards Action.  The range of 251-254 are reserved for experimental
   use and will not be assigned.  The initial entries into the registry
   will be:

     Value           Meaning              Reference
   ----------        ----------------     ------------
     0               Any IGP Protocol     This document
     1               OSPF                 This document
     2               ISIS                 This document



(3) What happens if there’s any error (invalid length, unknown protocol, etc.)
in the sub-TLVs defined in Section 5?  I’m assuming that the action is specific
to the TLV that contains them, or that there is something already specified in
rfc8029 — please include a pointer, or specifics if needed.

Nothing different from RFC 8029, which defines Errored TLVs and procedures.

 I see that Section
7.4. (Segment ID Check) says that other values (for Protocol) “MUST be treated
as Protocol value of 0” — that’s ok for now, but when/if other values are used
this document would have to be Updated.  It may be better to say “any other
unassigned value” (or maybe unrecognized, or something along those lines).


Excellent point. Thanks. Will use “unrecognized”.

(4) I would really like to see a registry definition for Adj. Type (in 5.3).



OK, here it goes:

9.3.  Adjacency Type in the IGP-Adjacency Segment ID

   IANA is requested to create a new "Adjacency Type in the IGP-
   Adjacency Segment ID" (see Section 5.3) registry under the "Multi-
   Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping
   Parameters" registry.  Code points in the range of 0-250 will be
   assigned by Standards Action.  The range of 251-254 are reserved for
   experimental use and will not be assigned.  The initial entries into
   the registry will be:

     Value           Meaning
   ----------        ----------------
     0               Unnumbered interface Adjacency
     1               Parallel Adjacency
     4               IPv4, non-parallel Adjacency
     6               IPv6, non-parallel Adjacency


Thanks!

Carlos.