Subject: [pim] 答复: call for adoption: draft-zhou-pim-vrrp-01

From: Xuxiaohu <[email-masked]>
Date: Mon, 3 Jun 2013 03:51:28 +0000

> -----邮件原件-----
> 发件人: Mike McBride [mailto:[email-masked]]
> 发送时间: 2013年5月31日 15:07
> 收件人: Prashant Jhingran (pjhingra)
> 抄送: Rajiv Asati (rajiva); Xuxiaohu; [email-masked]; Wei
> Zhou (weizho2); Stig Venaas; [email-masked]
> 主题: Re: [pim] call for adoption: draft-zhou-pim-vrrp-01
> 
> Thank you for the responses.
> 
> Some feel the two drafts are completely unrelated while others feel
> they are completely related. In either case, are you, who feel they
> are related, saying you oppose the adoption of draft-zhou-pim-vrrp-01?
> We can infer that is the case but I haven't heard explicitly stated
> opposition to adoption. We now have several choices for
> draft-zhou-pim-vrrp, let me try boiling it down to 3:
> 
> 1. adopt draft-zhou-pim-vrrp-01 as is
> 2. adopt draft-zhou-pim-vrrp-01 only after
> draft-xu-pim-drpriority-auto-adjustment is referenced.
> 3. merge the drafts

I prefer option 3.

Best regards,
Xiaohu

> In either case the authors should revive the expired
> draft-xu-pim-drpriority-auto-adjustment-03 for consideration within
> the wg irregardless of vrrp-01 adoption outcome.
> 
> What say ye?
> 
> mike
> 
> On Thu, May 23, 2013 at 2:08 AM, Prashant Jhingran (pjhingra)
> <[email-masked]> wrote:
> > Hi Mike,
> >
> > I agree with Rajiv, both drafts are trying to solve the same issue....that too in
> almost similar way.
> >
> > -
> > Regards,
> > Prashant Jhingran
> > NOSTG TME - SP Wi-Fi
> >
> > http://wwwin.cisco.com/ios/tech/mobile/proxyipv6/
> > http://wwwin.cisco.com/ios/tech/broadband
> >
> >
> > -----Original Message-----
> > From: Rajiv Asati (rajiva)
> > Sent: Thursday, May 23, 2013 3:06 AM
> > To: Mike McBride; Xuxiaohu; [email-masked]; Prashant
> Jhingran (pjhingra); Wei Zhou (weizho2)
> > Cc: Stig Venaas; [email-masked]
> > Subject: RE: [pim] call for adoption: draft-zhou-pim-vrrp-01
> >
> > Hi Mike,
> >
> > It seems that both drafts seem to solve nearly the same problem (multiple
> routers on the multi-access interface and existence of first-hop redundancy
> protocols e.g. VRRP).
> >
> > Cheers,
> > Rajiv
> >
> >
> >> -----Original Message-----
> >> From: Mike McBride [mailto:[email-masked]]
> >> Sent: Wednesday, May 22, 2013 2:17 AM
> >> To: Xuxiaohu; [email-masked]; Rajiv Asati (rajiva);
> >> Prashant Jhingran (pjhingra); Wei Zhou (weizho2)
> >> Cc: Stig Venaas; Mike McBride; [email-masked]
> >> Subject: Re: [pim] call for adoption: draft-zhou-pim-vrrp-01
> >>
> >> Folks,
> >>
> >> We have this new draft-zhou-pim-vrrp-01 which we are about to adopt
> >> into the pim wg. It has been brought to the WGs attention that there
> >> is a older draft (draft-xu-pim-drpriority-auto-adjustment-03) which
> >> may have some overlap with the new one. That older draft does contain
> >> information about VRRP aware PIM which is attributed to Stig in the
> >> acknowledgements. If the five of you authors feel that there is some
> >> validity that the older draft contains some information being used in
> >> the new draft, you may want to acknowledge that in the references or
> >> acknowledgements. It appears the drafts are dissimilar enough to not
> >> be merged but I may be wrong. Please share your opinions on this so we
> >> can establish consensus within the group and move the document along.
> >>
> >> If the broader WG participants have an opinion on this please speak up.
> >>
> >> thanks,
> >> mike
> >>
> >> On Thu, May 9, 2013 at 7:32 PM, Xuxiaohu <[email-masked]> wrote:
> >> > Hi all,
> >> >
> >> > This draft reminds me that there has been a draft
> >> (http://tools.ietf.org/html/draft-xu-pim-drpriority-auto-adjustment-03
> >> ) three years before which uses almost the same technology to save
> >> almost the same problem.
> >> >
> >> > The following is quoted from the above draft:
> >> >
> >> >    "In fact, if VRRP is run on the PIM routers and the VRRP has enabled
> >> >    the upstream link tracking mechanism, the PIM DR failover
> mechanism
> >> >    could be coupled with the VRRP so as to reuse the upstream link
> >> >    tracking mechanism of VRRP. One option is to synchronize the PIM DR
> >> >    priority value to the VRRP priority value always. In this way, the
> >> >    PIM DR and the VRRP master will always run on an identical router if
> >> >    the VRRP Preempt_Mode is set to True. Another option is to make the
> >> >    PIM DR and the VRRP master run on an identical router anyway (i.e.,
> >> >    regardless whether or not the VRRP Preempt_Mode is True). To
> achieve
> >> >    this goal, the PIM DR priority of the VRRP master router SHOULD
> >> >    always be set to a higher fixed value than that of the VRRP slave
> >> >    router automatically."
> >> >
> >> > Best regards,
> >> > Xiaohu
> >> >
> >> >> -----邮件原件-----
> >> >> 发件人: [email-masked] [mailto:[email-masked]] 代表
> >> Mike
> >> >> McBride
> >> >> 发送时间: 2013年5月10日 3:48
> >> >> 收件人: [email-masked]
> >> >> 主题: [pim] call for adoption: draft-zhou-pim-vrrp-01
> >> >>
> >> >> draft-zhou-pim-vrrp-01 was presented in our most recent pim meeting
> >> >> in Orlando. 4 people were in favor of adopting the draft. Zero against.
> >> >> Please read the draft (its short) and provide an opinion either way
> >> >> by the end of next Friday the 17th.
> >> >>
> >> >> http://www.ietf.org/id/draft-zhou-pim-vrrp-01.txt
> >> >>
> >> >> thanks,
> >> >> mike
> >> >> _______________________________________________
> >> >> pim mailing list
> >> >> [email-masked]
> >> >> https://www.ietf.org/mailman/listinfo/pim

---

From: Stig Venaas <[email-masked]>
Date: Mon, 03 Jun 2013 10:32:59 -0700

Hi

>> draft-xu-pim-drpriority-auto-adjustment is referenced.

I don't think we should simply do a vote here, we need to get an
understanding of what the WG wants and see if we have a rough
consensus. I think it would be helpful if people responding could
state why they believe so, this may lead to some useful discussion
and help people make up their mind.

As for merging, we need to see if the WG is interested in the content
of both the two drafts, and consider whether merging them makes sense.

We did have some support for adopting draft-zhou-pim-vrrp-01 in the
last meeting, while draft-xu-pim-drpriority-auto-adjustment was
discussed a few years ago, and people probably need to re-read it and
see what they think now.

Stig

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 4 Jun 2013 06:17:38 +0000

Hi Stig,

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Stig
> Venaas
> 发送时间: 2013年6月4日 1:33
> 收件人: Xuxiaohu
> 抄送: [email-masked]; Mike McBride; [email-masked]
> 主题: Re: [pim] 答复: call for adoption: draft-zhou-pim-vrrp-01
> 
> Hi
> 

Although draft-zhou-pim-vrrp attempts to address the transit network scenario additionally where VRRP is enabled, but IGP is disabled, there is one major overlap between these two drafts: to make the PIM last-hop/last-hop DR and the VRRP master run on the same router. 

> discussed a few years ago, and people probably need to re-read it and

For people to re-read it conveniently, a revision is available now at http://tools.ietf.org/html/draft-xu-pim-drpriority-auto-adjustment-04

Best regards,
Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 5 Jun 2013 03:19:42 +0000

Hi Wei,

> -----邮件原件-----
> 发件人: Wei Zhou (weizho2) [mailto:[email-masked]]
> 发送时间: 2013年6月1日 2:56
> 收件人: Mike McBride; Prashant Jhingran (pjhingra)
> 抄送: Rajiv Asati (rajiva); Xuxiaohu; [email-masked]; Stig
> Venaas; [email-masked]
> Hi,
> Thank you all for the comments and thoughts. I believe that the old draft
> is about upstream link failures, which is not what the new draft is about.
> The new draft is about how to support PIM and VRRP in general instead of
> focusing on the object being tracked.

If your draft is irrelevant to upstream link failure scenario, what's the motivation for making the PIM DR and the VRRP master always run on the same router? In other words, what's the problem when the PIM DR doesn't run on the VRRP master router? It seems that the below text quoted from your draft doesn't really state the FINAL problem. IMHO, it doesn't matter whether or not the multicast traffic is forwarded by the VRRP master router. In addition, "to ensure that the PIM DR is always able to forward PIM Join/Prune message towards RP or FHR", it doesn't require the PIM DR runs on the VRRP master router either.

===============================
  "PIM has no inherent redundancy capabilities and its operation is
   completely independent of VRRP group states.  As a result, IP
   multicast traffic is forwarded not necessarily by the same device as
   is elected by VRRP.  The VRRP Aware PIM feature provides consistent
   IP multicast forwarding in a redundant network with virtual routing
   groups enabled.

   In a multi-access segment (such as LAN), PIM designated router (DR)
   election is unaware of the redundancy configuration, and the elected
   DR and VRRP master router (MR) may not be the same router.  In order
   to ensure that the PIM DR is always able to forward PIM Join/Prune
   message towards RP or FHR, the VRRP MR becomes the PIM DR (if there
   is only one VRRP group)...."
===============================

Best regards,
Xiaohu

> If the WG think the upstream link failure scenario should be discussed in
> detail in the new draft, then I'm completely fine with merging. Moreover,
> if the new draft is adopted in its current shape, then the WG can always
> decide to include the upstream link failure scenario later.
> 
> Thanks,
> Wei
> 
> 
> 
> 
> 
> On 5/31/13 12:06 AM, "Mike McBride" <[email-masked]> wrote:
> 
> >> I agree with Rajiv, both drafts are trying to solve the same
> >>issue....that too in almost similar way.
> >>
> >> -
> >> Regards,
> >> Prashant Jhingran
> >> NOSTG TME - SP Wi-Fi
> >>
> >> It seems that both drafts seem to solve nearly the same problem
> >>(multiple routers on the multi-access interface and existence of
> >>first-hop redundancy protocols e.g. VRRP).
> >>
> >> Cheers,
> >> Rajiv
> >>
> >>

---

From: Stig Venaas <[email-masked]>
Date: Wed, 05 Jun 2013 10:01:25 -0700

So far we only got responses from the authors of the two drafts. To get
an understanding of how the WG is thinking, we would need responses from
other people too. So please help us out by reading the two drafts and
stating your thoughts on the matter. As I commented below, it is good if
you can state your thoughts and not just your vote though.

Technical discussion on both the two drafts is also very welcome.

Stig

---

From: "Wei Zhou (weizho2)" <[email-masked]>
Date: Thu, 6 Jun 2013 17:23:04 +0000

Hi Xiaohu,

Actually I would say it is not true that the new draft is "irrelevant" to
upstream link failure, which is one of the many scenarios that the new
general solution is trying to address.

If customer runs an IGP, then upstream failure is not an issue. On the
other hand if people want to they can configure VRRP to track link
failures, but that was not the focus of the new draft. Discussing the
different objects that different VRRP implementations may allow users to
track is not one of the purposes of the new draft, as that is not needed
to explain how VRRP interacts with PIM.

Moreover, it is definitely true that the new draft is proposing to make
PIM DR and VRRP Master run on the same router by adjusting PIM DR
priority, which I believe is the obvious way to make PIM respond to VRRP
state change and something both drafts support. If you have new/different
thoughts on this, please share.

So in addition to that obvious part shared by both drafts, may I know what
technical content/details you'd suggest to merge between the two drafts?

Thanks,
Wei

On 6/4/13 8:19 PM, "Xuxiaohu" <[email-masked]> wrote:

>If your draft is irrelevant to upstream link failure scenario, what's the
>motivation for making the PIM DR and the VRRP master always run on the
>same router? In other words, what's the problem when the PIM DR doesn't
>run on the VRRP master router? It seems that the below text quoted from
>your draft doesn't really state the FINAL problem. IMHO, it doesn't
>matter whether or not the multicast traffic is forwarded by the VRRP
>master router. In addition, "to ensure that the PIM DR is always able to
>forward PIM Join/Prune message towards RP or FHR", it doesn't require the
>PIM DR runs on the VRRP master router either.
>
>> >>> >    tracking mechanism of VRRP. One option is to synchronize the
>>PIM
>> >>>DR
>> >>> >    PIM DR and the VRRP master will always run on an identical
>>router
>> >>>if

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 7 Jun 2013 01:11:59 +0000

Hi Wei,

> 发送时间: 2013年6月7日 1:23
> 收件人: Xuxiaohu; Mike McBride; Prashant Jhingran (pjhingra)
> 抄送: Rajiv Asati (rajiva); [email-masked]; Stig Venaas;
> [email-masked]

What are the other scenarios that the general solution is trying to address?
 
> technical content/details you'd suggest to merge between the two drafts?

IMHO, that "obvious" part is the only practical problem that needs to be solved. The transit LAN scenario is a fake one, which has been explained in a previous email.

Best regards,
Xiaohu
 
> >> >>> >    the VRRP Preempt_Mode is set to True. Another option is to
> make
> >> >>>the

---

From: "Wei Zhou (weizho2)" <[email-masked]>
Date: Fri, 7 Jun 2013 02:35:10 +0000

Hi xiaohu,

As I mentioned in previous emails, any scenario that VRRP may track,
including interface state, line protocol, bandwidth etc, can be the
interested event. Again, the new solution is *not* trying to discuss the
details of any specific event such as upstream link failure described in
your previous draft.

More importantly, I believe it is incorrect or at least inaccurate to say
that "making VRRP Master and PIM DR to run one same router is the *only*
practical problem that needs to be solved", that is why the new draft
tries to address other practical problems like BIDIR, Assert and multiple
virtual groups, in order to provide a complete pim-vrrp interaction
solution - rather than simply adjusting the PIM DR priority. And that's
why I'd like to know what you would suggest to merge with the new draft
from technical point of view.

Regarding the transit network scenario, I am still not quite sure about
the reason why you described it as a "fake" scenario from your previous
comments. Are you saying that there is absolutely zero chance that any
customer will enable VRRP in any transit network scenario for any reason?
Please correct me if my understanding is wrong here, I believe it is
actually an interesting topic to discuss on the possible use cases here.

Thanks,
Wei

On 6/6/13 6:11 PM, "Xuxiaohu" <[email-masked]> wrote:

>IMHO, that "obvious" part is the only practical problem that needs to be
>solved. The transit LAN scenario is a fake one, which has been explained
>in a previous email.
>
>Best regards,
>Xiaohu
> 
>> Thanks,
>> Wei
>> 
>> 
>> 
>> 
>> 
>> 
>> >> If the WG think the upstream link failure scenario should be
>>discussed
>> >>in
>> >> >>> validity that the older draft contains some information being
>>used
>> >>in
>> >> >>> be merged but I may be wrong. Please share your opinions on this
>>so
>> >>we
>> >> >>> If the broader WG participants have an opinion on this please
>>speak
>> >>up.
>> >> >>>
>> >> >>> thanks,
>> >> >>> mike
>> >> >>>
>> >> >>> >    priority value to the VRRP priority value always. In this
>>way,
>> >>the
>> >> >>> >> Please read the draft (its short) and provide an opinion
>>either
>> >>way