Re: [pim] New Version Notification for draft-yong-rtgwg-igp-multicast-arch-00.txt

[Lucy yong <[e-mail]>]

Hi Ice,

Sorry for the very late response on your mail (http://www.ietf.org/mail-archive/web/pim/current/msg03055.html). Please see inline below.

Dear Lucy,

I have read through the draft, it reads very well, below are my comments:
Lucy: thanks.

1.1 Motivation

Ice: Creating a 'multicast' fabric can be done with PIM/mLDP/RSVP-TE as well, this is not a specific benefit of adding tree building inside of the IGP. Note that the MVPN procedures (RFC6513) described mechanisms similar to what is proposed in this draft, i.e. create a Mi-PMSI (default fabric) and S-PMSI (specific trees). And RFC6514 describes how to use auto-provision those trees. It is not clear to me from the draft (or use-case) that there is a reason to avoid BGP.
Lucy: yes, you can use another protocol to do multicast in IGP. The goal here is to use single IGP protocol for both unicast and multicast. It will simplify the network and allow automatic infrastructure network configuration. This is important for DC networks.

Ice: Longer convergence times of PIM compared to unicast are due to two factors, the delay of signalling from RIB to PIM AND the amount of state (trees) that need to be updated in the PIM database. The first delay is relatively small, say order of 100ms, the cost of updating a high number of PIM/mLDP trees is higher and increases with the amount of state.
Lucy: this is not always true. PIM convergence time is on top of the IGP convergence time.

3.2.2. Parallel Local Link Selection

Quote from draft:
   "....Note that if multiple distribution trees are configured in a domain
   or on a router, better load balance among parallel links through the
   tie-breaking algorithm can be achieved. Otherwise, if there is only
   one tree is configured, then only one link in parallel links can be
   used for the corresponding distribution tree. However, calculating
   and maintaining many trees is resource consuming. Operators need to
   balance between two ...."

Ice: It is very likely network operators want to take benefit of ECMP through the network, so having a single tree in the network is not an attractive option. Also, a 'default' single tree in the network will cause flooding and waisting of bandwidth (the nature of Tree aggregation). Putting the burden on the operators to choose their poison (Flooding or State) it not solving any problem for operators  compared to how multicast is deployed today. This is one of the key issues we need to address IMO.
Lucy: The solution builds one default tree and other trees if operator wants. So flooding can be avoided. There is no free lunch. All depend what is operator goal.

3.4. Pruning a Distribution Tree for a Group

Ice: I can see it could be useful to use the link state database to build a tree, but if we're going down the path of creating multiple trees for different receiver populations, it means you need to maintain state for each of those trees. If we now compare this with mLDP/PIM, you end up with the same amount of state, its just that it is signalled via the IGP. The way the tree is calculated in the IGP is different from how PIM/mLDP does it, but its not clear if using the IGP database is any better.
Lucy: singling via IGP saves mcast convergence time and allows IGP network automatically configured.

4.4. Reverse Path Forwarding Check (RPFC)

Ice: This section raises an important issue. The advantage of using the IGP database to build a tree is that it follows the (forward looking) unicast path towards its destination(s). There is no dependency on the RPF check as we know it from PIM and mLDP, which is a simplification. Not having the RPF check makes you more receptive to loops, as you indicated in this section. By adding RPFC back into the mix to prevent loops, we're now combining the 'forward looking' path selection done by the upstream router and the 'backwards looking' (RPFC) accept mechanise on the downstream router. If there are async paths in the network there is no guarantee they select the same link, causing the downstream router to incorrectly drop the packets.
Lucy: RPFC mechanism is built in and can be used. In fact, just check source IP address on the packet against ucast db. The solution addresses how to ensure upstream and downstream select the same path in a tree. The problem you state is not the case.


Summarising:

Using the IGP Link State Database to build an IGP Tree per Root could be useful in some scenario's, but the lacking of RFC check make this IGP Tree much more receptive to loops. I think this is a big concern and adding back the RPF check back into the mix just complicates the solution.

Its is not clear that the procedures and mechanisms to build pruned IGP Trees are any simpler then how PIM/mLDP/RSVP-TE trees are build.
Lucy: the solution does not simply here. It is similar to PIM.
When looking at the amount of state maintained in the network, its probably the same. Saying that doing IGP Tree building is better because there is no need to run an other protocol like PIM/mLDP is misleading. Obviously the procedures added into the IGP come with a cost, in complexity, state and signalling requirements. This is not something that comes for free and now everybody who understand unicast IGP knows how the multicast procedures work.
Lucy: again, we clearly state the motivation for IGP multicast. It has some very useful case for DC network. Not sure how many DC network deploy PIM yet.

If the problem we are trying to solve is driven by 'plug and play' and/or auto provisioning, there are existing BGP mechanisms that we can use in combination with PIM/mLDP/RSVP-TE.
Lucy: add another protocol to achieve that? How complex level we want to go here while we can use one protocol to achieve it? No wonder why IT people want to some revolution on the network.

Sorry again for the late response.

Thanks,
Lucy

Thx,

Ice.