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

["Adrian Farrel" <[e-mail]>]

OK. Loa points out to me on IM that (not for the first time) I don't know what I
am talking about.
Think I read the registry not the RFC and got the allocation policies wrong
(again).

Back to the drawing board.

Adrian

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Adrian Farrel
> Sent: 22 October 2012 15:45
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: [mpls] 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
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls