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

["Dutta, Pranjal K (Pranjal)" <[e-mail]>]

I had raised similar concerns earlier. Hacking up “per adjacency specific” Dual-stack TLV to mean for “session-level” IPV6 FEC and Address capabilities is completely wrong thing to do.


1.      Dual stack TLV is sent per Hello adjacency on an interface and its purpose is bootstrapping LDP session. There could be multiple interface/adjacencies with a peering session. The capability in question is a session level capability and not per hello adjacency on an interface. Hacking up an adjacency level TLV to negotiate  IPV6 session capabilities is a complete disconnect.



2.      LDP session capability framework is defined in RFC 5561. There is an already defined method in draft-ietf-mpls-ldp-ip-pw-capability (SAC Capabilities) which is based on RFC 5561 to negotiate IPV6 FEC Capabilities in an LDP session. Currently SAC Capabilities limit to explicit advertisement of do_not_support = -ve case only. Just adding the following clause into SAC Capability include the +ve case (explicit support) is a generic way and time-tested solution.


“Implementations complying to this draft must advertise the IPv6 prefix state advertisement control capability (draft-ietf-mpls-ldp-ip-pw-capability) in the initialization message  explicitly indicating support for LDP IPv6 FEC. Without the peer advertising this capability, an LSR must not send IPv6 addresses and IPv6 FECs to that peer.”

            It does not make sense for an implementation to hack an adjacency level TLV (Dual Stack TLV which was introduced for a complete different purpose)  for the +ve case and then use IPV6 SAC Capabilities for –ve case). There needs to be only one way to fulfill one specific purpose. I am surprised too to see such kind of proposals in a Standards track item which is likely to exist for many years.

Thanks,
Pranjal

From: Aissaoui, Mustapha (Mustapha)
Sent: Monday, November 10, 2014 3:00 PM
To: Rajiv Asati (rajiva); Dutta, Pranjal K (Pranjal)
Cc: Ross Callon; [e-mail]; [e-mail]; [e-mail]
Subject: RE: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed)

Hi Rajiv,
We did not properly close this discussion and I noticed the draft was updated to use the dual-stack capability TLV in Hellos as a way to discover the LDP peer capability of handling IPv6 FECs and IPv6 addresses.

I am very surprised that we are deviating from the main LDP mechanism which is the LDP capability as per RFC 5561. Furthermore, we only needed to discover the IPv6 FEC and IPv6 address capabilities at the session level and not at the Hello adjacency level. There is nothing which is specific to the adjacency here.

The dual-stack capability TLV has nothing to do with the FEC and address capability of an LSR, it is simply a way to handle preference for the control plane establishment of the Hello adjacency. It is not a good precedent that this would be overloaded to indicate FEC and address capability advertisement which is orthogonal to adjacency establishment.

I strongly believe that we simply needed to use the existing IPv6 capability described in draft-ietf-mpls-ldp-ip-pw-capability,  which is extension of LDP capabilities defined in RFC 5561. We could also define another capability for the IPv6 addresses in that same draft if really required but I do not think we needed to. There needs to be only one method to do one thing and draft-ietf-mpls-ldp-ip-pw-capability is the way to go  for any IPv6 FEC related “session” capabilities.

To re-iterate, here is the proposal I made. Implementations complying to this draft must advertise the IPv6 prefix state advertisement control capability (draft-ietf-mpls-ldp-ip-pw-capability) in the initialization message explicitly indicating support for LDP IPv6 FEC. Without the peer advertising this capability, an LSR must not send IPv6 addresses and IPv6 FECs to that peer.

There was one individual support for this proposal on this mailing list and I thus consider the discussion was not properly closed.

Regards,
Mustapha.

From: Dutta, Pranjal K (Pranjal)
Sent: Tuesday, September 02, 2014 5:33 PM
To: Aissaoui, Mustapha (Mustapha); Rajiv Asati (rajiva)
Cc: Ross Callon; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed)


I second to Mustapha. We should use features for what they are designed for. It is the SAC capability (draft-ietf-mpls-ldp-ip-pw-capability-07) that defines the negotiation of IPV4/IPV6 Prefix FEC Capabilities in LDP session, which fits into the required inter-op solution organically.



I do not consider explicit advertisement of IPv6 Prefix FEC SAC (D = 0) in Initialization message can be seen as baggage. An implementation that does not want to receive IPv6 Prefix FECs will send D=1 in Initialization message anyways.



Cheers,

Pranjal



-----Original Message-----
From: mpls [mailto:[e-mail]] On Behalf Of Aissaoui, Mustapha (Mustapha)
Sent: Tuesday, September 02, 2014 11:57 AM
To: Rajiv Asati (rajiva)
Cc: Ross Callon; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short wglc closed)



Hi Rajiv,

I think the key point I am trying to convey is that we should keep the protocol clean and use features for what they are designed for. LDP has its own capability advertisement and it is meant to address issues like this one.



Overloading the TR field of the initialization message means that a peer will have to check both the TR and the SAC to decide what to do for the IPv6 prefix FEC while it is sufficient to check the SAC for all other FEC types. This is inconsistent and will cause an unnecessary exception in the protocol.



Also, using the LDP advertisement capability is not a baggage in the future. This mechanism is used with mLDP P2P and MP2MP FECs and this is working fine today although many implementations now support these types of FECs.



As for changing other drafts, we are simply talking about stating in draft-ietf-mpls-ldp-ip-pw-capability-07 that an LDP peer must set D-bit=0  in IPv6 prefix FEC SAC in the initialization message.



Regards,

Mustapha.



> -----Original Message-----

> From: Rajiv Asati (rajiva) [mailto:[e-mail]]

> Sent: Saturday, August 30, 2014 7:19 AM

> To: Aissaoui, Mustapha (Mustapha)

> Cc: Ross Callon; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

> draft-ietf-mpls-ldp- [e-mail]<mailto:[e-mail]>

> Subject: Re: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short

> wglc closed)

>

> 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<mailto:mustapha.aissaoui@alcatel-lucent%20.com>> wrote:

> >

> > 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]<mailto:[e-mail]>

> >> Cc: [e-mail]<mailto:[e-mail]>;

> >> [e-mail]<mailto:[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

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

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

> > MA> 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]<mailto:[e-mail]>>

> >> Date: Friday, August 22, 2014 at 4:34 PM

> >> To: Mustapha Aissaoui <[e-mail]<mailto:[e-mail]>>,

> >> "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>

> >> Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>,

> >> "[e-mail]<mailto:[e-mail]>"

> >> <[e-mail]<mailto:[e-mail]>>

> >> Subject: RE: [mpls] Way to progress draft-ietf-mpls-ldp-ipv6 (short

> >> wglc

> >> closed)

> >> Resent-From: <[e-mail]<mailto:[e-mail]>>

> >> Resent-To: Carlos Pignataro <[e-mail]<mailto:[e-mail]>>, Rajiv Papneja

> >> <[e-mail]<mailto:[e-mail]>>, Rajiv Asati <[e-mail]<mailto:[e-mail]>>, Vishwas

> >> Manral <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, Loa Andersson

> >> <[e-mail]<mailto:[e-mail]>>, Ross Callon <[e-mail]<mailto:[e-mail]>>, MARTIN VIGOUREUX

> >> <[e-mail]<mailto:[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]<mailto:[e-mail]>

> >>> Cc: [e-mail]<mailto:[e-mail]>;

> >>> [e-mail]<mailto:[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]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

> >>>> [e-mail]<mailto:[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]<mailto:[e-mail]>

> >>>> Senior MPLS Expert                          [e-mail]<mailto:[e-mail]>

> >>>> Huawei Technologies (consultant)     phone: [phone]

> >>>>

> >>>> _______________________________________________

> >>>> mpls mailing list

> >>>> [e-mail]<mailto:[e-mail]>

> >>>> https://www.ietf.org/mailman/listinfo/mpls

> >>>

> >>> _______________________________________________

> >>> mpls mailing list

> >>> [e-mail]<mailto:[e-mail]>

> >>> https://www.ietf.org/mailman/listinfo/mpls

> >



_______________________________________________

mpls mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/mpls