Hi Rajiv,
Thanks for the reply. I added some follow-up inline below.
Regards,
Mustapha.
-----Original Message-----
From: Rajiv Asati (rajiva) [mailto:rajiva(_at_)cisco(_dot_)com]
Sent: Tuesday, January 06, 2015 6:03 PM
To: Aissaoui, Mustapha (Mustapha); 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 Mustapha,
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:
Thanks for pointing out the below scenarios. We think that all but one are
either
covered or require editorial changes.
1. This scenario (sending hellos with DS capability on fewer interfaces for a
peer)
does NOT look realistic, since hitless upgrading a router would result in
sending
v4+v6 hellos either with DS capability or without DS capability (for a DS
peer,
assuming the peer was enabled for DS LDP, default or not, in an
implementation).
Perhaps, you had a different scenario in mind.
MA> This could occur during a hitless upgrade for Hello adjacencies from
different line cards during a transient time. I will not insist on this point
but I found the draft lacks what action to take if the Hello messages received
on parallel links from the same LSR are not consistent, meaning they have
different TR values or the message on one link do not have the DS capability.
The only thing I found is this paragraph in Section 6.1.1 but it does not say
what to do if an LSR receives inconsistent Hello messages:
"
An LSR MUST convey the same transport connection preference ("TR"
field value) in all (link and targeted) Hellos that advertise the
same label space to the same peer and/or on same interface. This
ensures that two LSRs linked by multiple Hello adjacencies using the
same label spaces play the same connection establishment role for
each adjacency.
"
2. Yes. This scenario is well covered in section 6.1.1 point#3.
//
3. If "Dual-stack capability" TLV is NOT present, and
Š
resulting in any established LDPoIPv4 session being reset
and a fatal Notification message being sent (with status
Š
//
MA> What I was talking about is a transition from state 2a to state 3a or from
state 2b to state 3b in Section 6.1.1. Perhaps one way to explicitly state that
the session is bounced would be to add something like this to items 2a and 2b
of Section 6..1.1:
"
2. If "Dual-stack capability" TLV is present, and remote
preference matches with the local preference, then:
a) If TR=0100 (LDPoIPv4), then determine the active/passive
roles for TCP connection using IPv4 transport address as
defined in section 2.5.2 of RFC 5036.
b) If TR=0110 (LDPoIPv6), then determine the active/passive
roles for TCP connection by using IPv6 transport address
as defined in section 2.5.2 of RFC 5036.
*If subsequently to establishing the LDP session, the Hello messages from
the peer
do not include the Dual-stack capability TLV, the session is terminated and
a fatal Notification message is sent with status code of 'Dual-Stack
Non-Compliance' (IANA allocation TBD).*
"
3. Yes (to the expected behavior). This is somewhat covered in bullet #1 in
section
6.1.1, but we can make it explicit by adding "or does not get recognized² as
below:
OLD:
If "Dual-stack capability" TLV is present and remote preference does not match
with the local preference,..
NEW:
If "Dual-stack capability" TLV is present and remote preference does not match
with the local preference (or does not get recognized),..
MA> Your proposed modification does address this comment. Thank you.
4 and 5. Yes (to the expected behavior). It is implicit in section 7.2 para 4.
//..
An LSR MAY further constrain the advertisement of FEC-label bindings for a
particular address family by negotiating the IP Capability...//
Are you suggesting to make it explicit?
MA> Yes I wanted something more explicit. This section certainly says the IPv6
prefix FEC capability can further constrain a particular FEC type which is
allowed by the check of the DS capability TLV. It however does not discuss the
negative case, i.e., the DS capability TLV did not allow a FEC type but the IP
capability allowed it.
I believe the following addition to an earlier paragraph in Section 7.2 would
help clarify this:
"
If an LSR enabled with Dual-stack LDP for a peer and
1. Is NOT able to find the Dual-stack capability TLV in the
incoming IPv4 LDP hello messages from that peer, then the LSR
MUST NOT advertise IPv6 FEC-label bindings to the peer *even if it
received an IP capability
from the peer indicating the enabling of the IPv6 FEC type*.
"
BTW, there is a "copy & paste" mistake in the following paragraph in the same
Section 7.2. The "via ADDRESS message" is not correct here since this is about
FEC distribution, hence Label Mapping message, and not address distribution.
"
If an LSR is enabled with Single-stack LDP for any peer, then it
MUST advertise (via ADDRESS message) FEC-Label bindings for the
enabled address family, and accept FEC-Label bindings for the
enabled address family.
"
--
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco
-----Original Message-----
From: <Aissaoui>, Mustapha Aissaoui
<mustapha(_dot_)aissaoui(_at_)alcatel-lucent(_dot_)com>
Date: Tuesday, December 16, 2014 at 12:21 PM
To: IETF Discussion <ietf(_at_)ietf(_dot_)org>, IETF-Announce
<ietf-announce(_at_)ietf(_dot_)org>
Cc: "mpls(_at_)ietf(_dot_)org" <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