Re: New Version Notification for draft-yong-rtgwg-igp-multicast-arch-00.txt
IJsbrand Wijnands <ice <at> cisco.com>
2014-11-10 19:23:14 GMT
I have read through the draft, it reads very well, below are my comments:
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.
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.
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.
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.
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.
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. 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.
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.
> -----Original Message-----
> From: rtgwg [mailto:rtgwg-bounces <at> ietf.org] On Behalf Of Lucy yong
> Sent: Tuesday, October 28, 2014 8:51 AM
> To: rtgwg-chairs <at> tools.ietf.org; rtgwg <at> ietf.org
> Cc: draft-yong-rtgwg-igp-multicast-arch <at> tools.ietf.org
> Subject: FW: New Version Notification for draft-yong-rtgwg-igp-multicast-arch-00.txt
> We upload this new draft and like to get your comments.
> The subject was proposed to IS-IS WG first. AD suggested splitting the original proposal into two: IGP
multicast architecture and IS-IS protocol extension, and work out the architecture in RTG WG.
> We will present this in Honolulu.
> -----Original Message-----
> From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org]
> Sent: Monday, October 27, 2014 4:54 PM
> To: Andrew Qu; Jon Hudson; Lucy yong; Haoweiguo; Lucy yong; Donald Eastlake; Andrew Qu; Donald E.
Eastlake 3rd; Jon Hudson; Haoweiguo
> Subject: New Version Notification for draft-yong-rtgwg-igp-multicast-arch-00.txt
> A new version of I-D, draft-yong-rtgwg-igp-multicast-arch-00.txt
> has been successfully submitted by Lucy Yong and posted to the IETF repository.
> Name: draft-yong-rtgwg-igp-multicast-arch
> Revision: 00
> Title: IGP Multicast Architecture
> Document date: 2014-10-27
> Group: Individual Submission
> Pages: 13
> URL: http://www.ietf.org/internet-drafts/draft-yong-rtgwg-igp-multicast-arch-00.txt
> Status: https://datatracker.ietf.org/doc/draft-yong-rtgwg-igp-multicast-arch/
> Htmlized: http://tools.ietf.org/html/draft-yong-rtgwg-igp-multicast-arch-00
> This document specifies Interior Gateway Protocol (IGP) network architecture to support multicast
transport. It describes the architecture components and the algorithms to automatically build a
distribution tree for transporting multicast traffic and provides a method of pruning that tree for
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and
diff are available at tools.ietf.org.
> The IETF Secretariat
> rtgwg mailing list
> rtgwg <at> ietf.org