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

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

----- Original Message -----
From: "Mach Chen" <[e-mail]>
To: <[e-mail]>;
<[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Tuesday, October 23, 2012 2:49 AM
> 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.

Yes, I too think that this is, technically, broadly, what the I-D is
setting out to do.

With the benefit of hindsight, RFC4379 would have done better to define
a range of values for common sub-TLVs, likely to be used by several
TLVs; and a range of values for sub-TLVs which are TLV specific.  And a
requirement for future definers of sub-TLVs to be clear about the usage
of any common ones.  Other IANA registries have this concept.

So I see this I-D as moving towards that sort of registry.

Tom Petch

> 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
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>