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

[Ross Callon <[e-mail]>]

> 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:[e-mail]] On Behalf Of Aissaoui, Mustapha (Mustapha)
Sent: Tuesday, August 19, 2014 3:19 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed)

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:[e-mail]] On Behalf Of Loa Andersson
> Sent: Tuesday, August 12, 2014 11:45 AM	
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed)
> 
> 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: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Huawei Technologies (consultant)     phone: [phone]
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls