Re: [mpls] wg last call and IPR poll on draft-ietf-mpls-ldp-ipv6-07

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

Loa, Mustapha, 

Sorry about the delay. :(

First, it is important to note that dual-stack is a Œtransition state¹,
whereas IPv6-only is the Œend-state¹ for every network (for long time to
come).  We got to ensure that we design LDP for the end-state (IPv6-only)
and accommodate the transition-state (dual-stack) with minimal changes.

 
Your point, which is applicable only to the dual-stack scenario, seems to
boil down to - sending (and receiving) both LDP IPv4 link hellos and LDP
IPv6 link hellos on a dual-stack interface (that is enabled with both LDP
IPv4 and LDP IPv6) is neither needed, nor beneficial. Well, we assert that
it is needed/beneficial for the following reasons (each explained further
later**):,

 
1- Single-stack vs Dual-stack related to hello
2- Session bootstrapping tied to hello
3- Next-hop Label resolution tied to (v6) hello adj
4- Hello timer pacing

 
Additionally, our assertion discounts the below reasons:
5- Label advertisement tied to hello adj
6- Label Packet forwarding tied to hello adj

 
 
Before we get to the details below, let us reiterate that sending both LDP
IPv4 and IPv6 link hellos in case of dual-stack interface:.
  a) doesn't change anything for targeted hello (same as that of today),
  b) has no bearing on whether the implementation maintains separate
structures for IPv4 and IPv6 link hello or not
  c) is backward compatible with RFC5036 (for ex, if R1 is enabled with
this draft, whereas R2 is not, then R1 will not receive any LDP IPv6 link
hello from R2, which will ignore the IPv6 link hello sent by R1)
  R1------R2
 
 


** Here are the detailed reasons:
 

1. Single-stack vs Dual-stack -- simplest and easiest transition between
dual-stack and single-stack LDP -- moving single-stack IPv4 to dual-stack
results in adding IPv6 link hello exchange, and moving dual-stack to
single-stack IPv6 LDP results in removal of IPv4 link hello exchange.

 
We must note that dual-stack multi-access interface, an LSR would likely
end up sending (and receiving) both IPv4 and IPv6 link hellos anyway,
since not all LSRs on that interface will support / prefer IPv4 or IPv6
transport the same way. Again, simplicity is the key here.


                   
2. Session bootstrapping -- LSRs need to discover v4 or/and v6 transport
that the peer is willing to use for bootstrapping the subsequent TCP/LDP
session (and quickly resort to using the alternate transport if the
preferred transport failed) in case of dual-stack LDP. Having both hello
adjacencies facilitate this, needless to say.
 

                  This is similar to that of happy eyeball RFC 6555 that
enables dual-stack device to choose between IPv4 and IPv6 (with a bit of
preference for IPv6) for the subsequent TCP session.

 
It is a bad idea to have IPv4 hellos bootstrapping an IPv6 TCP session
(analogically, it is a bad idea to assume that road is good for the bus
just because it is good for the cycle) or vice versa.

 
Of course, once the session has been established, it is certainly an
option to drop the hello adj that didn¹t get used. We can now deem that as
a local behavior and an implementation choice. However, in case of a
multi-access interface, it is highly likely that LSRs will end up having
to send both IPv4 and IPv6 link hellos and maintain dual-stack hello adj,
as mentioned earlier.


 
3. Next-hop Label resolution tied to (v6) hello adj -- The section 2.7 of
rfc5036 is very clear about 'label resolution' and leaves no room for
misinterpretation. The fact of the matter is that duplicate IPv6
Link-local Addresses (serving as the routing next-hops) is one of the
hallmarks of IPv6, and section 2.7 it is not sufficient for IPv6 FEC label
resolution if based just on routing next-hops.

 
Perhaps, this example scenario (in which R3 and R5 use the same LLA
(=LLA2) on R3-R2 and R5-R2 links respectively (R2 connects to both R3 and
R5)) can help:

 
R1--R2----R3---R4----"x"
       
\-----R5-----------"y"
 

R1 has an IPv6 route to ³x² via R2 with next-hop = LLA-x2
R2 has an IPv6 route to ³x² via R3 with next-hop = LLA2
R2 has an IPv6 route to ³y² via R5 with next-hop = LLA2.
 

Relying on just RFC5036 section 2.7 that describes the next-hop/label
resolution using ADDRESS message (and says nothing about Hello), R2 would
attempt to resolve next-hop=LLA2 for FEC ³x² and find two neighbors=R3 and
R5 that advertised LLA2 in their ADDRESS messages. R2 has now no way to
figure out which one is the correct next-hop, and could map LLA2 to R5 and
use R5's label (if any) while forwarding to R3 (because the next-hop
interface is still pointing to R3).

Result = misrouting/blackholing of the traffic to ³x².
 

That¹s why the proposed logic (in section 8), relying on IPv6 Hello adj,
is needed to avoid traffic blackholing or misrouting (of packets going on
LSPv6) by enabling the LSR to resolve the label correctly using the hello
adjacency table when/if duplicate IPv6 LLAs are used as the routing
next-hops. LDP IPv6 must be able to bind to the right interfaces to result
in the right forwarding behavior. The proposed logic is the simplest and
easiest way to handle the issue without relying on any extra capability or
message.
 

We must consider IPv6-only network as well as dual-stack network, and we
should consider minimal changes to the protocol itself. Sending IPv4 and
IPv6 link hello requires no changes to the protocol, suffice to say.

 
 
5. Label advertisement tied to hello adj -- Good catch. This was an
oversight on our part, as it got changed from MAY to SHOULD after our
chair & AD suggested that change (as it didn¹t sound right earlier). We
will fix this by changing it back to MAY in the next version, and by
revising the text in the first two paragraphs of section 7 to something
like what¹s shown below:

 
//
Section 7. Label Distribution
 
An LSR MAY constrain the advertisement of all IPv4 FEC-label bindings or
all IPv6 FEC-label bindings using one of the two dynamic methods ­ (a) LSR
advertises IP FEC-label binding only for the AFI that matches with that of
the Hello Adjacency per peer, (b) LSR negotiates the IP Capability for a
given AFI, as specified in [IPPWCap
<http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-07#ref-IPPWCap>] and
advertises the IP FEC-label binding for the negotiated AFI(s) per peer.
//

 
6. Label Packet forwarding tied to hello adj ­ This is no longer the case,
as (to be) reflected in the -08 version.

 
We hope that this response is helpful for coming to a consensus on this
document. We certainly appreciate your critical feedback.
 
 



Cheers
Co-authors 


-----Original Message-----
To: Loa Andersson <loa at pi.nu <mailto:[e-mail]>>, "mpls at
ietf.org <mailto:[e-mail]>" <mpls at ietf.org
<mailto:[e-mail]>>

Subject: Re: [mpls] wg last call and IPR poll on
draft-ietf-mpls-ldp-ipv6-07
From: "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui at
alcatel-lucent.com <mailto:[e-mail]>>
Date: Tue, 12 Jun 2012 09:16:34 -0500



>Loa,
>
>Yes, we are in sync. We will submit the updated document in a week or two
>and also follow up on the mailing list.
>
>Cheers,
>Rajiv
>
>> Hi Loa,
>>I raised a couple of major issues with this draft and proposed a
>>solution to address them. I have discussed these at length with the
>>authors on this mailing list but it does not seem we are making any
>>progress to address it.
>>
>>I have summarized the issues below as well as a possible solution. Since
>>thes issues cause backward compatibility with RFC 5036, I do not believe
>>we can publish the draft in its current version.
>>
>>Regards,
>>Mustapha.
>>=========================================================================
>>============
>>Issues in draft-ietf-mpls-ldp-ipv6:
>>
>>1. Current version of LDP IPv6 draft mandates maintaining a Hello
>>adjacency for each of IPv4 and IPv6 over a dual-stack interface between
>>two LSRs but will bootstrap a single LDP session (IPv4 or IPv6). RFC
>>5036 allows bootstrapping of an IPv6 session by an IPv6 Hello adjacency
>>OR bootstrapping of an IPv4 LDP session by an IPv4 Hello Adjacency over
>>the same IP interface.
>>The proposal in this draft doubles number of Hello adjacencies and
>>breaks backward compatibility with RFC 5036 for no gain.
>>
>>2. Current version of LDP IPv6 draft ties the FEC types resolved over a
>>given interface to the type of adjacency. This violates RFC 5036 which
>>allows any FEC type (unicast IPv4, unicast IPv6, mLDP p2mp FEC, PW FEC)
>>over an interface regardless of the Hello adjacency is IPv4 or IPv6. A
>>Hello adjacency over a link is an assertion that a link is associated
>>with the LDP session with the peer, meaning FECs exchanged over the
>>session can be programmed over those links, and nothing else. The
>>control of which FEC type is resolved over which interface is controlled
>>via LDP capability and/or LDP FEC policies.
>>
>>3. There is no need to maintain two link Hello adjacencies over the same
>>interface for resolving an IPv4 or an IPv6 FEC. We just published a
>>draft to specify LDP adjacency capability negotiation. This is the
>>correct way to control which FECs can be resolved to a link such that we
>>can keep IPv6 and IPv4 FEC resolution compatible with RFC 5036 in the
>>case of dual-stack interfaces:
>>http://www.ietf.org/id/draft-pdutta-mpls-ldp-adj-capability-00.txt
>>
>>=========================================================================
>>======== 
>> 
>> 
>> On 2012-06-20 18:28, Loa Andersson wrote:
>> > Working Group,
>> >
>> > this working last call has been closed.
>> >
>> > We have had comments, could the authors please work with the
>> commenter
>> > to resolve the comments and if necessary republish a new version of
>> > the draft!
>> >
>> > /Loa
>> >
>> > On 2012-06-11 08:20, Loa Andersson wrote:
>> >> Working Group,
>> >>
>> >> this is to start a one week working group last call on
>> >> draft-ietf-mpls-ldp-ipv6-07.
>> >>
>> >> Bckground - the draft was passed working group last call in August
>> >> last year, and it should from that perspective be OK to request
>> >> publication.
>> >>
>> >> However;
>> >>
>> >> - it is a bit too long ago
>> >> - after the wg last call a discussion, that did not really cause any
>> >>    changes to the draft, that generated great interest.
>> >>    The background was that for the 32-bit LSR-id an routeable IPv4
>> >>    address has often been used in IPv4 networks. Thre were interest
>>of
>> >>    using an routeabel  IPv6 address for LSR-id in IPv6 networks.
>> >>    It was decided not to go down this path, since it would have huge
>> >>    impact on the LDP protocol itself and all the HW implementations.
>> >>
>> >> This working group last call is limited to the changes between
>> >> version
>> >> -06 and -07.
>> >>
>> >> Also since this draft was through wg last call before we explicitly
>> >> started to poll for IPRs on our draft, we need to do that now.
>> >>
>> >> Listed authors need to make an explicit statement to the working
>> >> group and working group chairs that all the IPRs they now of has been
>> >> disclosed or that they are not aware of any IPRs
>> >>
>> >> Other working group members that har aware of IPRs should state so on
>> >> the working group mailing list.
>> >>
>> >> This working group last call and IPR poll ends June 18th, 2012.
>> >>
>> >> /Loa
>> >> for the mpls wg co-chairs
>> >>
>> >>
>> >
>> 
>> --
>> 
>> 
>> Loa Andersson                         email: [e-mail]
>> Sr Strategy and Standards Manager            [e-mail]
>> Ericsson Inc                          phone: [phone]
>>                                               [phone]