Re: WG adoption poll for draft-nitish-vrrp-bfd-p2p

[Loa Andersson <[e-mail]>]

Folks,

Yes, it is a good idea to adopt this document.

When it is adopted, can we post the new version as
draft-ietf-rtgwg-bfd-vrrp-p2p (or some such).

I know that this is just for convenience, but we are a lot of people
that have scripts looking for the wg-name in the third position.

/Loa

On 2018-01-25 17:52, Alexander Vainshtein wrote:
> Chris and all,
> 
> I support adoption of this draft as a WG document.
> 
> Nitish,
> 
> Lots of thanks for the new version and your clarifications. It addresses 
> my immediate concerns.
> 
> Regards,
> 
> Sasha
> 
> Office: [phone]
> 
> Cell:      [phone]
> 
> Email:   [e-mail]
> 
> *From:*Nitish Gupta (nitisgup) [mailto:[e-mail]]
> *Sent:* Thursday, January 25, 2018 9:21 AM
> *To:* Alexander Vainshtein <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; [e-mail]; 
> Aditya Dogra (addogra) <[e-mail]>; 
> [e-mail]; [e-mail]
> *Subject:* RE: WG adoption poll for draft-nitish-vrrp-bfd-p2p
> 
> Hi Sasha,
> 
> Thanks again for your comments and suggestions.
> 
> As requested we have added a section indicating that the workings of 
> this draft can be extended to VRRPv2 as well. We have updated a new 
> version of the draft as well.
> 
> Also for the below point:
> 
> “I also think that lack of clarity regarding re-evaluation of the 
> Critical Path BFD session is both problematic and pretty trivial to 
> resolve before adoption (at least, we seem to agree that such 
> clarification is necessary).”
> 
> [nitisgup] I believe that we have already pointed this out earlier and I 
> would like to reiterate my point, we have already explained the VRRP 
> state machine and the changes required in the state machine for VRRP to 
> interface with BFD. For instance, what you are asking us to put is 
> already there:
> 
> *   (1015) - If a BACKUP ADVERTISEMENT is received, then:*
> 
>        (1020) + If the Priority in the BACKUP ADVERTISEMENT is
> 
>                 zero, then:
> 
>           (1025) * Remove the Peer from peer table.
> 
>        (1030) + else: // priority non-zero
> 
> *         (1035) * Update the Peer info in peer table.*
> 
>           (1040) * Recompute the Backup_Down_Interval
> 
>           (1045) * Reset the Backup_Down_Timer to
> 
>                    Backup_Down_Interval
> 
>        (1050) + endif // priority in backup advert zero
> 
> *      (1055) + Calculate the Critical_Backup*
> 
> Thanks,
> 
> Nitish
> 
> *From: *Alexander Vainshtein <[e-mail] 
> <mailto:[e-mail]>>
> *Date: *Tuesday, January 16, 2018 at 2:03 AM
> *To: *"[e-mail] <mailto:[e-mail]>" <[e-mail] 
> <mailto:[e-mail]>>
> *Cc: *"[e-mail] <mailto:[e-mail]>" 
> <[e-mail] <mailto:[e-mail]>>, 
> "[e-mail] <mailto:[e-mail]>" <[e-mail] 
> <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" 
> <[e-mail] <mailto:[e-mail]>>, "Aditya Dogra (addogra)" 
> <[e-mail] <mailto:[e-mail]>>, 
> "[e-mail] 
> <mailto:[e-mail]>" 
> <[e-mail] 
> <mailto:[e-mail]>>, "Nitish Gupta (nitisgup)" 
> <[e-mail] <mailto:[e-mail]>>, "[e-mail] 
> <mailto:[e-mail]>" <[e-mail] 
> <mailto:[e-mail]>>
> *Subject: *RE: WG adoption poll for draft-nitish-vrrp-bfd-p2p
> 
> Colin,
> 
> I do not see that VRRPv2 is really abandoned in IPv4 deployments that I 
> see (of course, my exposure is limited).
> 
> I also do not see that VRRPv3 has really added much to VRRPv2 for IPv4.
> 
> I also have not seen any vendors announcing end of life/end of support 
> of VRRPv2 in their implementations. Or did I miss something?
> 
> The bottom line: We can “agree to disagree” about this point, and see 
> what other WG members have to say on this issue.
> 
> I also think that lack of clarity regarding re-evaluation of the 
> Critical Path BFD session is both problematic and pretty trivial to 
> resolve before adoption (at least, we seem to agree that such 
> clarification is necessary).
> 
> My 2c,
> 
> Sasha
> 
> Office: [phone]
> 
> Cell:      [phone]
> 
> Email: [e-mail] 
> <mailto:[e-mail]>
> 
> *From:*Colin Docherty [mailto:[e-mail]] *On Behalf Of 
> *Colin Docherty
> *Sent:* Tuesday, January 16, 2018 11:32 AM
> *To:* Alexander Vainshtein <[e-mail] <mailto:[e-mail]>>; 
> Nitish Gupta (nitisgup) <[e-mail] <mailto:[e-mail]>>
> *Cc:* [e-mail] <mailto:[e-mail]>; 
> [e-mail] <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; Aditya Dogra (addogra) <[e-mail] 
> <mailto:[e-mail]>>; Alexander Vainshtein 
> <[e-mail] 
> <mailto:[e-mail]>>; 
> [e-mail] 
> <mailto:[e-mail]>
> *Subject:* Re: WG adoption poll for draft-nitish-vrrp-bfd-p2p
> 
> Hi Alexander/Group,
> 
> Some replies,
> 
> On 16/01/18 08:54, Alexander Vainshtein wrote:
> 
>     Nitish and all,
> 
>     Lots of thanks for a prompt and detailed response.
> 
>     Based on your response I think that some changes to the draft should
>     be made prior to its adoption by the WG. Some other changes can be
>     safely handled once the draft becomes a WG document. The details can
>     be found in */my comments to your responses/*.
> 
>     I would also like to discuss one more issue that I did not mention
>     in my original set of comments.
> 
>     The last statement in Section 5 says:
> 
>     <quote>
> 
>         This Draft does not preclude the possibility of the peer table being
> 
>         populated by means of manual configuration, instead of using the
> 
>         BACKUP ADVERTISEMENT as defined by the Draft.
> 
>     <end quote>
> 
>     I wonder if this statement is sufficient of and by itself for the
>     implementers of such an option.
> 
>     If the peer table is populated by  manual configuration, and if,
>     say, object tracking is used to modify priorities of different
>     members of the VRRP group, priority-based selection of the CRITICAL
>     PATH member becomes more or less meaningless (because priorities
>     become dynamic). As a consequence, all BACKUP members of the group
>     would have to monitor their BFD sessions with teh Master and would
>     treat failure of these sessions as the Master Down event. Once this
>     happens, they would all sent VRRP Advertisement messages and resolve
>     the mastership in teh usual VRRP way. I do not see any serious
>     issues with this approach but it is different from the approach
>     defined in the draft. I wonder if clarification of this behavior
>     should not be added to the draft. In any case, this is not a stopper
>     for adopting the draft as a WG document.
> 
> 
> If we leave the statement as is then it is open to further expansion in 
> the future, however I think it would be good to just to focus on the 
> core functionality, and I don't think its a stopper at this stage.
> 
> 
> 
> 
>     Hopefully my comments will help.
> 
>     Here begin my comments to your responses:
> 
>     -----
> 
>     1.       The draft seems to deal just with VRRPv3 (RFC 5798) while
>     completely ignoring VRRPv2 (RFC 3768). I wonder if this omission is
>     due to some technical issue; if not, do the authors plan to extend
>     the draft to cover also VRRPv2 in future? (The context for this
>     question is that, AFAIK, VRRPv2 is more widely deployed for IPv4)
> 
>     [nitisgup] Since VRRPv3 covers First Hop redundancy for both ipv4
>     and ipv6, We have taken VRRPv3 as the base for this RFC and the same
>     can be extended to VRRPv2. We can cover that in future version of
>     the draft.
> 
>     */[Sasha] Taking into account that VRRPv2 is much more widely used
>     with IPv4 than VRRPv3, I think that at least a declaration of
>     intention to include also VRRPv2 should be done before the draft is
>     adopted. /*
> 
> 
> I strongly disagree with this. Around 2013 when I was developing the 
> initial BFD/VRRPv3 design, VRRPv2 was been actively deprecated with our 
> team for our new VRRPv3 implementation. VRRPv2 at that point had already 
> been deprecated since 2010. I really think it is time to move forward, 
> there is nothing in the VRRPv2 specification that isn't improved on in 
> VRRPv3. If anything this draft should serve as an incentive for 
> widespread adoption of VRRPv3 over its deprecated predecessor. Most 
> implementations have relatively straightforward upgrade paths for the 
> VRRPv2->VRRPv3 transition.
> 
> 
> 
> 
>     2.       Neither RFC 3768 nor RFC 5798 do not mention a “Master Down
>     event”; rather they speak about “expiration of the
>     Master_Down_Timer”. However, the draft uses the term “Master Down
>     event” several times. Can I safely assume that it is the same as
>     “expiration of the Master_Down_Timer”?
> 
>     [nitisgup] We have already covered in the Draft, that Master down
>     event is triggered by either “expiration of the Master_Down_Timer”
>     or “Critical_BFD_Session going down”. But We will also define it in
>     the section 3.6 of the Draft.
> 
>     */[Sasha] OK with me, can be done after adoption. /*
> 
> 
> Agreed.
> 
> 
> 
> 
>     3.       While neither RFC 3768 nor RFC 5798 mention it, most VRRP
>     implementations support tracking mechanisms that result in dynamic
>     change of priorities of VRRP group members. The draft does not
>     discuss what happens when priority of one of the group members
>     changes. E.g.:
> 
>     a.       Do the backup member that experiences such a change
>     immediately send a new Backup Advertisement?
> 
>                              [nitisgup] When the VRRP Router Enters the
>     Backup State it will send a BACKUP ADVERTISEMENT.
> 
>     b.       Is the “Critical Path” re-estimated each time this happens etc.
> 
>     [nitisgup] Ciritical Path is determined every time an
>     Advert(MASTER/BACKUP) is received from the PEER, as it will be
>     updated in the PEER table.
> 
>     */[Sasha] From my POV this should be explicitly stated in teh draft
>     before adoption. /*
> 
> I don't think this needs to be explicitly stated before adoption.
> 
> 
> 
> 
>     4.       Both VRRPv2 and VRRPv3 support no-preemption mode. Please
>     explain what happens if this mode is set in a VRRP group member
>     whose priority becomes (due to dynamic changes) higher than that of
>     the current Master?
> 
>     [nitisgup] We have not changed the Behavior of VRRPv3 with this
>     Draft the, We have already captured the updated State machine in
>     section 3.6.3, which takes care of Preempt_Mode of the VRRP router.
> 
>     */[Sasha] My point was that, with preemption mode enabled, some of
>     the BACKUP members could have higher priority of the current Master.
>     Clarifying that this does not affect determination of the CRITICAL
>     BFD session would be useful  - could be done after teh draft is
>     adopted. /*
> 
>     5.       Suppose that the draft is used with VRRPv3 for IPv6. Is the
>     Source IPv6 address of the Backup Advertisement packet a link-local
>     address of the interface via which this message is transmitted?
>     (This is explicitly specified in RFC 5798 for the VRRP Advertisement
>     message, but not specified in the draft)
> 
>     [nitisgup] We can take care of this in next version of the Draft.
>     */[Sasha] OK - could be done after adoption /*
> 
> 
> Agreed.
> 
> 
> 
> 
>     6.       In the scenario above, will the 1-hop IPv6 BFD session use
>     link-local IPv6 addresses of the VRRP Master and its primary Backup?
>     (I assume that the answer is positive, but it would be nice to see
>     this in the draft and not to leave it for the implementers to guess).
> 
>     [nitisgup] Same as above we will explicitly mention it. */[Sasha]
>     Sams as above for me too/*mage removed by sender. *:) happy
> 
> 
> Agreed.
> 
> 
> 
> 
> Regards,
> Colin.
> 
> 
> ___________________________________________________________________________
> 
> This e-mail message is intended for the recipient only and contains 
> information which is
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have 
> received this
> transmission in error, please inform us by e-mail, phone or fax, and 
> then delete the original
> and all copies thereof.
> ___________________________________________________________________________
> 
> 
> 
> ___________________________________________________________________________
> 
> This e-mail message is intended for the recipient only and contains 
> information which is
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have 
> received this
> transmission in error, please inform us by e-mail, phone or fax, and 
> then delete the original
> and all copies thereof.
> ___________________________________________________________________________
> 
> 
> _______________________________________________
> rtgwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtgwg
> 

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert
Huawei Technologies (consultant)     phone: [phone]