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

[Vitkovský Adam <[e-mail]>]

Hello,

The main benefit I see in putting multicast signaling into IGP is the link-state properties that can be inherited/leveraged by the multicast. 
That is every node in the network knows where all the sources and all the receivers are connected to and how to transport traffic from any source to any receivers and how to fast re-route around the failed links. 

adam
> -----Original Message-----
> From: rtgwg [mailto:[e-mail]] On Behalf Of IJsbrand
> Wijnands
> Sent: Monday, November 10, 2014 8:23 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: New Version Notification for draft-yong-rtgwg-igp-multicast-
> arch-00.txt
> 
> Dear Lucy,
> 
> I have read through the draft, it reads very well, below are my comments:
> 
> 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.
> 
> 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.
> 
> 
> 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. 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.
> 
> Thx,
> 
> Ice.
> 
> 
> > -----Original Message-----
> > From: rtgwg [mailto:[e-mail]] On Behalf Of Lucy yong
> > Sent: Tuesday, October 28, 2014 8:51 AM
> > To: [e-mail]; [e-mail]
> > Cc: [e-mail]
> > Subject: FW: New Version Notification for draft-yong-rtgwg-igp-multicast-
> arch-00.txt
> >
> > Hello,
> >
> > 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.
> >
> > Thanks,
> > Lucy
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > 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
> >
> >
> > Abstract:
> > 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
> improved efficiency.
> >
> >
> >
> >
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtgwg
> 
> _______________________________________________
> rtgwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtgwg