Re: [mpls] Question on draft-ietf-mpls-rfc4379bis-09.txt

[t.petch <[e-mail]>]

----- Original Message -----
From: "Aissaoui, Mustapha (Nokia - CA)" <[e-mail]>
To: "t.petch" <[e-mail]>; <[e-mail]>
Sent: Friday, November 25, 2016 4:28 PM

Thanks Tom.

So, draft-ietf-mpls-spring-lsp-ping when it becomes RFC should state
that it is updating the RFC which will come out of
draft-ietf-mpls-rfc4379bis-09.txt.

<tp>

Mmmm my first reply was too hasty; wrong in fact.  I was looking at
spring-lsp-ping where it defined the new subTLVs of TLVs 1, 16, 20 but
you were asking about  TLV type 20 Downstream Detailed Mapping.

Stepping back, if all that an I-D or RFC does is add entries to existing
registries, then that is no longer considered an update to the earlier
RFC.  A former AD for mpls was very keen on this approach and I would
say that it is now the accepted approach within the IETF.  But we may
get an AD, or WG Chair perhaps, that takes a contrary view but I would
be surprised to see that.

Note that 4359bis is not even a reference for the spring I-D at present.

But s.7.4, the spring I-D says
"   This section updates the procedure defined in Step 6 of section 4.4.
   of [RFC4379]"
and if that is not an update, I do not know what is:-)  Should this also
apply to rfc4379bis?

Looking more closely at the I-D, I think that s.10.1 IANA Considerations
are ... well ...rubbish?  They reference sections 4.1, 4.2, 4.3 for the
new subTLVs, which is clearly wrong; should be 5.1, 5.2, 5.3.

s.7.4 has error code TBD with no request for TBD to be given a value.

s.6 adds TBD5 and TBD6 to the Downstream Mapping TLV with no request for
TBD5 and TBD6 to be given values.  But is this section referring to the
Downstream Mapping TLV of RFC4379 or the TLV20 Downstream Detailed
Mapping (which is what you asked about) or both? I think that the
authors may be a little confused here.

The Downstream Mapping TLV has no subTLVs so adding values to the
Downstream Mapping TLV is an update to 4379bis (or RFC4379 (or both)).

But the Downstream Detailed Mapping TLV has a Label Stack subTLV so
adding values to that is just an action for IANA and is not an update to
rfc4379bis and you can find this registry on the IANA website at
http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-p
arameters.xml#sub-tlv-20

which URL my pesky e-mail client will split in two but hopefully you can
put the pieces back together again.

Of course, as the spring I-D stands, then the registry will not be
updated with TBD5 and TBD6 but doubtless that will be fixed.

Note that in the spring I-D s.5.1 and s.5.3, OSPF and ISIS are 1 and 2
respectively while in s.6 they must be something different; all designed
to increase the probability of error:-)

Finally, "Sub-TLVs for TLV Types 1, 16 and 21" sub-registry will be an
obvious reference to an MPLS expert, less so to the average reader.

Sorry about misleading you earlier.  As we always say, I-Ds are a work
in progress.

Tom Petch

Mustapha.

> -----Original Message-----
> From: t.petch [mailto:[e-mail]]
> Sent: Friday, November 25, 2016 6:25 AM
> To: Aissaoui, Mustapha (Nokia - CA) <[e-mail]>;
> [e-mail]
>
> ----- Original Message -----
> From: "Aissaoui, Mustapha (Nokia - CA)" <[e-mail]>
> To: <[e-mail]>
> Sent: Thursday, November 24, 2016 10:05 PM
>
> Dear all,
> Can someone point me to where are held the IANA allocation for the
values in the
> 'protocol' field of the Label Stack Sub-TLV of the Downstream Detailed
Mapping
> TLV?
>
> There is draft-ietf-mpls-spring-lsp-ping-01 which is adding IS-IS and
OSPF as new
> values into this field but I fail to find where these are maintained.
>
> <tp>
>
> My reading would be that there is no such registry.  The new sub-TLV
appear at
>
http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-p
> arameters.xml#sub-tlv-1-16-21
> where for e.g. 34 the reference is to the I-D that you cite, with no
more details.
>
> Not all names and numbers appear in an IANA registry; setting up and
maintaining
> a registry takes work and sometimes it is not worth it.  If the only
use is local to the
> one field and only in the one RFC, then it may not be worth it.
>
> Tom Petch
>
> Regards,
> Mustapha.
>
>
>
> ----------------------------------------------------------------------
--
> --------
>
>
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls
> >