Hi Tom, Many thanks for your comments! Please see my reply inline with [Mach]
Best regards, Mach ________________________________________ From: [email protected] [[email protected]] on behalf of t.p. [[email protected]] Sent: Saturday, November 03, 2012 2:05 To: [email protected] 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" <[email protected]> To: "IETF-Announce" <[email protected]> Cc: <[email protected]> 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 > [email protected] mailing lists by 2012-11-09. Exceptionally, comments may be > sent to [email protected] 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 > [email protected] > https://www.ietf.org/mailman/listinfo/mpls >
