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

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 22 Oct 2012 15:44:33 +0100

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 22 Oct 2012 21:12:02 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Adrian Farrel
> Sent: 22 October 2012 15:45
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [mpls] One last problem with
draft-ietf-mpls-return-path-specified-lsp-
> ping
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Mach Chen <[email-masked]>
Date: Tue, 23 Oct 2012 01:49:55 +0000

Hi Adrian,

>    be used in the Reply Path TLV and are not to be carried in

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:[email-masked]]
> 发送时间: 2012年10月22日 22:45
> 收件人: [email-masked]
> 抄送: [email-masked]; [email-masked]
> 主题: One last problem with draft-ietf-mpls-return-path-specified-lsp-ping
>

---

From: t.petch <[email-masked]>
Date: Tue, 23 Oct 2012 12:43:05 +0100

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

> > 收件人:
[email-masked]
> > 主题: One last problem with
draft-ietf-mpls-return-path-specified-lsp-ping
> > the new Reply Path TLV. The reason I thought this is that the
document
> > discusses
> > 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