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 protected]: +972-52-8674833, +972-54-9266302
On Monday, January 15, 2018 8:29 AM, Nitish Gupta (nitisgup)
<[email protected]> 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 protected]>
Date: Thursday, January 11, 2018 at 9:00 AM
To: "[email protected]" <[email protected]>
Cc: Chris Bowers <[email protected]>, RTGWG <[email protected]>,
"[email protected]" <[email protected]>, "[email protected]"
<[email protected]>
Subject: RE: WG adoption poll for draft-nitish-vrrp-bfd-p2p
Resent-From: <[email protected]>
Resent-To: <[email protected]>, <[email protected]>, <[email protected]>,
<[email protected]>, <[email protected]>
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 protected] -----Original Message-----
From: Rtg-bfd [mailto:[email protected]] On Behalf Of Chris Bowers
Sent: Wednesday, January 10, 2018 11:23 PM
To: RTGWG <[email protected]>; [email protected]
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
___________________________________________________________________________
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.
___________________________________________________________________________
