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

Tom,
Since the Downstream Mapping TLV is deprecated in draft-ietf-mpls-rfc4379bis-09.txt, then draft-ietf-mpls-spring-lsp-ping should be only be discussing changes required to the Downstream Detailed Mapping (DDMAP) TLV 20 and should be referencing draft-ietf-mpls-rfc4379bis-09.txt indeed.

As for the following:
"
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-parameters.xml#sub-tlv-20 
"

You see my issue, from this URL link it appears that IANA is not maintaining the values for the 'protocol' field of the Label stack sub-TLV 2 of DDMAP TLV 20. Now draft-ietf-mpls-spring-lsp-ping is adding protocol values 5 (OSPF) and 6 (ISIS) but it cannot action IANA because it does not maintain the 'protocol' field values.

Mustapha.

> -----Original Message-----
> From: t.petch [mailto:ietfc@btconnect.com]
> Sent: Friday, November 25, 2016 12:37 PM
> To: Aissaoui, Mustapha (Nokia - CA) <mustapha.aissaoui@nokia.com>;
> mpls@ietf.org
> Subject: Re: [mpls] Question on draft-ietf-mpls-rfc4379bis-09.txt
> 
> ----- Original Message -----
> From: "Aissaoui, Mustapha (Nokia - CA)" <mustapha.aissaoui@nokia.com>
> To: "t.petch" <ietfc@btconnect.com>; <mpls@ietf.org>
> 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:ietfc@btconnect.com]
> > Sent: Friday, November 25, 2016 6:25 AM
> > To: Aissaoui, Mustapha (Nokia - CA) <mustapha.aissaoui@nokia.com>;
> > mpls@ietf.org
> >
> > ----- Original Message -----
> > From: "Aissaoui, Mustapha (Nokia - CA)" <mustapha.aissaoui@nokia.com>
> > To: <mpls@ietf.org>
> > 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
> > > mpls@ietf.org
> > > https://www.ietf.org/mailman/listinfo/mpls
> > >