Re: [pim] call for adoption: draft-zhou-pim-vrrp-01

["Wei Zhou (weizho2)" <[e-mail]>]

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" <[e-mail]> wrote:

>Hi Wei,
>
>> -----邮件原件-----
>> 发件人: Wei Zhou (weizho2) [mailto:[e-mail]]
>> 发送时间: 2013年6月7日 1:23
>> 收件人: Xuxiaohu; Mike McBride; Prashant Jhingran (pjhingra)
>> 抄送: Rajiv Asati (rajiva); [e-mail]; Stig Venaas;
>> [e-mail]
>> 主题: Re: [pim] call for adoption: draft-zhou-pim-vrrp-01
>> 
>> 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.
>
>What are the other scenarios that the 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?
>
>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
>> 
>> 
>> 
>> 
>> 
>> 
>> On 6/4/13 8:19 PM, "Xuxiaohu" <[e-mail]> wrote:
>> 
>> >Hi Wei,
>> >
>> >> -----邮件原件-----
>> >> 发件人: Wei Zhou (weizho2) [mailto:[e-mail]]
>> >> 发送时间: 2013年6月1日 2:56
>> >> 收件人: Mike McBride; Prashant Jhingran (pjhingra)
>> >> 抄送: Rajiv Asati (rajiva); Xuxiaohu; [e-mail];
>>Stig
>> >> Venaas; [e-mail]
>> >> 主题: Re: [pim] call for adoption: draft-zhou-pim-vrrp-01
>> >>
>> >> 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" <[e-mail]> wrote:
>> >>
>> >> >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
>> >> >
>> >> >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)
>> >> ><[e-mail]> 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; [e-mail];
>> Prashant
>> >> >>Jhingran (pjhingra); Wei Zhou (weizho2)
>> >> >> Cc: Stig Venaas; [e-mail]
>> >> >> 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:[e-mail]]
>> >> >>> Sent: Wednesday, May 22, 2013 2:17 AM
>> >> >>> To: Xuxiaohu; [e-mail]; Rajiv Asati (rajiva);
>> >> >>> Prashant Jhingran (pjhingra); Wei Zhou (weizho2)
>> >> >>> Cc: Stig Venaas; Mike McBride; [e-mail]
>> >> >>> 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 <[e-mail]>
>> >> 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
>> >> >>> >
>> >> >>> >> -----邮件原件-----
>> >> >>> >> 发件人: [e-mail] [mailto:[e-mail]] 代表
>> >> >>> Mike
>> >> >>> >> McBride
>> >> >>> >> 发送时间: 2013年5月10日 3:48
>> >> >>> >> 收件人: [e-mail]
>> >> >>> >> 主题: [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
>> >> >>> >> [e-mail]
>> >> >>> >> https://www.ietf.org/mailman/listinfo/pim
>> >
>