Subject: RE: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to LDP for IPv6) to Proposed Standard

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Tue, 16 Dec 2014 17:21:42 +0000

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:[email-masked]] On Behalf Of The IESG
> Sent: Thursday, December 04, 2014 2:37 PM
> To: IETF-Announce
> Cc: [email-masked]
> 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 [email-masked]
> mailing lists by 2014-12-18. Exceptionally, comments may be sent to [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Mark Tinka <[email-masked]>
Date: Wed, 17 Dec 2014 08:03:47 +0200

On Tuesday, December 16, 2014 07:21:42 PM Aissaoui, Mustapha 
(Mustapha) wrote:

> 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.

Mustapha, I'm curious - are testing against other LDPv6 
implementations, or LDPv4 implementations?

Mark.

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Wed, 17 Dec 2014 13:26:54 +0000

Hi Mark,
It is actually testing against existing LDP IPv4 implementations when the LSR compliant to this draft sends LDP IPv6 FECs and LDP IPv6 addresses over the LDP IPv4 session.

Here is a brief summary of the issues as I described to the list this summer:
"
When an LSR which supports LDP IPv6 according to this draft is in a LAN with a broadcast interface, it can peer with LSRs which support this draft and LSRs which do not. When it peers using IPv4 LDP control plane with an LSR which does not support this draft, we have seen during our testing an issue that the advertisement of IPv6 addresses or IPv6 FECs to that peer will cause it to bring down the IPv4 LDP session.

In other words, there are deployed LDP implementations which are compliant to RFC 5036 for LDP IPv4 but are not compliant to RFC 5036 when it comes to handling IPv6 address or IPv6 FECs over an LDP IPv4 session. This is making us very concerned that when users enable dual-stack LDP IPv4/IPv6, they will bring down LDP IPv4 sessions which have been working in a multi-vendor environments for so many years.
"

Regards,
Mustapha.

> From: Mark Tinka [mailto:[email-masked]]
> Sent: Wednesday, December 17, 2014 1:04 AM
> To: [email-masked]
> Cc: Aissaoui, Mustapha (Mustapha); [email-masked]; IETF-Announce
> Subject: Re: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to LDP for
> IPv6) to Proposed Standard
> 
> > I was the one who raised the interop issues we found while testing our
> > implementation of LDP IPv6 against existing and deployed
> > implementations.
> 
> Mustapha, I'm curious - are testing against other LDPv6 implementations, or LDPv4
> implementations?
> 
> Mark.

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Wed, 17 Dec 2014 00:13:42 +0000

I agree with the points raised by Mustapha.

Thanks,

Pranjal

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Aissaoui, Mustapha (Mustapha)
Sent: Tuesday, December 16, 2014 9:22 AM
To: [email-masked]; IETF-Announce
Cc: [email-masked]
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to LDP for IPv6) to Proposed Standard

Hi Adrian and all,

Regards,

Mustapha.

> Cc: [email-masked]<mailto:[email-masked]>

> 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

> 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-masked]<mailto:[email-masked]> mailing lists by 2014-12-18. Exceptionally, comments may

> be sent to [email-masked]<mailto:[email-masked]> instead. In either case, please retain the

> beginning of the Subject line to allow automated sorting.

> [email-masked]<mailto:[email-masked]>

mpls mailing list

[email-masked]<mailto:[email-masked]>

---

From: Mark Tinka <[email-masked]>
Date: Wed, 17 Dec 2014 22:17:38 +0200

On Wednesday, December 17, 2014 03:26:54 PM Aissaoui, 
Mustapha (Mustapha) wrote:

> It is actually testing against existing LDP IPv4
> implementations when the LSR compliant to this draft
> sends LDP IPv6 FECs and LDP IPv6 addresses over the LDP
> IPv4 session.
> 
> Here is a brief summary of the issues as I described to
> the list this summer: "
> When an LSR which supports LDP IPv6 according to this
> draft is in a LAN with a broadcast interface, it can
> peer with LSRs which support this draft and LSRs which
> do not. When it peers using IPv4 LDP control plane with
> an LSR which does not support this draft, we have seen
> during our testing an issue that the advertisement of
> IPv6 addresses or IPv6 FECs to that peer will cause it
> to bring down the IPv4 LDP session.
> 
> In other words, there are deployed LDP implementations
> which are compliant to RFC 5036 for LDP IPv4 but are not
> compliant to RFC 5036 when it comes to handling IPv6
> address or IPv6 FECs over an LDP IPv4 session. This is
> making us very concerned that when users enable
> dual-stack LDP IPv4/IPv6, they will bring down LDP IPv4
> sessions which have been working in a multi-vendor
> environments for so many years. "

Thanks for the explanation, Mustapha.

Operationally, sounds a bit like IS-IS in a mixed single and 
dual stack environment, but with IS-IS running in ST (Single 
Topology) mode.

Of course, the IS-IS solution is to support MT (Multi-
Topology) so that adjacencies between a single stack and 
dual stack device work just fine.

I realize I'm simplifying things a bit, but not sure if we 
can borrow a leaf from the IS-IS solution, if we are going 
to implement an integrated LDPv4/LDPv6 in the same code 
base.

One more question - are you implying that this issue is not 
present in a point-to-point topology?

Mark.

---

From: Mark Tinka <[email-masked]>
Date: Thu, 18 Dec 2014 18:27:31 +0200

On Thursday, December 18, 2014 05:38:16 PM Aissaoui, 
Mustapha (Mustapha) wrote:

> Hi Mark,
> The issue will exist on a p2p link...

Yes, figured as much.

> but in that case you
> could always add a per-interface configuration knob
> which disables the dual-stack behavior and will prevent
> sending IPv6 FECs and IPv6 addresses over a session on
> that link.

Yes, easier to do on a point-to-point link compared to a 
broadcast network.

That said, I'm still for more of an MT-type solution a la 
IS-IS, so that this applies to the entire protocol. This 
way, operators do not have to fuff around with yet-another-
knob (until they really have to).

Any thoughts around this?

Cheers,

Mark.

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Thu, 18 Dec 2014 15:38:16 +0000

Hi Mark,
The issue will exist on a p2p link but in that case you could always add a per-interface configuration knob which disables the dual-stack behavior and will prevent sending IPv6 FECs and IPv6 addresses over a session on that link.

Regards,
Mustapha. 

> Sent: Wednesday, December 17, 2014 3:18 PM
> To: Aissaoui, Mustapha (Mustapha)
> Cc: [email-masked]; [email-masked]; IETF-Announce
> On Wednesday, December 17, 2014 03:26:54 PM Aissaoui, Mustapha (Mustapha)
> wrote:
> 
> > It is actually testing against existing LDP IPv4 implementations when
> > the LSR compliant to this draft sends LDP IPv6 FECs and LDP IPv6
> > addresses over the LDP
> > IPv4 session.
> >
> > Here is a brief summary of the issues as I described to the list this
> > summer: "
> > When an LSR which supports LDP IPv6 according to this draft is in a
> > LAN with a broadcast interface, it can peer with LSRs which support
> > this draft and LSRs which do not. When it peers using IPv4 LDP control
> > plane with an LSR which does not support this draft, we have seen
> > IPv6 addresses or IPv6 FECs to that peer will cause it to bring down
> > the IPv4 LDP session.
> >
> > In other words, there are deployed LDP implementations which are
> > compliant to RFC 5036 for LDP IPv4 but are not compliant to RFC 5036
> > when it comes to handling IPv6 address or IPv6 FECs over an LDP IPv4
> > session. This is making us very concerned that when users enable
> > dual-stack LDP IPv4/IPv6, they will bring down LDP IPv4 sessions which
> > have been working in a multi-vendor environments for so many years. "
> 
> Operationally, sounds a bit like IS-IS in a mixed single and dual stack environment,
> but with IS-IS running in ST (Single
> Topology) mode.
> 
> Topology) so that adjacencies between a single stack and dual stack device work
> just fine.
> 
> I realize I'm simplifying things a bit, but not sure if we can borrow a leaf from the IS-
> IS solution, if we are going to implement an integrated LDPv4/LDPv6 in the same
> code base.
> 
> One more question - are you implying that this issue is not present in a point-to-point
> topology?
> 
> Mark.

---

From: Mark Tinka <[email-masked]>
Date: Fri, 19 Dec 2014 14:24:45 +0200

On Friday, December 19, 2014 01:25:15 AM Aissaoui, Mustapha 
(Mustapha) wrote:

> What we were debating is if we should use the LDP
> capability TLV mechanism which LDP uses to advertise any
> new capability not supported by previous implementations
> versus overloading another TLV which was not meant for
> capability discovery.

As an operator, having to upgrade a non-compliant device 
that is not yet ready to run LDPv6 so that a neighboring 
LDPv6-capable device planning to run LDPv6 can still form 
LDPv4 adjacencies is quite heavy-handed.

Upgrading a device for anything LDPv6 should, ideally, be in 
the interest of getting LDPv6 deployed, and not to prevent 
LDPv4 adjacency tear-down due to capability incompatibility.

On the other hand, it might be worthwhile looking into 
adding a knob for an LDPv6-compliant device to tell it to 
have backwards compatibility with non-compliant devices on 
the wire. Since one would, in all likelihood, be upgrading a 
non-compliant device to make it compliant, the heavy-hand 
makes sense here since an operator needs to get the code in 
anyway.

Mark.

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Thu, 18 Dec 2014 23:25:15 +0000

Hi Mark,
both proposed methods to solve this LDP backward compatibility issue rely on detecting a specific TLV from the peer. So, the absence of the TLV will indicate that the peer LSR is not compliant to the LDP IPv6 draft in a similar way ISIS uses the absence of the Multi-Topology TLV to consider the neighbor is MT=0 capable only. So there is no need for a CLI knob. 

What we were debating is if we should use the LDP capability TLV mechanism which LDP uses to advertise any new capability not supported by previous implementations versus overloading another TLV which was not meant for capability discovery.

Mustapha.     

> Sent: Thursday, December 18, 2014 11:28 AM
> On Thursday, December 18, 2014 05:38:16 PM Aissaoui, Mustapha (Mustapha)
> wrote:
> 
> > Hi Mark,
> > could always add a per-interface configuration knob which disables the
> > dual-stack behavior and will prevent sending IPv6 FECs and IPv6
> > addresses over a session on that link.
> 
> Yes, easier to do on a point-to-point link compared to a broadcast network.
> 
> That said, I'm still for more of an MT-type solution a la IS-IS, so that this applies to
> the entire protocol. This way, operators do not have to fuff around with yet-another-

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Fri, 19 Dec 2014 14:14:17 +0000

Hi Mark,
Indeed the reason I raised the issue in the summer was to make sure we do not disrupt existing LDPv4 deployments and that we do not need to upgrade a LDPv4 node which does not comply to this LDPv6 spec. So, both proposed methods put the onus on the LDPv6 compliant node to automatically detect a router which is not compliant to LDPv6 such that it will not send to that node LDP IPv6 FECs and IPv6 addresses. 

>From that perspective, the draft now addressed the issue. My latest message was raising concerns about the specific method added to the draft and by which the LDPv6 compliant LSR goes about addressing the issue. 

I hope this clarifies the situation.

Regards,
Mustapha.

> Sent: Friday, December 19, 2014 7:25 AM
> > What we were debating is if we should use the LDP capability TLV
> > mechanism which LDP uses to advertise any new capability not supported
> > by previous implementations versus overloading another TLV which was
> > not meant for capability discovery.
> 
> As an operator, having to upgrade a non-compliant device that is not yet ready to
> run LDPv6 so that a neighboring LDPv6-capable device planning to run LDPv6 can
> still form
> Upgrading a device for anything LDPv6 should, ideally, be in the interest of getting
> LDPv6 deployed, and not to prevent
> On the other hand, it might be worthwhile looking into adding a knob for an LDPv6-
> compliant device to tell it to have backwards compatibility with non-compliant
> devices on the wire. Since one would, in all likelihood, be upgrading a non-compliant
> device to make it compliant, the heavy-hand makes sense here since an operator
> needs to get the code in anyway.
> 
> Mark.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 19 Dec 2014 18:22:17 -0000

Mustapha,

It will fall to me to try to draw some form of consensus out of this discussion
so I have would like to clarify some things.

Are you reporting an interop problem with widely deployed implementations, or an
interop problem with one release of one implementation? The latter is what I
would call a bug, since the problem is a failure to conform to 5036. The former
is, of course, a bigger problem.

Are you reporting a problem that is exclusive to multi-access links? While this
is an important use case, it is a little marginal.

In short, do you have a corner case comprising of:
- multi-access link
- combined legacy v4 nodes and new v6 nodes
- a non-conformant v4 node
...or is the problem larger than that?

Thanks,
Adrian

> Sent: 19 December 2014 14:14
> To: [email-masked]
> Indeed the reason I raised the issue in the summer was to make sure we do not
> disrupt existing LDPv4 deployments and that we do not need to upgrade a LDPv4
> node which does not comply to this LDPv6 spec. So, both proposed methods put
> the onus on the LDPv6 compliant node to automatically detect a router which is
> not compliant to LDPv6 such that it will not send to that node LDP IPv6 FECs
and
> IPv6 addresses.
> 
> >From that perspective, the draft now addressed the issue. My latest message
> was raising concerns about the specific method added to the draft and by which
> the LDPv6 compliant LSR goes about addressing the issue.
> 
> > Subject: Re: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to
LDP
> for
> > As an operator, having to upgrade a non-compliant device that is not yet
ready
> to

---

From: Mark Tinka <[email-masked]>
Date: Sun, 21 Dec 2014 18:02:13 +0200

On Friday, December 19, 2014 04:14:17 PM Aissaoui, Mustapha 
(Mustapha) wrote:

> Indeed the reason I raised the issue in the summer was to
> make sure we do not disrupt existing LDPv4 deployments
> and that we do not need to upgrade a LDPv4 node which
> does not comply to this LDPv6 spec. So, both proposed
> methods put the onus on the LDPv6 compliant node to
> automatically detect a router which is not compliant to
> LDPv6 such that it will not send to that node LDP IPv6
> FECs and IPv6 addresses.
> 
> From that perspective, the draft now addressed the issue.
> My latest message was raising concerns about the
> specific method added to the draft and by which the
> LDPv6 compliant LSR goes about addressing the issue.
> 

Thanks, Mustapha.

Mark.

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Fri, 19 Dec 2014 19:10:47 +0000

Hi Adrian,
We found interop issues with two other widely deployed implementations in which the LDP IPv4 session was brought down. 

One implementation was with receiving IPv6 addresses over the LDPv4 session and the behavior did not seem to change with a few versions of the implementation we tried. The second implementation was with IPv6 FECs over the LDPv4 session. This last one was fixed in a subsequent release but we lately found out that there were still issues with withdrawing/releasing the IPv6 FECs.

The issue exists in both p2p and broadcast interfaces. The thing is that as soon as a router is upgraded to this implementation, it will automatically begin advertising IPv6 addresses and IPv6 FECs over the LDPv4 session. Based on testing so far, and we have not tested all possible OS and hardware versions, we believe it is risky to advertise these by default and hence our proposal to play it safe and only advertise them if the peer LSR explicitly advertised its support for IPv6 FECs by including the IPv6 FEC capability in the session initialization. 

The draft now added a similar check using the dual-stack capability TLV at the adjacency level instead of our proposal of using the capability TLV at the session level. It does complicate the check of the peer capabilities and as such I provided comments in the last call email to clarify the behavior of that proposal.

Regards,
Mustapha.

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Friday, December 19, 2014 1:22 PM
> To: Aissaoui, Mustapha (Mustapha); [email-masked]
> Cc: [email-masked]; [email-masked]; 'IETF-Announce'
> Subject: RE: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to LDP for
> It will fall to me to try to draw some form of consensus out of this discussion so I
> have would like to clarify some things.
> 
> interop problem with one release of one implementation? The latter is what I would
> call a bug, since the problem is a failure to conform to 5036. The former is, of
> course, a bigger problem.
> 
> Are you reporting a problem that is exclusive to multi-access links? While this is an
> important use case, it is a little marginal.
> 
> > From: mpls [mailto:[email-masked]] On Behalf Of Aissaoui,
> > Mustapha
> > (Mustapha)
> LDP for
> > Indeed the reason I raised the issue in the summer was to make sure we
> > do not disrupt existing LDPv4 deployments and that we do not need to
> > upgrade a LDPv4 node which does not comply to this LDPv6 spec. So,
> > both proposed methods put the onus on the LDPv6 compliant node to
> > automatically detect a router which is not compliant to LDPv6 such
> > that it will not send to that node LDP IPv6 FECs
> and
> > IPv6 addresses.
> >
> > was raising concerns about the specific method added to the draft and
> > by which the LDPv6 compliant LSR goes about addressing the issue.
> >
> > > > mechanism which LDP uses to advertise any new capability not
> > > > supported by previous implementations versus overloading another
> > > > TLV which was not meant for capability discovery.
> > >
> > > run LDPv6 so that a neighboring LDPv6-capable device planning to run
> > > LDPv6
> > can
> > > still form
> > > Upgrading a device for anything LDPv6 should, ideally, be in the
> > > interest of
> > getting
> > > On the other hand, it might be worthwhile looking into adding a knob
> > > for an
> > LDPv6-
> > > devices on the wire. Since one would, in all likelihood, be
> > > upgrading a non-
> > compliant
> > > device to make it compliant, the heavy-hand makes sense here since
> > > an
> > operator