Subject: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed)

From: Loa Andersson <[email-masked]>
Date: Tue, 12 Aug 2014 17:44:38 +0200

Working Group,

During what we thought would be a short wglc on draft-ietf-mpls-ldp-ipv6
http://www.ietf.org/mail-archive/web/mpls/current/msg12464.html
we had a comment that stopped us from continuing progressing the
draft.

The short working group last call is now closed!

The comment we refer to was raised in a private mail to the working
group chairs and the draft authors.

It says that there are a problem with some RFC 5036 non-compliant
implementations deployed and draft-ietf-mpls-ldp-ipv6. There is no
detailed description of the exact problems.

We strongly encourage the people that made the comment(s) to write-up
the problem, either as

- a new draft (preferred); or
- in a mail to the working group mailing list

Once we an agreement to write a new draft or the write-up to the
mailing, we will continue to ask the working group to see if we
can agree to a way to progress. We like to see this
write-up before September 1. Failing this we will continue to
progress the draft-ietf-mpls-ldp-ipv6 as is.

/Loa
for the working group chairs
-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Tue, 19 Aug 2014 07:18:53 +0000

Dear all,
The following are the details of the issue we found and the proposed solution. We shared this first with the authors to get initial feedback.

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.

The proposed solution is to have implementations complying to this draft advertise the IPv6 prefix state advertisement control capability (draft-ietf-mpls-ldp-ip-pw-capability-07) in the initialization message explicitly indicating support for LDP IPv6. Without the peer advertising this capability, an LSR must not send IPv6 addresses and FECs to that peer. 

This approach is safer and has been followed when mLDP FEC was introduced as explained in Section 2.1 of RFC 6388. Also, this does not introduce any new TLV to draft-ietf-mpls-ldp-ipv6. It just makes the exchange of LDP IPv6 addresses and FECs conditional to both peers explicitly indicating support for IPv6 capability during LDP session initialization. 

We do not feel such a simple change justifies writing a new draft and having to deal with backward compatibility of implementations across two drafts. 

We appreciate your comments on this matter.

Regards,
Mustapha.

> -----Original Message-----
> From: mpls [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: Tuesday, August 12, 2014 11:45 AM	
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed)
> 
> Working Group,
> 
> we had a comment that stopped us from continuing progressing the draft.
> 
> The comment we refer to was raised in a private mail to the working group chairs
> and the draft authors.
> 
> implementations deployed and draft-ietf-mpls-ldp-ipv6. There is no detailed
> description of the exact problems.
> 
> We strongly encourage the people that made the comment(s) to write-up the
> problem, either as
> 
> Once we an agreement to write a new draft or the write-up to the mailing, we will
> continue to ask the working group to see if we can agree to a way to progress. We
> like to see this write-up before September 1. Failing this we will continue to progress
> the draft-ietf-mpls-ldp-ipv6 as is.
> 
> /Loa
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Mark Tinka <[email-masked]>
Date: Wed, 20 Aug 2014 04:06:45 +0200

On Tuesday, August 19, 2014 09:18:53 AM Aissaoui, Mustapha 
(Mustapha) wrote:

> The proposed solution is to have implementations
> complying to this draft advertise the IPv6 prefix state
> advertisement control capability
> (draft-ietf-mpls-ldp-ip-pw-capability-07) in the
> initialization message explicitly indicating support for
> LDP IPv6. Without the peer advertising this capability,
> an LSR must not send IPv6 addresses and FECs to that
> peer.

I would support such a capability check, because for me, I 
have always held the view that the ability to signal LDPv6 
control plane also means the ability to signal LDPv6 FEC's 
and prefix information.

It is risky to signal IPv6 FEC's across an LDPv4 session 
just for its sake, and vice versa.

And I'd support this both for broadcast and point-to-point 
links.

Meanwhile, very happy to hear that ALU have code for this 
currently being tested. It's very encouraging to see.

Mark.

---

From: Ross Callon <[email-masked]>
Date: Fri, 22 Aug 2014 20:34:49 +0000

> The proposed solution is to have implementations complying to this draft
> advertise the IPv6 prefix state advertisement control capability
> (draft-ietf-mpls-ldp-ip-pw-capability-07) in the initialization message
> explicitly indicating support for LDP IPv6. Without the peer advertising
> this capability, an LSR must not send IPv6 addresses and FECs to that peer.

Speaking as an individual contributor, this seems IMHO to be the right solution (noting that, in final text as would be published in an RFC, the "must not" in the last sentence should be capitalized). 

Thanks, Ross

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Aissaoui, Mustapha (Mustapha)
Sent: Tuesday, August 19, 2014 3:19 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed)

Dear all,

Regards,
Mustapha.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 27 Aug 2014 23:18:45 +0000

If this draft were to address the interoperability with rfc5036
non-compliant implementations, then it would be easier to rather leverage
the Œtransport preference¹ TLV that is already part of the version 13.
This TLV was defined after the getting Adrian's and George¹s feedback.

http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-13#section-6.1.1

The reason for not agreeing to the alternate solution (of using IP Prefix
capability etc.) is 2-fold:

- not forward compatible (consider a deployment 5 yrs from now - IPv6-only
MPLS network - now, the LSR will be expecting an unnecessary IPv6 prefix
capability advertisement, and that¹s not optimal, if not annoying)

- not 100% backward compatible (does not solve the advertisement of v6
address binding to a v4 neighbor (which can also cause an outage to a
non-compliant peer))

Thanks. 

-- 
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco

-----Original Message-----
From: Ross Callon <[email-masked]>
Date: Friday, August 22, 2014 at 4:34 PM
To: Mustapha Aissaoui <[email-masked]>,
"[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>,
"[email-masked]"
<[email-masked]>
Subject: RE: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc
closed)
Resent-From: <[email-masked]>
Resent-To: Carlos Pignataro <[email-masked]>, Rajiv Papneja
<[email-masked]>, Rajiv Asati <[email-masked]>, Vishwas Manral
<[email-masked]>, <[email-masked]>, Loa Andersson <[email-masked]>,
Ross Callon <[email-masked]>, MARTIN VIGOUREUX
<[email-masked]>
Resent-Date: Friday, August 22, 2014 at 4:35 PM

>Speaking as an individual contributor, this seems IMHO to be the right
>solution (noting that, in final text as would be published in an RFC, the
>"must not" in the last sentence should be capitalized).
>
>Thanks, Ross
>
>The following are the details of the issue we found and the proposed
>solution. We shared this first with the authors to get initial feedback.
>
>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.
>
>This approach is safer and has been followed when mLDP FEC was introduced
>as explained in Section 2.1 of RFC 6388. Also, this does not introduce
>any new TLV to draft-ietf-mpls-ldp-ipv6. It just makes the exchange of
>LDP IPv6 addresses and FECs conditional to both peers explicitly
>indicating support for IPv6 capability during LDP session initialization.
>
>We do not feel such a simple change justifies writing a new draft and
>having to deal with backward compatibility of implementations across two
>drafts. 
>
>>the
>>mailing, we will

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Sat, 30 Aug 2014 00:25:45 +0000

Hi Rajiv,
See inline below for some follow-up.

Regards,
Mustapha.

> From: Rajiv Asati (rajiva) [mailto:[email-masked]]
> Sent: Wednesday, August 27, 2014 7:19 PM
> To: Ross Callon; Aissaoui, Mustapha (Mustapha); [email-masked]
> If this draft were to address the interoperability with rfc5036 non-compliant
> implementations, then it would be easier to rather leverage the Œtransport
> preference¹ TLV that is already part of the version 13.
MA> It is not a good idea to overload this new TLV with a capability advertisement role. LDP has its own capability advertisement mechanism and there is no need to confuse implementations with the handling of two mechanisms.
 
> The reason for not agreeing to the alternate solution (of using IP Prefix capability
> etc.) is 2-fold:
> 
> - not forward compatible (consider a deployment 5 yrs from now - IPv6-only MPLS
> network - now, the LSR will be expecting an unnecessary IPv6 prefix capability
> advertisement, and that¹s not optimal, if not annoying)
MA> IPv6-only network is not synonymous with a single FEC type network. It will support many types of FECs  in addition to the IPv6 prefix FEC: mLDP IPv6 FECs, PW FECs, IPv4 prefix FEC, etc. The LDP capabilities have been designed for the purpose of explicitly enabling or disabling capabilities including FEC type support on a given session.

> - not 100% backward compatible (does not solve the advertisement of v6 address
> binding to a v4 neighbor (which can also cause an outage to a non-compliant peer))
MA> I think it makes sense to tie the exchange of both IPv6 address messages and IPv6 prefix FECs to the advertisement of the IPv6 capability by both peers. If however there is a use case for decoupling the advertising of IPv6 addresses from IPv6 FECs, then a separate capability can be devised for addresses but I do not think we need it.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sat, 30 Aug 2014 11:19:20 +0000

Hi Mustapha, 

TR field is useful in case of dual-stack environment and using it for determining whether the peer implementation is compliant (wrt handling v6 address bindings and label bindings) is simple and straight forward. 

When v6-only peer implementations exist (and become a new norm), TR field usage would become moot. And we wouldn't have to see them. A very good thing, IMO.  

We need to think about how much of this baggage needs to carry over when single-stack ipv6 networks become a new norm (like single-stack ipv4 has been). 

Given that this draft already has built-in means to accommodate the RFC5036 non-compliant peer issue and do so in a simple manner, it is not necessary to require changing other drafts, IMO. 

Cheers,
Raj

PS; While there are multiple types of FECs, and it would be wise to dictate the default behavior (v6 FECs advertised) in v6-only environment with an option to change it. This is nothing different from current protocol machinery.

> On Aug 29, 2014, at 8:25 PM, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent .com> wrote:
> 
> Hi Rajiv,