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: +972-39266302
Cell: +972-549266302
Email: [email protected]
*From:*Nitish Gupta (nitisgup) [mailto:[email protected]]
*Sent:* Thursday, January 25, 2018 9:21 AM
*To:* Alexander Vainshtein <[email protected]>
*Cc:* [email protected]; [email protected]; [email protected];
Aditya Dogra (addogra) <[email protected]>;
[email protected]; [email protected]
*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 <[email protected]
<mailto:[email protected]>>
*Date: *Tuesday, January 16, 2018 at 2:03 AM
*To: *"[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>
*Cc: *"[email protected] <mailto:[email protected]>"
<[email protected] <mailto:[email protected]>>,
"[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>, "[email protected] <mailto:[email protected]>"
<[email protected] <mailto:[email protected]>>, "Aditya Dogra (addogra)"
<[email protected] <mailto:[email protected]>>,
"[email protected]
<mailto:[email protected]>"
<[email protected]
<mailto:[email protected]>>, "Nitish Gupta (nitisgup)"
<[email protected] <mailto:[email protected]>>, "[email protected]
<mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>
*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: +972-39266302
Cell: +972-549266302
Email: [email protected]
<mailto:[email protected]>
*From:*Colin Docherty [mailto:[email protected]] *On Behalf Of
*Colin Docherty
*Sent:* Tuesday, January 16, 2018 11:32 AM
*To:* Alexander Vainshtein <[email protected] <mailto:[email protected]>>;
Nitish Gupta (nitisgup) <[email protected] <mailto:[email protected]>>
*Cc:* [email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>; [email protected]
<mailto:[email protected]>; Aditya Dogra (addogra) <[email protected]
<mailto:[email protected]>>; Alexander Vainshtein
<[email protected]
<mailto:[email protected]>>;
[email protected]
<mailto:[email protected]>
*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
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
