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

[Loa Andersson <[e-mail]>]

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]