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

From: Chris Bowers <[email-masked]>
Date: Wed, 10 Jan 2018 15:23:02 -0600

RTGWG,

This email starts the two week WG adoption poll for draft-nitish-vrrp-bfd-p2p.

https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd-p2p/

Please indicate whether you support or oppose having RTGWG work
on this topic with this draft as the starting point.

This WG adoption poll will end on Thursday, January 25th.

An IPR poll for this draft was conducted last month.

Thanks,
Chris

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 10 Jan 2018 13:39:27 -0800

Support as co-author

Regards,
Jeff

> On Jan 10, 2018, at 13:23, Chris Bowers <[email-masked]> wrote:
> 
> RTGWG,
> 
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: "Nitish Gupta (nitisgup)" <[email-masked]>
Date: Wed, 10 Jan 2018 21:41:35 +0000

As a Co-Author I support the adoption of the document.

Thanks,
Nitish

On 1/10/18, 1:39 PM, "rtgwg on behalf of Jeff Tantsura" <[email-masked] on behalf of [email-masked]> wrote:

    Support as co-author
    
    Regards,
    Jeff

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 11 Jan 2018 17:00:30 +0000

Hi all,

I have several questions regarding the draft that I would like to clarify before providing any firm opinion regarding its adoption.

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)

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”?

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?

b.       Is the “Critical Path” re-estimated each time this happens etc.

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?

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)

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).

Your timely feedback would be highly appreciated.

Regards, and lots of thanks in advance,

Sasha

Office: +972-39266302

Cell:      +972-549266302

Email:   [email-masked]

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Chris Bowers
Sent: Wednesday, January 10, 2018 11:23 PM
To: RTGWG <[email-masked]>; [email-masked]
Subject: WG adoption poll for draft-nitish-vrrp-bfd-p2p

RTGWG,

Please indicate whether you support or oppose having RTGWG work on this topic with this draft as the starting point.

Thanks,

Chris

___________________________________________________________________________

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.
___________________________________________________________________________

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 11 Jan 2018 09:01:55 -0800

Hi,
yes/support as co-author.

Regards,
Greg

---

From: "Nitish Gupta (nitisgup)" <[email-masked]>
Date: Mon, 15 Jan 2018 06:29:01 +0000

Hi Sasha,

We would like to Thank you for your questions and its good to see interest in the Draft. Will be Happy to answer the questions.
Please find our responses inline.

Thanks,
Nitish

From: Alexander Vainshtein <[email-masked]>
Date: Thursday, January 11, 2018 at 9:00 AM
To: "[email-masked]" <[email-masked]>
Cc: Chris Bowers <[email-masked]>, RTGWG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: WG adoption poll for draft-nitish-vrrp-bfd-p2p
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Thursday, January 11, 2018 at 9:00 AM

Hi all,

[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.

[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.

                        [nitisgup] When the VRRP Router Enters the Backup State it will send a BACKUP ADVERTISEMENT.

[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.

[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.

[nitisgup] We can take care of this in next version of the Draft.

[nitisgup] Same as above we will explicitly mention it.

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Chris Bowers
Sent: Wednesday, January 10, 2018 11:23 PM
To: RTGWG <[email-masked]>; [email-masked]
Subject: WG adoption poll for draft-nitish-vrrp-bfd-p2p

RTGWG,

Thanks,

Chris

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 16 Jan 2018 08:54:57 +0000 (UTC)

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.
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.  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. 
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.  
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 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
----- 
Regards,                                    Sasha Vainshteinemail:   [email-masked]: +972-52-8674833, +972-54-9266302  

    On Monday, January 15, 2018 8:29 AM, Nitish Gupta (nitisgup) <[email-masked]> wrote:

 #yiv5950416049 #yiv5950416049 -- _filtered #yiv5950416049 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv5950416049 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv5950416049 #yiv5950416049 p.yiv5950416049MsoNormal, #yiv5950416049 li.yiv5950416049MsoNormal, #yiv5950416049 div.yiv5950416049MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:11.0pt;font-family:Calibri;}#yiv5950416049 a:link, #yiv5950416049 span.yiv5950416049MsoHyperlink {color:#0563C1;text-decoration:underline;}#yiv5950416049 a:visited, #yiv5950416049 span.yiv5950416049MsoHyperlinkFollowed {color:#954F72;text-decoration:underline;}#yiv5950416049 p.yiv5950416049MsoPlainText, #yiv5950416049 li.yiv5950416049MsoPlainText, #yiv5950416049 div.yiv5950416049MsoPlainText {margin:0in;margin-bottom:.0001pt;font-size:11.0pt;font-family:Calibri;}#yiv5950416049 span.yiv5950416049PlainTextChar {font-family:Calibri;}#yiv5950416049 span.yiv5950416049EmailStyle19 {font-family:Calibri;color:windowtext;}#yiv5950416049 span.yiv5950416049msoIns {text-decoration:underline;color:teal;}#yiv5950416049 .yiv5950416049MsoChpDefault {font-size:10.0pt;} _filtered #yiv5950416049 {margin:1.0in 1.25in 1.0in 1.25in;}#yiv5950416049 div.yiv5950416049WordSection1 {}#yiv5950416049 _filtered #yiv5950416049 {} _filtered #yiv5950416049 {} _filtered #yiv5950416049 {} _filtered #yiv5950416049 {} _filtered #yiv5950416049 {} _filtered #yiv5950416049 {} _filtered #yiv5950416049 {} _filtered #yiv5950416049 {} _filtered #yiv5950416049 {} _filtered #yiv5950416049 {}#yiv5950416049 ol {margin-bottom:0in;}#yiv5950416049 ul {margin-bottom:0in;}#yiv5950416049 Hi Sasha,    We would like to Thank you for your questions and its good to see interest in the Draft. Will be Happy to answer the questions. Please find our responses inline.    Thanks, Nitish    From: Alexander Vainshtein <[email-masked]>
Date: Thursday, January 11, 2018 at 9:00 AM
To: "[email-masked]" <[email-masked]>
Cc: Chris Bowers <[email-masked]>, RTGWG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: WG adoption poll for draft-nitish-vrrp-bfd-p2p
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Thursday, January 11, 2018 at 9:00 AM    Hi all, I have several questions regarding the draft that I would like to clarify before providing any firm opinion regarding its adoption.   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. 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. 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.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. 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. 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.Your timely feedback would be highly appreciated.   Regards, and lots of thanks in advance, Sasha   Office: +972-39266302 Cell:      +972-549266302 Email:   [email-masked]   -----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Chris Bowers
Sent: Wednesday, January 10, 2018 11:23 PM
To: RTGWG <[email-masked]>; [email-masked]
Subject: WG adoption poll for draft-nitish-vrrp-bfd-p2p   RTGWG,   This email starts the two week WG adoption poll for draft-nitish-vrrp-bfd-p2p.   https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd-p2p/   Please indicate whether you support or oppose having RTGWG work on this topic with this draft as the starting point.   This WG adoption poll will end on Thursday, January 25th.   An IPR poll for this draft was conducted last month.   Thanks, Chris   
___________________________________________________________________________

---

From: Colin Docherty <[email-masked]>
Date: Tue, 16 Jan 2018 09:32:09 +0000

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
> 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.

> 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.
> [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/**:) happy

Agreed.

Regards,
Colin.

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 16 Jan 2018 10:03:33 +0000

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: +972-39266302
Cell:      +972-549266302

From: Colin Docherty [mailto:[email-masked]] On Behalf Of Colin Docherty
Sent: Tuesday, January 16, 2018 11:32 AM
To: Alexander Vainshtein <[email-masked]>; Nitish Gupta (nitisgup) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Aditya Dogra (addogra) <[email-masked]>; Alexander Vainshtein <[email-masked]>; [email-masked]
Subject: Re: WG adoption poll for draft-nitish-vrrp-bfd-p2p

Hi Alexander/Group,

Some replies,

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>

   BACKUP ADVERTISEMENT as defined by the Draft.
<end quote>

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.

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.

[Sasha] From my POV this should be explicitly stated in teh draft 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[Image removed by sender. *:) happy]

Agreed.

Regards,
Colin.

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 25 Jan 2018 11:44:38 +0000

Resending after reducing the size.
Chris and all,
I support adoption of this draft as a WG document.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Alexander Vainshtein
Sent: Thursday, January 25, 2018 11:53 AM
To: 'Nitish Gupta (nitisgup)' <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; Aditya Dogra (addogra) <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: WG adoption poll for draft-nitish-vrrp-bfd-p2p

Nitish,
Lots of thanks for the new version and your clarifications. It addresses my immediate concerns.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

---

From: "Nitish Gupta (nitisgup)" <[email-masked]>
Date: Thu, 25 Jan 2018 07:20:33 +0000

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 <[email-masked]>
Date: Tuesday, January 16, 2018 at 2:03 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Aditya Dogra (addogra)" <[email-masked]>, "[email-masked]" <[email-masked]>, "Nitish Gupta (nitisgup)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: WG adoption poll for draft-nitish-vrrp-bfd-p2p

Colin,

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi Alexander/Group,

Some replies,

Agreed.

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.

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 25 Jan 2018 09:52:57 +0000

Chris and all,

Nitish,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Nitish Gupta (nitisgup) [mailto:[email-masked]]
Sent: Thursday, January 25, 2018 9:21 AM
To: Alexander Vainshtein <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Aditya Dogra (addogra) <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: WG adoption poll for draft-nitish-vrrp-bfd-p2p

Hi Sasha,

Thanks,
Nitish

From: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, January 16, 2018 at 2:03 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Aditya Dogra (addogra)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Nitish Gupta (nitisgup)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: WG adoption poll for draft-nitish-vrrp-bfd-p2p

Colin,

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Colin Docherty [mailto:[email-masked]] On Behalf Of Colin Docherty
Sent: Tuesday, January 16, 2018 11:32 AM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Nitish Gupta (nitisgup) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Aditya Dogra (addogra) <[email-masked]<mailto:[email-masked]>>; Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: WG adoption poll for draft-nitish-vrrp-bfd-p2p

Hi Alexander/Group,

Some replies,

Agreed.

Agreed.

Agreed.

Regards,
Colin.

---

From: Chris Bowers <[email-masked]>
Date: Mon, 29 Jan 2018 14:30:24 -0600

There appears to be consensus for RTGWG to adopt this document.

Please post the latest version renamed to:

draft-ietf-rtgwg-vrrp-bfd-p2p

Thanks,
Chris