The MPLS WG Archive

[IJsbrand Wijnands <ice@cisco.com>]

Hi Shuying,


> Hi all,
>    At IETF 65 in dallas, we all made presentations. I proposed a 
> mechanism to minimize packet loss during upstream LSR change in P2MP. 
> In case of network failure, I would simplify the process of 
> reconnecting the P2MP LSP to minimize packet loss. In case of route 
> changing, the main idea of the mechanism is 'make before break'. In 
> your presentation, you mentioned that you would do some work 
> to minimize packet loss during upstream LSR change.
>    In my opinion, in case of route changing, 'make befor break' may 
> be a preferable mechanism, but it should be simple. In case of network 
> failure, there may be two ways to minimize packet loss. One way is 
> to do some work before the network failure, like 'frr', so we could 
> learn some methods from IPfrr and rfc4090. the other way is to do some 
> work after failure, like the methods in our drafts, but it should be 
> simple and minimize the time of taffic disruption.
>    I expect some comments on my 
> draft(draft-liu-mpls-ldp-p2mp-reroute-00.txt) from you. I also expect 
> to discuss this work with you. 

I've went through the draft in some more detail and compiled the 
following higher level commands.

1. Simplicity and scalability.

In the draft you mention that you are solving a scalability problem 
that exists while converging from an old to a new upstream LSR. And in 
the email above you mention that this is done in a simple way. I think 
both of those goals are not met. In your draft you propose to decouple 
the convergence of an LSP from unicast routing changes. Instead you 
propose to converge based on link failure and re-optimize the LSP based 
on new LDP messages, the 'Path Modify message' and 'Path Check 
messages'. At the end of the day you want to converge the tree to 
follow the best path, so you are not sending any less label mappings 
then compared to what is documented in draft-ietf-mpls-ldp-p2mp-01. So 
I don't see why this is more scalable.

2. Convergence based on link failure.

You propose to converge the P2MP LSP based on link failure in stead of 
routing changes. In the draft you mention that convergence over 
ethernet interfaces is out of the scope. I don't think you can propose 
a solution that does not include a solution for ethernet type 
interfaces. It is obvious that the solution you propose does not work 
over ethernet interfaces, saying that it is out of scope is a little 
bit too easy to get away with ;-)

I've more concerns on converging based on link failure, see below.

       ---------- < C >--------
       |                       |
    < root > ---- < A > ---- < B > ---- Receiver.

The initial LSP path is root - A - B - receiver.

Now the link fails between the root and A. LSR A will detect the 
failure and send out a label mapping to B to converge to the newly 
learned path. LSR B does not converge based on unicast routing changes 
so the upstream LSR remains A. LSR B now receives a label mapping from 
its upstream LSR A. What is LSR B supposed to do here? According to 
your draft is must wait for the Path Check message before it 
re-evaluates if it is on the shortest path. But until that time the LSP 
is broken.

3. Forwarding state in the LFIB.

This section is one of the most controversial in the draft. In your 
proposal you end up with 2 upstream LSRs for a single P2MP FEC entry. 
You don't want to accept labeled packets from both since that would 
cause duplication. You propose to solve this problem by listening to 
unknown (multicast?) packets. These packets are punted from the 
forwarding path to the process level and used to influence the protocol 
logic. This is a major scalability concern since you don't want to punt 
every unknown multicast packet to the protocol level. Also, how do you 
know its a multicast packet? It looks like you propose the LFIB will 
inspect the L3 header to know if this is a multicast packet or not. I 
think is bad practice.

Thx,

Ice.


_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls