Re: [mpls] Last Call: <draft-ietf-mpls-ipv6-pw-lsp-ping-03.txt>(LabelSwitched Path (LSP) Ping for IPv6 Pseudowire FECs) toProposed Standard

More thoughts inline <tp> three times (and apologies for the slow
response).

----- Original Message -----
From: "Mach Chen" <mach.chen@huawei.com>
To: "t.p." <daedulus@btconnect.com>; <ietf@ietf.org>
Sent: Wednesday, November 07, 2012 12:24 PM

Hi Tom,
Many thanks for your comments!
Please see my reply inline with [Mach]

Best regards,
Mach
________________________________________
From: ietf-bounces@ietf.org [ietf-bounces@ietf.org] on behalf of t.p.
[daedulus@btconnect.com]
Sent: Saturday, November 03, 2012 2:05
To: ietf@ietf.org

I worry about the allocation of sub-TLVs in this I-D.

It calls for
"The following Sub-TLV changes, which comprise three updates and two
   additions, are made for two TLV Types in the aforementioned sub-
   registry: TLV Type 1 for "Target FEC Stack", and TLV Type 21 for
   "Reply Path"."
and it is the Type 21 that worries me.

[Mach] Since draft-ietf-mpls-return-path-specified-lsp-ping has already
defined the rule and policy on how to inhirent the sub-TLVs from type 1
TLV, IMHO, here it may be no need to explicitly mention how to registry
the sub-TLVs for Type 21. So, how about this:
"The following Sub-TLV changes, which comprise three updates and two
additions, are made for TLV Type 1."

<tp>
I do not see this rule defined in draft-ietf-mpls-return-path-specified,
at least, not for any sub-TLVs that may be defined in future for Type 1
TLVs, that is, that I-D covers the present but not the future and that
is what I worry about.  The ipv6 I-D as initially written did not take
account of return-path-specified and vice versa, so I expect this
situation to recur and do not see a good solution to it.
</tp>

IANA has, for Type 21,

Reply Path (TEMPORARY - expires 2012-01-20)
[draft-ietf-mpls-return-path-specified-lsp-ping]

and I am unclear what the rules are about updates to expired, TEMPORARY,
allocations.

[Mach] As Loa pointed out, the current IANA registry for Type 21 TLV is
not reflecting the proposal in
[draft-ietf-mpls-return-path-specified-lsp-ping].

<tp>
Yes, and my reading is that the removal of temporary allocations is (yet
another) duty of the WG chair, so doubtless that will be taken care
of:-)
</tp>

I worry too that
[draft-ietf-mpls-return-path-specified-lsp-ping]
while confirming the reservation of Type 21 takes a different tack for
sub-TLVs, namely
"
According to the guidelines defined in [RFC5226], the sub-TLV range
   of Reply Path TLV are partitioned as following:
   0-31743 - Reserved, and MUST NOT be allocated."
so quite what this I-D will do to that I-D worries me.

[Mach] This is intended for the Type 21 TLV to have a common part code
range shared with Type 1 TLV and a TLV specific code range for its own
dedicaed sub-TLV. I think we should have an agreement on this solution
:-)

<tp>
Yes, we have long had agreement on the general idea of the solution but
it is not clear to me that the current wording got that message across,
for example to the AD, in which case we need better wording.  I realise
that this has come up on the MPLS list but I am unsure what the proposed
wording now is.  In fact, I am unclear whether the change proposed in
return-path-specified is intended to apply to all TLVs, present and
future - I think that it should, for safety, but the wording is unclear
to me on that point

Which point is of course nothing to do with the IETF Last Call of ipv6,
no need to mention it there, but it seems better to keep it on one
thread for the moment.

</tp>

Best regards,
Mach

And I worry yet more that other I-Ds, such as
draft-zjns-mpls-lsp-ping-relay-reply-00
are heading down the track with further updates in this area of the MPLS
namespace (except that this particular one seems to have abandoned
sub-TLVs).

Tom Petch

----- Original Message -----
From: "The IESG" <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
Cc: <mpls@ietf.org>
Sent: Wednesday, October 24, 2012 9:31 PM

>
> The IESG has received a request from the Multiprotocol Label Switching
WG
> (mpls) to consider the following document:
> - 'Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs'
>   <draft-ietf-mpls-ipv6-pw-lsp-ping-03.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2012-11-09. Exceptionally, comments may
be
> sent to iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>    Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP)
Ping
>    and traceroute mechanisms are commonly used to detect and isolate
>    data plane failures in all MPLS LSPs including Pseudowire (PW)
LSPs.
>    The PW LSP Ping and traceroute elements, however, are not specified
>    for IPv6 address usage.
>
>    This document extends the PW LSP Ping and traceroute mechanisms so
>    they can be used with IPv6 PWs, and updates RFC 4379.
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-pw-lsp-ping/
>
> IESG discussion can be tracked via
>
http://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-pw-lsp-ping/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>