Hi Tom,
Many thanks for your comments!
Please see my reply inline with [Mach]
Best regards,
Mach
________________________________________
From: ietf-bounces(_at_)ietf(_dot_)org [ietf-bounces(_at_)ietf(_dot_)org] on
behalf of t.p. [daedulus(_at_)btconnect(_dot_)com]
Sent: Saturday, November 03, 2012 2:05
To: ietf(_at_)ietf(_dot_)org
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-ipv6-pw-lsp-ping-03.txt>
(LabelSwitched Path (LSP) Ping for IPv6 Pseudowire FECs) toProposed
Standard
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."
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].
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 :-)
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(_at_)ietf(_dot_)org>
To: "IETF-Announce" <ietf-announce(_at_)ietf(_dot_)org>
Cc: <mpls(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org mailing lists by 2012-11-09. Exceptionally, comments
may
be
sent to iesg(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls