Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input

From: Carlos Pignataro <[email-masked]>
Date: Sat, 01 Oct 2011 10:06:01 -0400

Hi Rajiv,

Please see inline my 2¢, disclaimer I'm co-author.

On 9/22/2011 4:52 PM, Rajiv Asati (rajiva) wrote:
> While this document passed the WGLC without any comments, we wanted to
> bring up an issue to seek your feedback.

Thanks Rajiv for polling the WG! This is the last pending comment on
this doc.

> 	
> The issue is that the current LDP spec rfc5036 allows an LDP peer to
> advertise IPv6 bindings to an LDP IPv4 peer, even though the peer may
> not have any IPv6 enabled (or IPv6 LDP), and vice versa*. See figure 3
> in section 1.1.1 of ldp-ipv6 document. 
> 
> While mpls-ldp-ipv6 section 7** addresses this issue (by checking for v6
> hello adj, in line with existing 'targeted adj check for PW binding
> advertisement'), we want to pose the following questions:
> 
> (1) is this a reasonable issue to be fixed? 

Yes.

The problem description is that of what bindings to advertise, under
which conditions (or negotiations), for different FECs.

> (2) is ldp-ipv6 document the right place to fix it?

No.

The problem space is larger than the scope of this I-D, as per its
Abstract ("LDP behavior when IPv6 network is used".) I fear that
crafting a solution here would be rushed and would not do justice to a
complete analysis of the problem space. See below.

> (3) is the solution highlighted in section 7 a reasonable solution, if
> you answered yes to both 1 and 2?

I am not sure... I sense that tying label/FEC mapping exchanges to the
transport Hello Adjacency is an approach that could break under some
conditions, as there is no inherent relationship between bindings and
hello adjacency -- should be tied to routing neighbor adjacency for the AF.

This solution is targeted to IPv4 and IPv6 AF for the Prefix FEC (and
BTW it would make all current IPv4 binding advertising out-of-spec), but
what about other AFs for this given FEC, and what about other FEC Types.

For example, what about the case of an LDP session for Pseudowires
(given that there is no "Pseudowire hello adjacency"? In this case, of
an LDP session for PW signaling, should LSRs advertise Prefix FECs
depending on the IPv4/IPv6 hello adjacency? And multicast? And ...?

I note that there are other potential solutions in documents (e.g.,
capability negotiation, outbound filtering), but there is no document
looking at the problem space more holistically. Lack of that, I sense
it's premature to include a narrow solution in an LDP-over-IPv6 document
-- after all, this is not a new problem, and exists with IPv4. And
moreover, some of the potential solutions to this do not need
standardization (i.e., can even be a local matter).

I look forward to seeing WG consensus emerge on this point.

Thanks,

-- Carlos.

> 
> You may answer simple yes/no to each Q, if you like.
> 
> Cheers,
> Rajiv
> 
> 
> 
> 
> 
> *	Consequently, an LDP peer advertising IPv4 bindings to
> 	an LDP IPv6 only peer, which doesn't have IPv4 any more
> 	(out in the future, of course).
> 
> 
> **
> 7. Label Distribution
> 
>    This document specifies that an LSR should advertise and receive
>    both IPv4 and IPv6 label bindings from and to the peer, only if it
>    has valid IPv4 and IPv6 Hello Adjacencies for that peer, as
>    specified in section 6.2.	
> 
>    This means that the LSR must not advertise any IPv6 label bindings
>    to a peer over an IPv4 LDP session, if no IPv6 Hello Adjacency
>    existed for that peer (and vice versa).
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Kamran Raza <[email-masked]>
Date: Sat, 01 Oct 2011 18:25:28 -0400

Please see inline for [skraza]

> (1) is this a reasonable issue to be fixed?
[skraza]: Yes.

> (2) is ldp-ipv6 document the right place to fix it?
[skraza]: No. 

This issue of "un-ncessary binding advertisement" is not ipv6 prefix FEC
specific, and currently exists for other type of LDP FECs as well. For
example, it is possible that an LSR may send IPv4 prefix FEC bindings on an
LDP session that mainly exist for PW FEC exchanges. Neither LDP RFC5036 [nor
PW RFC4447] explicitly disallow this. Similarly, this issue even exists
today within a single supported AF -- i.e. Often an LSR may end up
advertising LIB for entire IPV4 prefix table to its peers, though the
receiver may have interest only in few/handful of bindings.

There are already IETF drafts which are addressing the similar issues
mentioned above using different approaches/areas:

1) "LDP IP and PW Capability": draft-ietf-mpls-ldp-ip-pw-capability-00.txt
2) "LDP Outbound Label Filtering": draft-raza-mpls-ldp-olf-00.txt

So, IMHO, this draft is not the right place to address/fix it.

> you answered yes to both 1 and 2?

[skraza]: No. 

This changes the very core of base LDP Spec. LDP label binding advertisement
are bound to an LDP session and not LDP hello adjacencies. LDP Hello
adjacencies are used to maintain next-hop adjacency and MPLS forwarding
(labelled/unlablled) setup accordingly on given nextop IP path.

Tie-ing label advertisement decision with hello adjacency not only will
change very core of LDP base spec, but also be convergence impacting as
explained below:

Today, when an (hello) adjacency comes while session is already up and label
have already been exchanged, there is no/minimal delay in setting up
(labelled) MPLS forwarding after link/adj up (as labels are readily
available from nexthop peer).

Also, there are features like "Session protection" which are in place to
explicitly enforce this - where an LSR keeps LDP session up (and remote
labels intact) by means of special targeted-adj even when its one/more link
adj go down. This means that when the link adj comes back up, the forwarding
convergence is fast as it is not at all dependent on label advertisement
exchange/completion. By tie-ing label advertisement with adj state, we are
doing the exact opposite to what session-protection like features are trying
to achieve. 

Finally, adjacencies with repeated flaps will cause quite of a network churn
due to binding advertisement/withdrawal repeatedly. This churn will be more
visible and impacting in case of LSRs/network operating in "ordered" control
mode.

My 2 cents,
-- 
Kamran Raza
Cisco Systems, Inc.

---

From: Eric Rosen <[email-masked]>
Date: Mon, 03 Oct 2011 09:46:46 -0400

I agree with Carlos and Kamran, and would suggest the removal of section 7.

Also, the last paragraph of section 3 seems dubious:

   Additionally, it is desirable that a packet is forwarded to an LSP
   of an egress router, only if LSP's address-family matches with that
   of the LDP hello adjacency on the next-hop interface.

> not have any IPv6 enabled (or IPv6 LDP), and vice versa.

There is a general issue of how to prevent LDP from sending label bindings
to a particular peer, if the peer doesn't need those label bindings.  I
don't think the set of label bindings needed by the peer can be inferred
from the type of the Hello adjacency.

The information needed to choose the network layer protocol used by the LDP
session should not be used to infer the set of label bindings to be
distributed, as these are two independent choices.

I think proposals for constraining the set of advertised label bindings
should be outside the scope of this document.