Subject: RE: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to LDP for IPv6) to Proposed Standard

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Tue, 6 Jan 2015 21:01:57 +0000

Adrian and authors,
Can we also close on the IANA assignment for the new TLVs and specifically for the Dual-Stack Capability TLV?

I assume this will be drawn from the Common Hello Parameters range of the LDP TLV Type Name Space. The next available value is 0x0409. I appreciate if you could confirm this value.

Regards,
Mustapha.

> -----Original Message-----
> From: mpls [mailto:[email-masked]] On Behalf Of Aissaoui, Mustapha
> (Mustapha)
> Sent: Tuesday, December 16, 2014 12:22 PM
> To: [email-masked]; IETF-Announce
> Cc: [email-masked]
> Subject: Re: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to LDP for
> IPv6) to Proposed Standard
> 
> Hi Adrian and all,
> I was the one who raised the interop issues we found while testing our
> implementation of LDP IPv6 against existing and deployed implementations. I
> proposed a simple method of using the existing FEC advertisement capability at
> the session level as a way for an LSR to detect if an implementation support LDP
> IPv6 FECs and IPv6 addresses. This existing FEC advertisement capability at
> session level is defined in draft-ietf-mpls-ldp-ip-pw-capability-08 but with the
> limitation that it can be used only to disable support of IPv6 FECs in LDP
> Initialization Message; we proposed to generalize the method to also indicate
> explicit support for IPv6 FECs and IPv6 Addresses in LDP Initialization Message.
> This method is safe and was also used with mLDP P2MP and MP2MP FECs when
> they were introduced. The intent here is that all session level capabilities in LDP
> should follow RFC 5561 approach.
> 
> There was an individual contributor which supported the proposal on the mailing
> list but the authors chose to ignore it and went with a proposal which overloaded
> the meaning of the dual-stack capability TLV. Regardless of the merit of either
> method, the discussion on the MPLS mailing list was not closed properly from my
> perspective.
> 
> Now here is the concern I raised with using the dual-stack capability. Not only this
> TLV is an adjacency level feature which is has nothing to do with FEC capability
> advertisement, but it is introducing complexity in the implementation which now
> has to check dual-stack capability for *each* adjacency to the peer *and* the
> session level FEC capability to decide what the peer is capable of at the *session
> level*.
> 
> Having said that, I want to keep the spirit of cooperation and make sure we get this
> draft published. To that effect, I am not opposed to its publication as long as the
> following points are clarified in the draft since now FEC capability of the LSR peer
> is determined by a check a both adjacency and session levels:
> 
> 1. The draft is missing the behavior when multiple adjacencies exist to the same
> LSR and the peer LSR advertised the dual-stack capability only over a subset of
> these Hello adjacencies.
> I assume here the peer LSR is considered to be dual-stack capable as soon as any
> of the Hello adjacencies includes the dual-stack capability. This would allow a
> hitless upgrade scenario from an older implementation to one which complies to
> this draft
> 
> 2. Similarly, what would be the behavior if a hello adjacency changes from sending
> the dual-stack capability to not sending it? This would be for example in a hitless
> downgrade to a version of LDP which does not comply to this draft.
> I assume here that the session must be bounced since the LSRs need a clean state
> to not send IPv6 addresses and IPv6 FECs.
> 
> 3. The document defines 2 values for the dual-stack capability TR. It does not
> mention the behavior when an unknown value is received.
> Will that be considered a fatal error?
> 
> 4. The draft is missing the behavior of when the peer LSR does not advertise the
> dual-stack capability in all the Hello adjacencies but it advertised the enabling or
> disabling of the IPv6 prefix FEC capability in the session initialization message.
> I assume here that the absence of the dual-stack capability overrides any session
> level IPv6 FEC prefix capability advertisement.
> 
> 5. The draft is missing the behavior of when the peer LSR does not advertise the
> dual-stack capability in all the Hello adjacencies but it advertised the enabling of
> the IPv6 prefix FEC capability in the session Capability message.
> I assume the same behavior as in (4) applies here.
> 
> Regards,
> Mustapha.
> 
> > -----Original Message-----
> > From: mpls [mailto:[email-masked]] On Behalf Of The IESG
> > Sent: Thursday, December 04, 2014 2:37 PM
> > To: IETF-Announce
> > Cc: [email-masked]
> > Subject: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates
> > to LDP for IPv6) to Proposed Standard
> >
> >
> > The IESG has received a request from the Multiprotocol Label Switching
> > WG
> > (mpls) to consider the following document:
> > - 'Updates to LDP for IPv6'
> >   <draft-ietf-mpls-ldp-ipv6-14.txt> as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> > final comments on this action. Please send substantive comments to the
> > [email-masked] mailing lists by 2014-12-18. Exceptionally, comments may
> > be sent to [email-masked] instead. In either case, please retain the
> > beginning of the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >    The Label Distribution Protocol (LDP) specification defines
> >    procedures to exchange label bindings over either IPv4, or IPv6 or
> >    both networks. This document corrects and clarifies the LDP behavior
> >    when IPv6 network is used (with or without IPv4). This document
> >    updates RFC 5036 and RFC 6720.
> >
> > The file can be obtained via
> > http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/
> >
> > IESG discussion can be tracked via
> > http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ballot/
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> > _______________________________________________
> > mpls mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 6 Jan 2015 23:02:53 +0000

Hi Mustapha, 

> following points are clarified in the draft since now FEC capability of
>the LSR peer is
> determined by a check a both adjacency and session levels:

Thanks for pointing out the below scenarios. We think that all but one are
either covered or require editorial changes.

1. This scenario (sending hellos with DS capability on fewer interfaces
for a peer) does NOT look realistic, since hitless upgrading a router
would result in sending v4+v6 hellos either with DS capability or without
DS capability (for a DS peer, assuming the peer was enabled for DS LDP,
default or not, in an implementation).

Perhaps, you had a different scenario in mind.

2. Yes. This scenario is well covered in section 6.1.1 point#3.

//
     3. If "Dual-stack capability" TLV is NOT present, and

Š
             resulting in any established LDPoIPv4 session being reset
             and a fatal Notification message being sent (with status

Š

//

3. Yes (to the expected behavior). This is somewhat covered in bullet #1
in section 6.1.1, but we can make it explicit by adding "or does not get
recognized² as below:

OLD:
If "Dual-stack capability" TLV is present and remote preference does not
match with the local preference,..

NEW:
If "Dual-stack capability" TLV is present and remote preference does not
match with the local preference (or does not get recognized),..

4 and 5. Yes (to the expected behavior). It is implicit in section 7.2
para 4. 

//..
 An LSR MAY further constrain the advertisement of FEC-label bindings for
a particular address family by negotiating the IP Capability...//

Are you suggesting to make it explicit?

-- 
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco

-----Original Message-----
From: <Aissaoui>, Mustapha Aissaoui <[email-masked]>
Date: Tuesday, December 16, 2014 at 12:21 PM
To: IETF Discussion <[email-masked]>, IETF-Announce <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates

>implementation of LDP IPv6 against existing and deployed implementations.
>I proposed a simple method of using the existing FEC advertisement
>capability at the session level as a way for an LSR to detect if an
>implementation support LDP IPv6 FECs and IPv6 addresses. This existing
>FEC advertisement capability at session level is defined in
>draft-ietf-mpls-ldp-ip-pw-capability-08 but with the limitation that it
>can be used only to disable support of IPv6 FECs in LDP Initialization
>Message; we proposed to generalize the method to also indicate explicit
>support for IPv6 FECs and IPv6 Addresses in LDP Initialization Message.
>they were introduced. The intent here is that all session level
>capabilities in LDP should follow RFC 5561 approach.
>
>There was an individual contributor which supported the proposal on the
>mailing list but the authors chose to ignore it and went with a proposal
>which overloaded the meaning of the dual-stack capability TLV. Regardless
>of the merit of either method, the discussion on the MPLS mailing list
>was not closed properly from my perspective.
>
>Now here is the concern I raised with using the dual-stack capability.
>Not only this TLV is an adjacency level feature which is has nothing to
>do with FEC capability advertisement, but it is introducing complexity in
>the implementation which now has to check dual-stack capability for
>*each* adjacency to the peer *and* the session level FEC capability to
>decide what the peer is capable of at the *session level*.
>
>Having said that, I want to keep the spirit of cooperation and make sure
>we get this draft published. To that effect, I am not opposed to its
>publication as long as the following points are clarified in the draft
>since now FEC capability of the LSR peer is determined by a check a both
>adjacency and session levels:
>
>1. The draft is missing the behavior when multiple adjacencies exist to
>the same LSR and the peer LSR advertised the dual-stack capability only
>over a subset of these Hello adjacencies.
>I assume here the peer LSR is considered to be dual-stack capable as soon
>as any of the Hello adjacencies includes the dual-stack capability. This
>would allow a hitless upgrade scenario from an older implementation to
>one which complies to this draft
>
>2. Similarly, what would be the behavior if a hello adjacency changes
>from sending the dual-stack capability to not sending it? This would be
>for example in a hitless downgrade to a version of LDP which does not
>comply to this draft.
>I assume here that the session must be bounced since the LSRs need a
>clean state to not send IPv6 addresses and IPv6 FECs.
>
>3. The document defines 2 values for the dual-stack capability TR. It
>does not mention the behavior when an unknown value is received.
>4. The draft is missing the behavior of when the peer LSR does not
>advertise the dual-stack capability in all the Hello adjacencies but it
>advertised the enabling or disabling of the IPv6 prefix FEC capability in
>the session initialization message.
>I assume here that the absence of the dual-stack capability overrides any
>session level IPv6 FEC prefix capability advertisement.
>
>5. The draft is missing the behavior of when the peer LSR does not
>advertise the dual-stack capability in all the Hello adjacencies but it
>advertised the enabling of the IPv6 prefix FEC capability in the session
>Capability message.
>>final
>> comments on this action. Please send substantive comments to the
>>[email-masked]
>> mailing lists by 2014-12-18. Exceptionally, comments may be sent to
>>[email-masked]
>> instead. In either case, please retain the beginning of the Subject
>>line to allow
>> automated sorting.
>> 
>> Abstract
>>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 7 Jan 2015 16:46:02 -0000

Hi Mustapha,

> I assume this will be drawn from the Common Hello Parameters range of the LDP
> TLV Type Name Space. The next available value is 0x0409. I appreciate if you
could
> confirm this value.

Are you asking for an early allocation of this code point?

The document has been through IETF last call and with a few edits will be ready
for processing by the IESG. After IESG approval, the IANA will make a
provisional allocation of a code point that will be confirmed on publication of
the RFC. The IANA is *likely* to allocate the next available value, but not if
another I-D gets there first :-)

Unless there is a reason for a rush, I suggest that we wait for normal process.
Constructive discussion of the remaining issues with this draft should enable
that to complete quickly.

Thanks,
Adrian

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Fri, 9 Jan 2015 23:19:10 +0000

Hi Rajiv,
Thanks for the reply. I added some follow-up inline below.

Regards,
Mustapha.

> From: Rajiv Asati (rajiva) [mailto:[email-masked]]
> Sent: Tuesday, January 06, 2015 6:03 PM
> To: Aissaoui, Mustapha (Mustapha); [email-masked]; IETF-Announce
> Cc: [email-masked]
> > Having said that, I want to keep the spirit of cooperation and make
> >sure we get this  draft published. To that effect, I am not opposed to
> >its publication as long as the  following points are clarified in the
> >draft since now FEC capability of the LSR peer is  determined by a
> >check a both adjacency and session levels:
> 
> Thanks for pointing out the below scenarios. We think that all but one are either
> covered or require editorial changes.
> 
> 
> 1. This scenario (sending hellos with DS capability on fewer interfaces for a peer)
> does NOT look realistic, since hitless upgrading a router would result in sending
> v4+v6 hellos either with DS capability or without DS capability (for a DS peer,
> assuming the peer was enabled for DS LDP, default or not, in an implementation).
> 
MA> This could occur during a hitless upgrade for Hello adjacencies from different line cards during a transient time. I will not insist on this point but I found the draft lacks what action to take if the Hello messages received on parallel links from the same LSR are not consistent, meaning they have different TR values or the message on one link do not have the DS capability. The only thing I found is this paragraph in Section 6.1.1 but it does not say what to do if an LSR receives inconsistent Hello messages:
"
An LSR MUST convey the same transport connection preference ("TR"
   field value) in all (link and targeted) Hellos that advertise the
   same label space to the same peer and/or on same interface.  This
   ensures that two LSRs linked by multiple Hello adjacencies using the
   same label spaces play the same connection establishment role for
   each adjacency.
"
 
>              and a fatal Notification message being sent (with status
MA> What I was talking about is a transition from state 2a to state 3a or from state 2b to state 3b in Section 6.1.1. Perhaps one way to explicitly state that the session is bounced would be to add something like this to items 2a and 2b of Section 6..1.1:
"
2. If "Dual-stack capability" TLV is present, and remote
        preference matches with the local preference, then:

          a) If TR=0100 (LDPoIPv4), then determine the active/passive
             roles for TCP connection using IPv4 transport address as
             defined in section 2.5.2 of RFC 5036.

          b) If TR=0110 (LDPoIPv6), then determine the active/passive
             roles for TCP connection by using IPv6 transport address
             as defined in section 2.5.2 of RFC 5036.
   *If subsequently to establishing the LDP session, the Hello messages from the peer
   do not include the Dual-stack capability TLV, the session is terminated and a fatal Notification message is sent with     status code of 'Dual-Stack Non-Compliance' (IANA allocation TBD).*
"

> 
> 3. Yes (to the expected behavior). This is somewhat covered in bullet #1 in section
> 6.1.1, but we can make it explicit by adding "or does not get recognized² as below:
> 
> 
> OLD:
> If "Dual-stack capability" TLV is present and remote preference does not match
> with the local preference,..
> 
> 
> NEW:
> If "Dual-stack capability" TLV is present and remote preference does not match
> with the local preference (or does not get recognized),..
MA> Your proposed modification does address this comment. Thank you.

> 4 and 5. Yes (to the expected behavior). It is implicit in section 7.2 para 4.
> 
> //..
>  An LSR MAY further constrain the advertisement of FEC-label bindings for a
> particular address family by negotiating the IP Capability...//
> 
MA> Yes I wanted something more explicit. This section certainly says the IPv6 prefix FEC capability can further constrain a particular FEC type which is allowed by the check of the DS capability TLV. It however does not discuss the negative case, i.e., the DS capability TLV did not allow a FEC type but the IP capability allowed it. 
I believe the following addition to an earlier paragraph in Section 7.2 would help clarify this:
"
If an LSR enabled with Dual-stack LDP for a peer and

     1. Is NOT able to find the Dual-stack capability TLV in the
        incoming IPv4 LDP hello messages from that peer, then the LSR
        MUST NOT advertise IPv6 FEC-label bindings to the peer *even if it received an IP capability 
        from the peer indicating the enabling of the IPv6 FEC type*.
"
BTW, there is a "copy & paste" mistake in the following paragraph in the same Section 7.2. The "via ADDRESS message" is not correct here since this is about FEC distribution, hence Label Mapping message, and not address distribution.
"
If an LSR is enabled with Single-stack LDP for any peer, then it
   MUST advertise (via ADDRESS message) FEC-Label bindings for the
   enabled address family, and accept FEC-Label bindings for the
   enabled address family.
"

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Fri, 9 Jan 2015 23:22:01 +0000

Ok thanks Adrian. Yes, we should close quickly on the remaining points.

Mustapha.

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Wednesday, January 07, 2015 11:46 AM
> To: Aissaoui, Mustapha (Mustapha); [email-masked]
> Cc: [email-masked]
> Subject: RE: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to LDP for
> > Can we also close on the IANA assignment for the new TLVs and
> > specifically for the Dual-Stack Capability TLV?
> >
> > I assume this will be drawn from the Common Hello Parameters range of
> > the LDP TLV Type Name Space. The next available value is 0x0409. I
> > appreciate if you
> could
> > confirm this value.
> 
> The document has been through IETF last call and with a few edits will be ready for
> processing by the IESG. After IESG approval, the IANA will make a provisional
> allocation of a code point that will be confirmed on publication of the RFC. The
> IANA is *likely* to allocate the next available value, but not if another I-D gets there
> first :-)
> 
> Constructive discussion of the remaining issues with this draft should enable that
> to complete quickly.
> 
> Thanks,
> Adrian

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sat, 10 Jan 2015 03:27:31 +0000

Hi Mustapha, 

Thanks for the clarity.

1. You have a fair point. While it is implicit that section 2.5.5 of RFC
5036 (maintaining hello adj) would apply, it is reasonable to make it
explicit. We can add the below text -

//A Dual-stack LSR MUST still follow section 2.5.5 of RFC5036 and check
for matching Hello
messages from the peer (either all Hellos also include the Dual-stack
capability (with same TR value) or none do).//

2. This is already covered in both 3a and 3b by the following verbiage
"However, if IPv6 hellos are also received at any time from that
neighbor..” in the beginning of 2nd para. Note "at any time” here.

The text is sufficient, IMHO.

3. Closed. 

4.5. Ok. The following "(even if IP capability negotiation for IPv6
address family was done)” is appended to make it explicit. And Thanks for
catching the copy-paste error. :) Fixed.

Closed.

-----Original Message-----
From: <Aissaoui>, Mustapha Aissaoui <[email-masked]>
Date: Friday, January 9, 2015 at 6:19 PM
To: Rajiv Asati <[email-masked]>, IETF Discussion <[email-masked]>,
IETF-Announce <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates
to LDP for IPv6) to Proposed Standard

>>for a peer)
>MA> This could occur during a hitless upgrade for Hello adjacencies from
>different line cards during a transient time. I will not insist on this
>point but I found the draft lacks what action to take if the Hello
>messages received on parallel links from the same LSR are not consistent,
>meaning they have different TR values or the message on one link do not
>have the DS capability. The only thing I found is this paragraph in
>Section 6.1.1 but it does not say what to do if an LSR receives
>inconsistent Hello messages:
>"
>MA> What I was talking about is a transition from state 2a to state 3a or
>from state 2b to state 3b in Section 6.1.1. Perhaps one way to explicitly
>state that the session is bounced would be to add something like this to
>items 2a and 2b of Section 6..1.1:
>"
>   do not include the Dual-stack capability TLV, the session is
>terminated and a fatal Notification message is sent with     status code
>of 'Dual-Stack Non-Compliance' (IANA allocation TBD).*
>"
>
>
>> 
>MA> Yes I wanted something more explicit. This section certainly says the
>IPv6 prefix FEC capability can further constrain a particular FEC type
>which is allowed by the check of the DS capability TLV. It however does
>not discuss the negative case, i.e., the DS capability TLV did not allow
>a FEC type but the IP capability allowed it.
>BTW, there is a "copy & paste" mistake in the following paragraph in the
>same Section 7.2. The "via ADDRESS message" is not correct here since
>this is about FEC distribution, hence Label Mapping message, and not
>address distribution.
>"
>>sure

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Mon, 12 Jan 2015 15:52:23 +0000

Hi Rajiv,
I am good with your response below. Thanks!

Mustapha.

> Sent: Friday, January 09, 2015 10:28 PM
> 5036 (maintaining hello adj) would apply, it is reasonable to make it explicit. We
> can add the below text -
> 
> //A Dual-stack LSR MUST still follow section 2.5.5 of RFC5036 and check for
> matching Hello messages from the peer (either all Hellos also include the Dual-
> stack capability (with same TR value) or none do).//
> 
> 
> 
> 2. This is already covered in both 3a and 3b by the following verbiage "However, if
> IPv6 hellos are also received at any time from that neighbor..” in the beginning of
> 2nd para. Note "at any time” here.
> 
> 4.5. Ok. The following "(even if IP capability negotiation for IPv6 address family
> was done)” is appended to make it explicit. And Thanks for catching the copy-
> paste error. :) Fixed.
> 
> Closed.
> 
> 
> --
> Cheers,
> Rajiv Asati

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 12 Jan 2015 17:25:47 +0000

Thanks, Mustapha.

From: <Aissaoui>, Mustapha Aissaoui <[email-masked]<mailto:[email-masked]>>
Date: Monday, January 12, 2015 at 10:52 AM
To: Rajiv Asati <[email-masked]<mailto:[email-masked]>>, IETF Discussion <[email-masked]<mailto:[email-masked]>>, IETF-Announce <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to LDP for IPv6) to Proposed Standard

Hi Rajiv,

Mustapha.

-----Original Message-----
From: <Aissaoui>, Mustapha Aissaoui <[email-masked]<mailto:[email-masked]>>
Date: Friday, January 9, 2015 at 6:19 PM
To: Rajiv Asati <[email-masked]<mailto:[email-masked]>>, IETF Discussion <[email-masked]<mailto:[email-masked]>>,
IETF-Announce <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates
to LDP for IPv6) to Proposed Standard
>> To: Aissaoui, Mustapha (Mustapha); [email-masked]<mailto:[email-masked]>; IETF-Announce
>> Cc: [email-masked]<mailto:[email-masked]>
>> From: <Aissaoui>, Mustapha Aissaoui
>><[email-masked]<mailto:[email-masked]>>
>> To: IETF Discussion <[email-masked]<mailto:[email-masked]>>, IETF-Announce
>><[email-masked]<mailto:[email-masked]>>
>> Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
>> >> Cc: [email-masked]<mailto:[email-masked]>
>> >>[email-masked]<mailto:[email-masked]>
>> >>[email-masked]<mailto:[email-masked]>
>> >> [email-masked]<mailto:[email-masked]>
>> >[email-masked]<mailto:[email-masked]>