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

["Rajiv Asati (rajiva)" <[e-mail]>]

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

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