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

["Aissaoui, Mustapha (Mustapha)" <[e-mail]>]

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

Regards,
Mustapha.

> -----Original Message-----
> From: Rajiv Asati (rajiva) [mailto:[e-mail]]
> Sent: Wednesday, August 27, 2014 7:19 PM
> To: Ross Callon; Aissaoui, Mustapha (Mustapha); [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed)
> 
> 
> 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
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.


> 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