RE: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp-ping-12

["Roni Even" <[e-mail]>]

Hi,
This is OK . I have no concerns
Roni

> -----Original Message-----
> From: Loa Andersson [mailto:[e-mail]]
> Sent: 29 August, 2013 2:46 PM
> To: Roni Even
> Cc: 'Mach Chen'; draft-ietf-mpls-return-path-specified-lsp-
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Gen-ART LC review of
draft-ietf-mpls-return-path-specified-lsp-
> ping-12
> 
> 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
> 
> 
> 
> On 2013-08-29 12:24, Roni Even wrote:
> > 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
> >
> 
> --
> 
> 
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Huawei Technologies (consultant)     phone: [phone]