Re: Gen-ART LC review ofdraft-ietf-mpls-return-path-specified-lsp-ping-12

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

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" <[e-mail]>
To: "'Mach Chen'" <[e-mail]>;
<[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Thursday, August 29, 2013 11:24 AM
Subject: RE: Gen-ART LC review
ofdraft-ietf-mpls-return-path-specified-lsp-ping-12


> 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
>
> > -----Original Message-----
> > From: Mach Chen [mailto:[e-mail]]
> > Sent: 29 August, 2013 1:05 PM
> > To: Roni Even; draft-ietf-mpls-return-path-specified-lsp-
> > [e-mail]
> > Cc: [e-mail]; [e-mail]
> > Subject: RE: Gen-ART LC review of
> draft-ietf-mpls-return-path-specified-lsp-
> > ping-12
> >
> > Hi Roni,
> >
> > How about this:
> >
> > " 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 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
> >
> > > -----Original Message-----
> > > From: Roni Even [mailto:[e-mail]]
> > > Sent: Thursday, August 29, 2013 5:21 PM
> > > To: Mach Chen;
> > > [e-mail]
> > > Cc: [e-mail]; [e-mail]
> > > Subject: RE: Gen-ART LC review of
> > > draft-ietf-mpls-return-path-specified-lsp-ping-12
> > >
> > > 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:[e-mail]]
> > > > Sent: 29 August, 2013 11:33 AM
> > > > To: Roni Even; draft-ietf-mpls-return-path-specified-lsp-
> > > > [e-mail]
> > > > Cc: [e-mail]; [e-mail]
> > > > 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:[e-mail]]
> > > > > Sent: Wednesday, August 28, 2013 9:06 PM
> > > > > To:
> > > > >
[e-mail]
> > > > > Cc: [e-mail]; [e-mail]
> > > > > 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
>
>