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

[Kamran Raza <[e-mail]>]

Please see inline for [skraza]

On 11-09-22 4:52 PM, "Rajiv Asati (rajiva)" <[e-mail]> wrote:

> While this document passed the WGLC without any comments, we wanted to
> bring up an issue to seek your feedback.
> 
> 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?
[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.

> (3) is the solution highlighted in section 7 a reasonable solution, if
> 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.


> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls