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

["Aissaoui, Mustapha (Nokia - CA)" <[e-mail]>]

Hi Mach,
I am not as knowledgeable of the process but it seems that making the update to draft-ietf-mpls-rfc4379bis-09.txt to request a IANA registry for the 'protocol' field would make sense. Then, draft-ietf-mpls-spring-lsp-ping would add the additional values to the already created registry.

Mustapha.

> -----Original Message-----
> From: Mach Chen [mailto:[e-mail]]
> Sent: Saturday, November 26, 2016 1:33 AM
> To: Aissaoui, Mustapha (Nokia - CA) <[e-mail]>; t.petch
> <[e-mail]>; [e-mail]
> Subject: RE: [mpls] Question on draft-ietf-mpls-rfc4379bis-09.txt 
> 
> Hi Mustapha and Tom,
> 
> Good catch, Mustapha!
> 
> Indeed, there is no such a registry request for the protocol of the label Stack sub-
> TLV in the original 4379 and this bis document and it should have been one IMHO.
> 
> I guess when wrote and published rfc4379, the authors might believe that the listed
> protocols (Unknown, Static, BGP, LDP, RSVP-TE) are sufficient and cover all
> cases and no need for an IANA registry. But obviously Segment Routing is an
> exception :-). It's a pity we did not find it when do the bis document.
> 
> The 4379bis has already been in the RFC Queue, seems it's a bit late to update
> document. I see there are two ways to address the issue, 1) to ask the RFC editor
> to update bis document directly 2) or request such a registry in draft-ietf-mpls-
> spring-lsp-ping.
> 
> Best regards,
> Mach
> 
> > -----Original Message-----
> > From: mpls [mailto:[e-mail]] On Behalf Of Aissaoui,
> > Mustapha (Nokia - CA)
> > Sent: Saturday, November 26, 2016 5:33 AM
> > To: t.petch; [e-mail]
> > Subject: 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
> > -par
> > ameters.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:[e-mail]]
> > > Sent: Friday, November 25, 2016 12:37 PM
> > > To: Aissaoui, Mustapha (Nokia - CA) <[e-mail]>;
> > > [e-mail]
> > > Subject: Re: [mpls] Question on draft-ietf-mpls-rfc4379bis-09.txt
> > >
> > > ----- 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-pi
> > > ng
> > > -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-pi
> > > ng
> > > -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
> > > > >
> >
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls