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

From: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>
Date: Thu, 24 Nov 2016 22:05:40 +0000

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.

Regards,
Mustapha.

---

From: t.petch <[email-masked]>
Date: Fri, 25 Nov 2016 11:24:59 +0000

----- Original Message -----
From: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>
To: <[email-masked]>
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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>
Date: Fri, 25 Nov 2016 16:28:33 +0000

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.

Mustapha.

> -----Original Message-----
> From: t.petch [mailto:[email-masked]]
> Sent: Friday, November 25, 2016 6:25 AM
> To: Aissaoui, Mustapha (Nokia - CA) <[email-masked]>;
> [email-masked]
> Subject: Re: [mpls] Question on draft-ietf-mpls-rfc4379bis-09.txt
> 
> 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
> 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.
> 
> 
>

---

From: t.petch <[email-masked]>
Date: Fri, 25 Nov 2016 17:36:47 +0000

----- Original Message -----
From: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>
To: "t.petch" <[email-masked]>; <[email-masked]>
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.

> Can someone point me to where are held the IANA allocation for the
values in the
> There is draft-ietf-mpls-spring-lsp-ping-01 which is adding IS-IS and
OSPF as new
appear at
more details.
> Not all names and numbers appear in an IANA registry; setting up and
maintaining

---

From: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>
Date: Fri, 25 Nov 2016 21:33:17 +0000

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.

> Sent: Friday, November 25, 2016 12:37 PM
> 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.
> 
> 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.
> 
> Mapping (which is what you asked about) or both? I think that the authors may be
> a little confused here.
> 
> 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
> 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.
>

---

From: Mach Chen <[email-masked]>
Date: Sat, 26 Nov 2016 06:32:54 +0000

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 

> From: mpls [mailto:[email-masked]] On Behalf Of Aissaoui, Mustapha
> (Nokia - CA)
> Sent: Saturday, November 26, 2016 5:33 AM
> To: t.petch; [email-masked]
> 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:
> "
> 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.
> 
> > 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.
> >
> > 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.
> >
> > TBD5 and TBD6 to be given values.  But is this section referring to
> > the Downstream Mapping TLV of RFC4379 or the TLV20 Downstream
> Detailed
> > 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
> > which URL my pesky e-mail client will split in two but hopefully you
> > can put the pieces back together again.
> >
> > respectively while in s.6 they must be something different; all
> > designed to increase the probability of error:-)
> >
> > > 'protocol' field of the Label Stack Sub-TLV of the Downstream
> > > Detailed
> > Mapping
> > > TLV?
> > >
> > > --------------------------------------------------------------------
> > > --
> > --
> > > --------
> > >
> > >

---

From: t.petch <[email-masked]>
Date: Sat, 26 Nov 2016 12:37:50 +0000

----- Original Message -----
From: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>
To: "t.petch" <[email-masked]>; <[email-masked]>
Sent: Friday, November 25, 2016 9:33 PM

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:
"

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.

<tp>
Well, no, I disagree with that interpretation.  IANA has not been asked
to do anything and so has not done anything so IANA is doing just fine.

IANA assigns values once an I-D has gone through its stages, WG Last
Call, AD Review, IETF Last Call, IESG Review and is on its way to the
RFC Editor; only then is it safe to assume that the I-D is stable so we
are a long way off that, and in fact, the I-D at present does not even
contain a request to IANA to assign a value so that will need fixing
sooner or later if IANA is to assign a value.

There is an exception to this process, when a value is required early on
to permit interoperability testing, and the IANA website tells you that
this has been done for subTLV 34, 35, 36.

But this has NOT been done for values for OSPF and ISIS for TLV Type 20
and you would be very wrong IMHO to assume at this stage what those
values might be.

Tom Petch

Mustapha.

> So, draft-ietf-mpls-spring-lsp-ping when it becomes RFC should state
that it is
> Mmmm my first reply was too hasty; wrong in fact.  I was looking at
spring-lsp-
> Stepping back, if all that an I-D or RFC does is add entries to
existing registries,
> and if that is not an update, I do not know what is:-)  Should this
also apply to
> Looking more closely at the I-D, I think that s.10.1 IANA
Considerations are ... well
> TBD5 and TBD6 to be given values.  But is this section referring to
the
> Mapping (which is what you asked about) or both? I think that the
authors may be
> But the Downstream Detailed Mapping TLV has a Label Stack subTLV so
adding
> which URL my pesky e-mail client will split in two but hopefully you
can put the
> Of course, as the spring I-D stands, then the registry will not be
updated with TBD5
> Note that in the spring I-D s.5.1 and s.5.3, OSPF and ISIS are 1 and 2
respectively
> Finally, "Sub-TLVs for TLV Types 1, 16 and 21" sub-registry will be an
obvious
in progress.
Detailed

---

From: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>
Date: Mon, 28 Nov 2016 13:48:37 +0000

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.

> From: Mach Chen [mailto:[email-masked]]
> Sent: Saturday, November 26, 2016 1:33 AM
> To: Aissaoui, Mustapha (Nokia - CA) <[email-masked]>; t.petch
> <[email-masked]>; [email-masked]
> 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
> 
> > From: mpls [mailto:[email-masked]] On Behalf Of Aissaoui,
> > Mustapha (Nokia - CA)
> > 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
> > maintaining the values for the 'protocol' field of the Label stack sub-TLV 2 of
> DDMAP TLV 20.
> > (ISIS) but it cannot action IANA because it does not maintain the
> > 'protocol' field values.
> >
> > Mustapha.
> >
> > > 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.
> > > 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.
> > >
> > > 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
> > >
> > > 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
> > > 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.
> > >
> > > http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-pi
> > > ng
> > > -p
> > > > a registry takes work and sometimes it is not worth it.  If the
> > > > only
> > > use is local to the

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 28 Nov 2016 13:53:50 +0000

Thank you Mustapha for catching these, and Tom and Mach for the follow-ups.

There are three changes needed to draft-ietf-mpls-spring-lsp-ping based based on this discussion:

  1.  In Section 10.1, update the references to {Section 4.1, Section 4.2, Section 4.1} -> {Section 5.1, Section 5.2, Section 5.1}
  2.  Create a Section 10.2, create a registry for the “Protocol field of the Label Stack Sub-TLV of the Downstream Detailed Mapping TLV”, registering values 0-4, and asking for TBD5 and TBD6. If this happens in this draft instead of 4379bis, I believe it is OK.
  3.  Create a Section 10.3, requesting error code TBD.

Thanks!

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

On Nov 24, 2016, at 5:05 PM, Aissaoui, Mustapha (Nokia - CA) <[email-masked]<mailto:[email-masked]>> wrote:

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?

Regards,
Mustapha.
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>
Date: Mon, 28 Nov 2016 14:55:33 +0000

Hi Carlos,
You meant: {Section 5.1, Section 5.2, Section 5.*3*} .

Also, you need to reference draft-ietf-mpls-rfc4379bis-09.txt instead of RFC 4379 throughout the document and replace DSMAP TLV with DDMAP TLV (RFC 6424).

I have a few more comments on draft-ietf-mpls-spring-lsp-ping-01 which I will be sending in a separate message.

Regards,
Mustapha.

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Monday, November 28, 2016 8:54 AM
To: Aissaoui, Mustapha (Nokia - CA) <[email-masked]>
Cc: [email-masked]
Subject: Re: [mpls] Question on draft-ietf-mpls-rfc4379bis-09.txt

Thanks!

—

Dear all,

Regards,
Mustapha.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 28 Nov 2016 15:31:01 +0000

Hi, Mustapha,

On Nov 28, 2016, at 9:55 AM, Aissaoui, Mustapha (Nokia - CA) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,

Yes, sorry for the typo.

Indeed. We were waiting for 4379bis to be approved, now is the right time.

We are planning on making all these changes and submit a new rev.

Look forward.

Thanks,

— Carlos.

Regards,
Mustapha.

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Monday, November 28, 2016 8:54 AM
To: Aissaoui, Mustapha (Nokia - CA) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Question on draft-ietf-mpls-rfc4379bis-09.txt

Thanks!

—

Dear all,

Regards,
Mustapha.

---

From: t.petch <[email-masked]>
Date: Tue, 29 Nov 2016 10:33:42 +0000

Carlos

One other point I raised was that spring-lsp refers throughout to
Downstream Mapping TLV
and not to
Downstream Detailed Mapping TLV

Mustapha assumed that these should all be changed.  I am unsure about
this - is spring-lsp expected to work with Downstream Mapping TLV as
specified in RFC4379?  If not, then I think that spring-lsp should spell
that out.

Either way, the wording changes to spring-lsp need some thought since
Downstream Mapping TLV does not have subTLVs and Downstream Detailed
Mapping TLV does.

Tom Petch

----- Original Message -----
From: "Carlos Pignataro (cpignata)" <[email-masked]>
To: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, November 28, 2016 1:53 PM

>   1.  In Section 10.1, update the references to {Section 4.1, Section
4.2, Section 4.1} -> {Section 5.1, Section 5.2, Section 5.1}
>   2.  Create a Section 10.2, create a registry for the “Protocol field
of the Label Stack Sub-TLV of the Downstream Detailed Mapping TLV”,
registering values 0-4, and asking for TBD5 and TBD6. If this happens in
this draft instead of 4379bis, I believe it is OK.
> On Nov 24, 2016, at 5:05 PM, Aissaoui, Mustapha (Nokia - CA)
> 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?

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 29 Nov 2016 11:18:07 +0000

Hi Tom,

Indeed. My reply implied (although it didn't spell out) that this is specified for the DDMAP (and not the deprecated DSMAP). That's why the protocol field definition happens in a sub-TLV. 

Let us make the changes in the doc and then we can discuss over something more concrete. 

Thanks!

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

> On Nov 29, 2016, at 05:51, t.petch <[email-masked]> wrote:
> 
> Carlos
> 
>> ―

---

From: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>
Date: Wed, 30 Nov 2016 13:37:36 +0000

Tom and Carlos,
Thanks. It seems we are in sync.

Mustapha.

> Sent: Tuesday, November 29, 2016 6:18 AM
> To: t.petch <[email-masked]>
> Cc: Aissaoui, Mustapha (Nokia - CA) <[email-masked]>;
> [email-masked]
> Indeed. My reply implied (although it didn't spell out) that this is specified for the
> DDMAP (and not the deprecated DSMAP). That's why the protocol field definition
> happens in a sub-TLV.
> 
> > Downstream Mapping TLV and not to Downstream Detailed Mapping TLV
> >
> > specified in RFC4379?  If not, then I think that spring-lsp should
> > spell that out.
> >
> >>  2.  Create a Section 10.2, create a registry for the "Protocol field
> > of the Label Stack Sub-TLV of the Downstream Detailed Mapping TLV",
> > registering values 0-4, and asking for TBD5 and TBD6. If this happens
> > in this draft instead of 4379bis, I believe it is OK.
> >> "Sometimes I use big words that I do not fully understand, to make
> > myself sound more photosynthesis."
> >>