Subject: Re: [Gen-art] Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp-ping-12

From: "Roni Even" <[email-masked]>
Date: Thu, 29 Aug 2013 12:21:23 +0300

Hi,
I am not sure you responded to my latest email.

Having the policy for TLV type 1 here is not enough in my view since I only
look at RFC4379 and create a new TLV type I will not know that I have to
register it also for the type 21 if it will not be mentioned

As for the vendor specific see my other email
Roni

> -----Original Message-----
> From: Mach Chen [mailto:[email-masked]]
> Sent: 29 August, 2013 11:33 AM
> To: Roni Even; draft-ietf-mpls-return-path-specified-lsp-
> [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Gen-ART LC review of
draft-ietf-mpls-return-path-specified-lsp-
> ping-12
> 
> Hi Roni,
> 
> Thanks for your detailed review and comments!
> 
> Please see my reply inline...
> 
> > From: Roni Even [mailto:[email-masked]]
> > Sent: Wednesday, August 28, 2013 9:06 PM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: Gen-ART LC review of
> > draft-ietf-mpls-return-path-specified-lsp-ping-12
> >
> > I am the assigned Gen-ART reviewer for this draft. For background on
> > Gen-ART, please see the FAQ at
> > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> > Please resolve these comments along with any other Last Call comments
> > you may receive.
> > Document: draft-ietf-mpls-return-path-specified-lsp-ping-12
> > Reviewer: Roni Even
> > Review Date:2013-8-28
> > IETF LC End Date: 2013-9-4
> > IESG Telechat date:
> >
> > Summary: This draft is almost ready for publication as a standard track
RFC.
> >
> >
> > Major issues:
> > Minor issues:
> > I am not clear on the sub-TLV in section 6.2 1. If a new sub-TLV is
> > defined for TLV type 1 do they need also to be added to TLV type 21.
> > This should be clear, and if there is some relation I think it should
> > be reflected in the IANA registry for TLV type 1
> 
> Yes, type 21 TLV intends to reuse existing and future defined sub-TLVs for
> type TLV 1. And in Section 3.3, it has already stated this, it says:
> 
> "The Target FEC sub-TLVs defined in [RFC4379] provide a good way to
>    identify a specific return path.  The Reply Path TLV can carry any
>    sub-TLV defined for use in the Target FEC Stack TLV that can be
>    registered."
> 
> So, for Section 6.2, to make it cleaner and more explicit, how about this
> change:
> 
> Old:
> 
> " No assignments of sub-TLVs in the range of 0-16383 and 32768-49161
>    are made directly for TLV Type 21, sub-TLVs in these ranges are
>    copied from the assignments made for TLV Type 1. Assignments of
sub-..."
> 
> New:
> 
> " No assignments of sub-TLVs in the range of 0-16383 and 32768-49161
>    are made directly for TLV Type 21, sub-TLVs in these ranges are
>    copied from the assignments (including existing and future allocations)
>    made for TLV Type 1. Assignments of sub-..."
> 
> 
> > 2. For the vendor or private use why a difference policy than the rest
> > of the sub-TLV registry
> 
> This document does not make any changes to the "Vendor and Private use"
> definition, range and policy as defined in RFC4379. In RFC4379, it's
policy is
> defined different from other ranges.
> 
> >
> > Nits/editorial comments:
> > 1. In section 3.4 I assume that "TC" is traffic class. It will be good
> > to expand and have reference.
> 
> OK, will fix it when all last call comments received.
> 
> Best regards,
> Mach

---

From: "Roni Even" <[email-masked]>
Date: Thu, 29 Aug 2013 13:24:38 +0300

Hi,
This text is OK if one wants to implement this draft.
My concern was about the consistency of the IANA registration so that if
someone defines a new TLV type 1 based on RFC4379, IANA will know that it
must update also the registry for TLV type 21. If you see no such problem, I
have no concerns
Roni

> Sent: 29 August, 2013 1:05 PM
> How about this:
>     copied from the assignments made for TLV Type 1 and kept the same
>     as that for TLV Type 1. All sub-TLVs in these ranges (include existing
>     and future defined) defined for TLV Type 1 apply to TLV Type 21.
>     Assignments of sub-..."
> 
> Best regards,
> Mach
> 
> > Sent: Thursday, August 29, 2013 5:21 PM
> > To: Mach Chen;
> > [email-masked]
> > Having the policy for TLV type 1 here is not enough in my view since I
> > only look at RFC4379 and create a new TLV type I will not know that I
> > have to register it also for the type 21 if it will not be mentioned
> >
> > As for the vendor specific see my other email Roni
> >
> > > > To:
> > > > [email-masked]
> > > > I am the assigned Gen-ART reviewer for this draft. For background
> > > > on Gen-ART, please see the FAQ at
> > > > Please resolve these comments along with any other Last Call
> > > > comments you may receive.
> > > > I am not clear on the sub-TLV in section 6.2 1. If a new sub-TLV
> > > > is defined for TLV type 1 do they need also to be added to TLV type
21.
> > > > This should be clear, and if there is some relation I think it
> > > > should be reflected in the IANA registry for TLV type 1
> > >
> > > Yes, type 21 TLV intends to reuse existing and future defined
> > > sub-TLVs for type TLV 1. And in Section 3.3, it has already stated
this, it
> says:
> > > > 2. For the vendor or private use why a difference policy than the
> > > > rest of the sub-TLV registry
> > >
> > > > 1. In section 3.4 I assume that "TC" is traffic class. It will be
> > > > good to expand and have reference.
> > >

---

From: Loa Andersson <[email-masked]>
Date: Thu, 29 Aug 2013 13:46:17 +0200

Roni,

tnx - the authors should add words in the IANA section requesting that
IANA add this the pointed in the registry; they normally do anyway, but
writing it down should not be a problem.

As for "Vendor Private" RFC 4379 says:

   "Values from "Vendor Private" ranges MUST NOT be registered with IANA;
    however, the message MUST contain an enterprise code as registered
    with the IANA SMI Private Network Management Private Enterprise
    Numbers.  For each name space that has a Vendor Private range, it
    must be specified where exactly the SMI Private Enterprise Number
    resides; see below for examples.  In this way, several enterprises
    (vendors) can use the same code point without fear of collision."

The way I read this is that the paragraph does two things (1) defines
the allocation policy (in this case that "vendor private" won't be
assigned by IANA) and (2) put a restriction on the "vendor private"
(sub-)TLVs; they must contain a "private enterprise number".

Up to now I've thought the restriction on the format was global for
all "vendor private" sub-TLVs that are used by TLV for LSP Ping.
However we put words to the same effect in e.g. 6424, wo there is no
reason not to do it here also. A pointer to RFC4379 should be enough
e.g.:

"For the vendor private sub-TLVs defined for this document, the
same allocation policies and requirement on the sub-TLV format that is
specified for vendor private sub-TLVs in RFC4379 [RFC4379] appliacable."

Would that cover you concern?

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Mach Chen <[email-masked]>
Date: Thu, 29 Aug 2013 08:32:53 +0000

Hi Roni,

> Summary: This draft is almost ready for publication as a standard track RFC.
> 
> 
> Major issues:
> Minor issues:

Yes, type 21 TLV intends to reuse existing and future defined sub-TLVs for type TLV 1. And in Section 3.3, it has already stated this, it says:

So, for Section 6.2, to make it cleaner and more explicit, how about this change:

Old:

" No assignments of sub-TLVs in the range of 0-16383 and 32768-49161
   are made directly for TLV Type 21, sub-TLVs in these ranges are
   copied from the assignments made for TLV Type 1. Assignments of sub-..."

New:

> 2. For the vendor or private use why a difference policy than the rest 

This document does not make any changes to the "Vendor and Private use" definition, range and policy as defined in RFC4379. In RFC4379, it's policy is defined different from other ranges. 

Best regards,
Mach

---

From: Mach Chen <[email-masked]>
Date: Thu, 29 Aug 2013 10:05:12 +0000

Hi Roni,

How about this:

Best regards,
Mach

> To: Mach Chen; [email-masked]

---

From: "Roni Even" <[email-masked]>
Date: Thu, 29 Aug 2013 15:49:03 +0300

Hi,
This is OK . I have no concerns
Roni

> From: Loa Andersson [mailto:[email-masked]]
> Sent: 29 August, 2013 2:46 PM
> To: Roni Even
> Cc: 'Mach Chen'; draft-ietf-mpls-return-path-specified-lsp-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Gen-ART LC review of
> tnx - the authors should add words in the IANA section requesting that
IANA
> add this the pointed in the registry; they normally do anyway, but writing
it
> down should not be a problem.
> 
> The way I read this is that the paragraph does two things (1) defines the
> allocation policy (in this case that "vendor private" won't be assigned by
> IANA) and (2) put a restriction on the "vendor private"
> Up to now I've thought the restriction on the format was global for all
> "vendor private" sub-TLVs that are used by TLV for LSP Ping.
reason
> not to do it here also. A pointer to RFC4379 should be enough
> e.g.:
> 
> "For the vendor private sub-TLVs defined for this document, the same
> allocation policies and requirement on the sub-TLV format that is
specified
> for vendor private sub-TLVs in RFC4379 [RFC4379] appliacable."
> 
> > My concern was about the consistency of the IANA registration so that
> > if someone defines a new TLV type 1 based on RFC4379, IANA will know
> > that it must update also the registry for TLV type 21. If you see no
> > such problem, I have no concerns Roni
> >
> >>> Having the policy for TLV type 1 here is not enough in my view since
> >>> I only look at RFC4379 and create a new TLV type I will not know
> >>> that I have to register it also for the type 21 if it will not be
> >>> mentioned
> >>>

---

From: t.p. <[email-masked]>
Date: Thu, 29 Aug 2013 16:33:04 +0100

Roni

I find it difficult to know whether to agree with you or not since there
is another "gorilla" operating in this namespace, namely
draft-andersson-mpls-lsp-ping-upd-00
which sort of gives the option of taking out the sub-TLV types of a TLV
Type into a separate registry which can then be referenced by the
specifications of several TLV Types.  This I-D formally calls for no
action by IANA, except that it implies a reorganisation of the
registries which IANA might well already have executed - certainly, the
registries no longer look the same as they did a few months ago although
that might also be a coincidence.

You make reference to the registry set up by RFC6426 but you should be
aware that what is now in the IANA registries is not what was there when
that RFC was approved; rather, it has changed as alluded to above..

If
draft-andersson-mpls-lsp-ping-upd-00
is approved, and my perception is that IANA assumes it has been, then
this, return-path I-D would appear to be barking up the wrong tree and
needs revising to reflect the new IANA structure, namely that it needs
to update
the title which already exists
Sub-TLVs for TLV Types 1 and 16
to become
Sub-TLVs for TLV Types 1 and 16 and 21
whereupon things start to fall into place

draft-andersson-mpls-lsp-ping-upd-00
also updates RFC4379 which, if accepted, means, I think, that this I-D
need not.

All very technically sound but we seem to have our processes upside
down.

There is of course a lengthy history to this that is not material to the
current discussion.

Tom Petch

----- Original Message -----
From: "Roni Even" <[email-masked]>
To: "'Mach Chen'" <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, August 29, 2013 11:24 AM
Subject: RE: Gen-ART LC review
ofdraft-ietf-mpls-return-path-specified-lsp-ping-12

> My concern was about the consistency of the IANA registration so that
if
> > > > > Summary: This draft is almost ready for publication as a
standard
> > > > > track
> > > > So, for Section 6.2, to make it cleaner and more explicit, how
about
> > > > this
> > > > This document does not make any changes to the "Vendor and
Private
> > use"

---

From: "Roni Even" <[email-masked]>
Date: Thu, 29 Aug 2013 21:15:06 +0300

HI,
I do not follow all the MPLS work, this Gen-ART review is done during the
IETF LC.  
I would think that your point should have been discussed in the WG before
sending the return path ping to publication.
BTW: I took a quick look at draft-andersson-mpls-lsp-ping-upd-00 third
paragraph of section 2 and I am not sure that the return path ping is
influenced since it does not use all the sub-tlv from tlv type 1 so it
should be a separate registry
Roni

> From: t.p. [mailto:[email-masked]]
> Sent: 29 August, 2013 6:33 PM
> Cc: [email-masked]; [email-masked]
> Subject: Re: Gen-ART LC review
ofdraft-ietf-mpls-return-path-specified-lsp-
> I find it difficult to know whether to agree with you or not since there
is
> another "gorilla" operating in this namespace, namely
Type
> into a separate registry which can then be referenced by the
specifications of
> several TLV Types.  This I-D formally calls for no action by IANA, except
that it
> implies a reorganisation of the registries which IANA might well already
have
> executed - certainly, the registries no longer look the same as they did a
few
> months ago although that might also be a coincidence.
> 
this,
> return-path I-D would appear to be barking up the wrong tree and needs
> revising to reflect the new IANA structure, namely that it needs to update
> the title which already exists Sub-TLVs for TLV Types 1 and 16 to become
Sub-
> TLVs for TLV Types 1 and 16 and 21 whereupon things start to fall into
place
> also updates RFC4379 which, if accepted, means, I think, that this I-D
need
> not.
> 
> All very technically sound but we seem to have our processes upside down.
> 
current
> discussion.
> To: "'Mach Chen'" <[email-masked]>; <draft-ietf-mpls-return-path-
> [email-masked]>