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

[Xu Xiaohu <xuxh at huawei.com>]

Hi Mani,

-----邮件原件-----
> 发件人: Srimanikandan Ganesan [mailto:SGanesan at ExtremeNetworks.com] 
> 发送时间: 2009年8月5日 19:50
> 收件人: Xu Xiaohu; 'Prashant Jhingran (pjhingra)'
> 抄送: pim at ietf.org
> 主题: RE: [pim] 答复: 答复: DR priority adjustment automatically 
> according to the status of the tracked interfaces
> 
> If I try to understand your proposal, you want the DR to go 
> down only when all the uplinks are going down.

Yes, as long as there is still one exit to the outside network, we should
avoid DR switchover.
 
> So, if few of the links go down, would it be fine if we 
> continue to have convergence issues.
> 
> In extreme switches, we have tracking facility available with 
> VRRP which inform PIM and also VRRP will go down and VRRP 
> Master will take over the role. So, effectively PIM on the 
> VRRP Master will take the active role. And in this method, we 
> will track specific networks.

That's a good news. How to track specific networks since the whole multicast
sources may not be known by the last-hop PIM routers.
 
> I think, that approach would be a easy one to implement and 
> reliable one too, otherwise, it will be like putting too much 
> burden on the PIM to track all the active (S, G)s and (*, G)s.

In fact, the tracking mechanism can be an independent tool, which can be
used by VRRP or PIM, etc. IMHO, it'd better for PIM to be correlated with
the tracking mechanism itself, rahter than with some specific protocol, e.g
VRRP. For example, one may use HSRP, or there is some bugs occured with the
VRRP module. The easier, the better.  Of couse, your approach can still
work:)

Xiaohu

> -----Original Message-----
> From: Xu Xiaohu [mailto:xuxh at huawei.com]
> Sent: Wednesday, August 05, 2009 1:53 PM
> To: Srimanikandan Ganesan; 'Prashant Jhingran (pjhingra)'
> Cc: pim at ietf.org
> Subject: 答复: [pim] 答复: 答复: DR priority adjustment 
> automatically according to the status of the tracked interfaces
> 
> Hi,
> 
> > I am afraid whether tracking would be possible as suggested by you.
> >
> > Because you have mentioned about one source network from 
> which traffic 
> > is received.
> 
> It's just an example for illustrating the basic idea;)
> 
> > But in real scenario, there could be "n" number of source networks, 
> > i.e. (S, G) entries would be available. And the uplink 
> could be down 
> > for some "S" network where as there could be many active 
> (S, G), (*, 
> > G) trees would be present.
> 
> In the case that there are more than one upstream links on 
> the last-hop PIM router (as DR), all of them should be 
> tracked. If all of them down,  the PIM router could cease the 
> DR role.  However, in most cases, two last-hop routers each 
> with ONE uplink are enough for redundancy.  Note that the 
> uplink rent is not cheap.
> 
> > And I don’t know whether it will be a good idea to 
> downgrade ourselves 
> > to be non DR would be a good idea for these conditions.
> >
> > So, my two cents would be, the VRRP (or) HSRP should have tracking 
> > mechanism for specific source networks and they should 
> control these 
> > kind of scenerios.
> 
> Unfortunately no, the tracking mechanism in VRRP or HSRP is 
> not that intelligent as you expected. Hence, what I proposed 
> is just the same as the usage in VRRP, and I think this 
> mechanism can shoot most cases.
> 
> 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 12:49 PM
> > To: 'Prashant Jhingran (pjhingra)'
> > Cc: 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
> >
> > DISCLAIMER:
> > This e-mail and any attachments to it may contain confidential and 
> > proprietary material and is solely for the use of the intended 
> > recipient. Any review, use, disclosure, distribution or copying of 
> > this transmittal is prohibited except by or on behalf of 
> the intended 
> > recipient.  If you have received this transmittal in error, please 
> > notify the sender and destroy this e-mail and any 
> attachments and all 
> > copies, whether electronic or printed.
> >
> 
> 
> DISCLAIMER:
> This e-mail and any attachments to it may contain 
> confidential and proprietary material and is solely for the 
> use of the intended recipient. Any review, use, disclosure, 
> distribution or copying of this transmittal is prohibited 
> except by or on behalf of the intended recipient.  If you 
> have received this transmittal in error, please notify the 
> sender and destroy this e-mail and any attachments and all 
> copies, whether electronic or printed.
>