[mpls] 答复: One last problem with draft-ietf-mpls-return-path-specified-lsp-ping

[Mach Chen <[e-mail]>]

Hi Adrian,

> So, I *think* what you are asking for is:
> 1. A new top-level LSP Ping TLV called "Reply Path TLV"
>     Early allocation has assigned this value 21
> 2. The ability to carry any sub-TLV of the Target FEC Stack
>    top-level TLV as a sub-TLV of the Reply Path TLV
> 3. A way to "lock step" the two sub-TLV registries so that
>    new sub-TLVs that can be carried in the Target FEC Stack
>    TLV can also be carried in the Reply Path TLV
> 4. A way to create and register sub-TLVs that are only to
>    be used in the Reply Path TLV and are not to be carried in
>    the Target FEC Stack TLV

Yes, these are the targets that the I-D is trying to achieve, and the document redefines the "Vendor Private Use" range to achieve the target 4 above.

Best regards,
Mach

> -----邮件原件-----
> 发件人: Adrian Farrel [mailto:[e-mail]]
> 发送时间: 2012年10月22日 22:45
> 收件人: [e-mail]
> 抄送: [e-mail]; [e-mail]
> 主题: One last problem with draft-ietf-mpls-return-path-specified-lsp-ping
> 
> Thanks to the authors for a rapid turn-round on my review.
> We are almost there.
> 
> But the remaining issue is with the codepoints for the sub-TLVs of the Reply
> Path TLV. There seems to be some *massive* disconnect!
> 
> From the discussion of the 4379-defined "TLVs and sub-TLVs" sub-registry of the
> "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs)
> Ping Parameters - TLVs" registry in old versions of the I-D, I had assumed that
> you wanted to allow top-level TLVs from the registry to be used as sub-TLVs of
> the new Reply Path TLV. The reason I thought this is that the document
> discusses
> the allocation ranges for the top-level TLVs and says that new sub-TLVs of the
> Reply Path TLV that apply only to the Reply Path TLV must be allocated out of
> "safe" ranges - i.e. those ranges that cannot be allocated for top-level TLVs.
> 
> But when I look at the early allocations done in the registry (and presumably
> agreed by the authors) I see something completely different. What I see there
> is
> that the Reply Path TLV can carry as its own sub-TLVs those sub-TLVs that can
> be
> carried as sub-TLVs of the Target FEC Stack top-level TLV.
> 
> So, I *think* what you are asking for is:
> 1. A new top-level LSP Ping TLV called "Reply Path TLV"
>     Early allocation has assigned this value 21
> 2. The ability to carry any sub-TLV of the Target FEC Stack
>    top-level TLV as a sub-TLV of the Reply Path TLV
> 3. A way to "lock step" the two sub-TLV registries so that
>    new sub-TLVs that can be carried in the Target FEC Stack
>    TLV can also be carried in the Reply Path TLV
> 4. A way to create and register sub-TLVs that are only to
>    be used in the Reply Path TLV and are not to be carried in
>    the Target FEC Stack TLV
> 
> All of this has nothing to do with 4379 allocation polices or ranges applied to
> the top-level TLV registry.
> 
> If this is what we are trying to do, then:
> - we can delete the sections of text talking about TLV allocation
>    policies
> - we can introduce some text instructing IANA to lock-step the
>   registries of sub-TLVs
> - we can work out a policy that allows values used as sub-TLVs of
>   the Target FEC Stack TLV to be reserved so that they do not conflict
>   with allocations for sub-TLVs of the Reply Path TLV
> 
> So, step 1: please confirm that I have now (finally) understood what it is
> you're trying to achieve.
> 
> Sorry it has taken me so long to understand. Hopefully we can resolve this
> quickly from here on in.
> 
> Regards,
> Adrian