Adrian and authors, Can we also close on the IANA assignment for the new TLVs and specifically for the Dual-Stack Capability TLV? I assume this will be drawn from the Common Hello Parameters range of the LDP TLV Type Name Space. The next available value is 0x0409. I appreciate if you could confirm this value. Regards, Mustapha. > -----Original Message----- > From: mpls [mailto:mpls-bounces@xxxxxxxx] On Behalf Of Aissaoui, Mustapha > (Mustapha) > Sent: Tuesday, December 16, 2014 12:22 PM > To: ietf@xxxxxxxx; IETF-Announce > Cc: mpls@xxxxxxxx > Subject: Re: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to LDP for > IPv6) to Proposed Standard > > Hi Adrian and all, > I was the one who raised the interop issues we found while testing our > implementation of LDP IPv6 against existing and deployed implementations. I > proposed a simple method of using the existing FEC advertisement capability at > the session level as a way for an LSR to detect if an implementation support LDP > IPv6 FECs and IPv6 addresses. This existing FEC advertisement capability at > session level is defined in draft-ietf-mpls-ldp-ip-pw-capability-08 but with the > limitation that it can be used only to disable support of IPv6 FECs in LDP > Initialization Message; we proposed to generalize the method to also indicate > explicit support for IPv6 FECs and IPv6 Addresses in LDP Initialization Message. > This method is safe and was also used with mLDP P2MP and MP2MP FECs when > they were introduced. The intent here is that all session level capabilities in LDP > should follow RFC 5561 approach. > > There was an individual contributor which supported the proposal on the mailing > list but the authors chose to ignore it and went with a proposal which overloaded > the meaning of the dual-stack capability TLV. Regardless of the merit of either > method, the discussion on the MPLS mailing list was not closed properly from my > perspective. > > Now here is the concern I raised with using the dual-stack capability. Not only this > TLV is an adjacency level feature which is has nothing to do with FEC capability > advertisement, but it is introducing complexity in the implementation which now > has to check dual-stack capability for *each* adjacency to the peer *and* the > session level FEC capability to decide what the peer is capable of at the *session > level*. > > Having said that, I want to keep the spirit of cooperation and make sure we get this > draft published. To that effect, I am not opposed to its publication as long as the > following points are clarified in the draft since now FEC capability of the LSR peer > is determined by a check a both adjacency and session levels: > > 1. The draft is missing the behavior when multiple adjacencies exist to the same > LSR and the peer LSR advertised the dual-stack capability only over a subset of > these Hello adjacencies. > I assume here the peer LSR is considered to be dual-stack capable as soon as any > of the Hello adjacencies includes the dual-stack capability. This would allow a > hitless upgrade scenario from an older implementation to one which complies to > this draft > > 2. Similarly, what would be the behavior if a hello adjacency changes from sending > the dual-stack capability to not sending it? This would be for example in a hitless > downgrade to a version of LDP which does not comply to this draft. > I assume here that the session must be bounced since the LSRs need a clean state > to not send IPv6 addresses and IPv6 FECs. > > 3. The document defines 2 values for the dual-stack capability TR. It does not > mention the behavior when an unknown value is received. > Will that be considered a fatal error? > > 4. The draft is missing the behavior of when the peer LSR does not advertise the > dual-stack capability in all the Hello adjacencies but it advertised the enabling or > disabling of the IPv6 prefix FEC capability in the session initialization message. > I assume here that the absence of the dual-stack capability overrides any session > level IPv6 FEC prefix capability advertisement. > > 5. The draft is missing the behavior of when the peer LSR does not advertise the > dual-stack capability in all the Hello adjacencies but it advertised the enabling of > the IPv6 prefix FEC capability in the session Capability message. > I assume the same behavior as in (4) applies here. > > Regards, > Mustapha. > > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@xxxxxxxx] On Behalf Of The IESG > > Sent: Thursday, December 04, 2014 2:37 PM > > To: IETF-Announce > > Cc: mpls@xxxxxxxx > > Subject: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates > > to LDP for IPv6) to Proposed Standard > > > > > > The IESG has received a request from the Multiprotocol Label Switching > > WG > > (mpls) to consider the following document: > > - 'Updates to LDP for IPv6' > > <draft-ietf-mpls-ldp-ipv6-14.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@xxxxxxxx mailing lists by 2014-12-18. Exceptionally, comments may > > be sent to iesg@xxxxxxxx instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > The Label Distribution Protocol (LDP) specification defines > > procedures to exchange label bindings over either IPv4, or IPv6 or > > both networks. This document corrects and clarifies the LDP behavior > > when IPv6 network is used (with or without IPv4). This document > > updates RFC 5036 and RFC 6720. > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > _______________________________________________ > > mpls mailing list > > mpls@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@xxxxxxxx > https://www.ietf.org/mailman/listinfo/mpls