[pim] 答复: 答复: 答复: DR priority adjustment automatically according to the status of the tracked interfaces

[Xu Xiaohu <xuxh at huawei.com>]

Another side-effect of using failover static route is: when the uplink
recovers (from down to up), the RPF interface will change. As a result, the
transient forwarding interruption due to SPT/RPT rebuilding will occur.
Although this transient interruption issue due to unicast route change can
be solved by some make-before-break mechanism (borrow some ideas from
RPT->SPT switch mechanism, that is: untill the stream is received from the
new upstream link, the old upstream link will not be pruned), as I mentioned
in the PIM session of Dublin IETF meeting, the cost is relatively high for
this scenario.

With the DR auto-adjustment mechanism,  DR priority can be recovered or not
according to the pre-configured preemption policy. For example, if
preemption is disabled, the DR will not switch over so as to avoid the
unnecessary SPT/RPT rebuilding.

Xiaohu

> -----邮件原件-----
> 发件人: pim-bounces at ietf.org [mailto:pim-bounces at ietf.org] 代表 Xu Xiaohu
> 发送时间: 2009年8月5日 16:05
> 收件人: 'Prashant Jhingran (pjhingra)'
> 抄送: pim at ietf.org
> 主题: [pim] 答复: 答复: DR priority adjustment automatically 
> according to the status of the tracked interfaces
> 
> 
> > -----邮件原件-----
> > 发件人: Prashant Jhingran (pjhingra) [mailto:pjhingra at cisco.com]
> > 发送时间: 2009年8月5日 15:31
> > 收件人: Xu Xiaohu
> > 抄送: Su Haiyang; pim at ietf.org
> > 主题: RE: [pim] 答复: DR priority adjustment automatically according to 
> > the status of the tracked interfaces
> > 
> > You have a valid point but I would say network configuration/design 
> > should take care of this.  In absence of a dynamic mechanism (IGP), 
> > perhaps a failover static route might be good enough.
> 
> Use default route with higher cost? it can works in some 
> cases. However, this usage stil has some side-effect. Assume 
> these two routers are connected to an ISP network via 
> different links, once the default route learnt from the ISP 
> is withdrawn, the forwarding loop will occur within the shared LAN.
> 
> Xiaohu
> 
> > -----Original Message-----
> > From: Xu Xiaohu [mailto:xuxh at huawei.com]
> > Sent: Wednesday, August 05, 2009 12:49 PM
> > To: Prashant Jhingran (pjhingra)
> > Cc: 'Su Haiyang'; pim at ietf.org
> > Subject: 答复: [pim] 答复: DR priority adjustment automatically 
> according 
> > to the status of the tracked interfaces
> > 
> > 
> > > PIM-SM RFC takes care of such scenarios, following explains
> > the same:
> > > 
> > > - Once the uplink on R1 goes down, R1's next-hop towards
> > source would
> > > be via R2. IGP convergence would take care of this.
> > > - R1 should continue to act as DR as before, however the SG/*G 
> > > upstream interface would change as interface towards R2 (i.e. LAN
> > > interface)
> > > - R2 should add interface towards R1 as OIF while IIF as upstream 
> > > towards source (PIM-SM network)
> > > - On R1 oiflist = oiflist (-) iif so although R1 would 
> receive data 
> > > traffic from R2, router R1 would not be sending it back on LAN 
> > > interface
> > >   => Hence Assert like condition would not arise.
> > > => However, client would continue to receive mcast data as
> > before (it
> > > doesn't care which router is DR and who is fwd to it etc),
> > and hence
> > > nothing to worry !
> > 
> > However, in most cases, there is no IGP running between R1 
> and R2 via 
> > the shared edge LAN. Even though IGP is ran, the interface 
> is usually 
> > set to silent mode interface due to many reasons, e.g.  the routing 
> > security consideration, routing information flooding avoidance. 
> > Besides, for some small-scale edge site networks (e.g. only a LAN), 
> > static route, other than IGP is usually used.
> > 
> > Xiaohu
> > 
> > > -----Original Message-----
> > > From: pim-bounces at ietf.org [mailto:pim-bounces at ietf.org] On
> > Behalf Of
> > > Xu Xiaohu
> > > Sent: Wednesday, August 05, 2009 9:33 AM
> > > To: 'Su Haiyang'; pim at ietf.org
> > > Subject: [pim] 答复: DR priority adjustment automatically
> > according to
> > > the status of the tracked interfaces
> > > 
> > > 
> > > >   PIM is designed as a protocol independent multicast. 
> > The route to
> > > > source/RP PIM depend on is up to IGP, not it self.
> > > 
> > > Yes, PIM is Protocol Independent Multicast. However, it is
> > not a ROUTE
> > > indepedent multicast protocol.
> > > 
> > > > Just like the topology you give, the LAN is a backup
> > > transit network
> > > > to DR's up link. Why IGP doesn't converge through LAN to
> > > reach RP or
> > > > Source,
> > > 
> > > I gather you are not much falimiar with the real network 
> > > configuration. Why don't you ask why we need VRRP or HSRP?
> > > 
> > > Xiaohu
> > > 
> > > > -----Original Message-----
> > > > From: Xu Xiaohu [mailto:xuxh at huawei.com]
> > > > Sent: Wednesday, August 05, 2009 11:39 AM
> > > > To: 'Su Haiyang'; pim at ietf.org
> > > > Subject: 答复: [pim] DR priority adjustment automatically
> > > according to
> > > > the status of the tracked interfaces
> > > > 
> > > > 
> > > > >   I don't think that it is necessary for a DR to track
> > > it's upstream
> > > > > link to a source or RP, since IGP would care it for 
> PIM. When a 
> > > > > router's link to a source or RP is down, IGP would 
> converge to 
> > > > > another link to reach the source or RP. If there is no
> > > other link to
> > > > > source or RP, IGP may be fail to find a new route.
> > > > 
> > > > If all uplinks are down, what do you want the DR to do next?
> > > > 
> > > > > But isn't that be a poor topology?
> > > > 
> > > > Poor topology?  Two routers, each with a uplink to the
> > > Internet, are
> > > > used on a LAN for redundancy. Not enough?
> > > > 
> > > > Or do you even believe the tracking mechanism used in VRRP
> > > or HSRP is
> > > > useless?
> > > > 
> > > > Xiaohu
> > > > 
> > > > > -----Original Message-----
> > > > > From: pim-bounces at ietf.org [mailto:pim-bounces at ietf.org]
> > > On Behalf
> > > > > Of Xu Xiaohu
> > > > > Sent: Wednesday, August 05, 2009 11:00 AM
> > > > > To: pim at ietf.org
> > > > > Subject: [pim] DR priority adjustment automatically
> > > according to the
> > > > > status of the tracked interfaces
> > > > > 
> > > > > Hi all,
> > > > > 
> > > > > In the following PIM-SM (or SSM) scenario, R!, R2 and
> > Client are
> > > > > located with the same LAN. R1 is elected as the DR for
> > > that LAN. Now
> > > > > R1's uplink to the PIM-SM Network  is down, as long as R1
> > > still acts
> > > > > as the DR, the multicast stream will be broken soon or later.
> > > > > 
> > > > >              |
> > > > >              |   +-----+    +------------------+
> > > > >              +---+ R1  +----+                  |
> > > > >              |   +-----+    |                  |
> > > > >  +-------+   |              |                  |  +-------+
> > > > >  |Client +---+              | PIM-SM Network   +--+Source |
> > > > >  +-------+   |              |                  |  +-------+
> > > > >              |   +-----+    |                  |
> > > > >              +---+ R2  +----+                  |
> > > > >              |   +-----+    +------------------+
> > > > >              |
> > > > > 
> > > > > I wonder whether it is suitable for the DR (e.g., R1 in
> > the above
> > > > > figure) to track the upstream link, and once the
> > tracked link is
> > > > > down, its DR priority is reduced automatically so as to
> > > cease the DR
> > > > > role. Of couse, this mechanism is also suitable for the
> > scenario
> > > > > where the Multicast Souce is connected to more than one
> > > PIM routers
> > > > > via LAN.
> > > > > 
> > > > > Any comment? Or whether some vendor has already 
> implement this 
> > > > > feature?
> > > > > 
> > > > > Xiaohu
> > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > pim mailing list
> > > > > pim at ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/pim
> > > > > 
> > > > 
> > > 
> > > _______________________________________________
> > > pim mailing list
> > > pim at ietf.org
> > > https://www.ietf.org/mailman/listinfo/pim
> > 
> 
> _______________________________________________
> pim mailing list
> pim at ietf.org
> https://www.ietf.org/mailman/listinfo/pim
>