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(_at_)ietf(_dot_)org] On Behalf Of Aissaoui,
Mustapha
(Mustapha)
Sent: Tuesday, December 16, 2014 12:22 PM
To: ietf(_at_)ietf(_dot_)org; IETF-Announce
Cc: mpls(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org] On Behalf Of The IESG
Sent: Thursday, December 04, 2014 2:37 PM
To: IETF-Announce
Cc: mpls(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org mailing lists by 2014-12-18. 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
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls