Hi Chris,
thank you for your review. Will include the proposed update in the next version
of the draft.
On two approaches being presented in the draft. We'll work on the text to make
the situation more clear. And I can refer to RFC 4090 where two approaches to
RSVP FRR defined. And, as in the case with VRRP-BFD, it was result of merging
two drafts that presented technically viable though different solutions. And
that how I see two solutions presented in this draft - both are technically
sound, with their own pros and cons. But, of course, it would be for the RTGWG
and community of experts from other WGs, e.g. BFD, to decide.
Regards,
Greg
From: Chris Bowers [mailto:[email protected]]
Sent: Thursday, January 28, 2016 7:40 AM
To: Gregory Mirsky; Nitish Gupta (nitisgup); [email protected]; [email protected]
Cc: Jeff Haas; [email protected]; Aditya Dogra (addogra)
Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt
Greg,
Thanks. Those clarifications seem reasonable.
Draft authors,
I do have another general comment about the current text of the draft. The
current text discusses two different approaches to doing fast failure detection
in VRRP with BFD, using p2p BFD or p2mp BFD. The first uses existing BFD p2p
sessions and enhances VRRP to use the p2p BFD sessions. The second requires
less enhancement of VRRP, but relies on enhanced functionality in BFD. If
this is correct, it would be good for the text to explicitly state that these
are two distinct approaches, to help the readers during the poll for WG
adoption.
If this work is adopted by RTGWG, one could imagine a scenario where the
working group decides to document both approaches in the final version.
However, it is usually more desirable for the working group to evaluate the
different approaches and choose one. It would also be useful for the text to
explicitly state the authors' thoughts and intentions with respect to how the
document should evolve. Should it ultimately document one solution, should it
document multiple solutions, or should more work be done to determine if there
are compelling reasons to document multiple solutions? If adopted, it will
ultimately be up to the WG to decide how to move forward, regardless of the
stated intentions of the current authors. However, it would be useful for the
readers during the poll for WG adoption to understand the authors' current
intentions and their thinking on this topic.
Thanks,
Chris
From: Gregory Mirsky [mailto:[email protected]]
Sent: Wednesday, January 27, 2016 7:43 PM
To: Chris Bowers <[email protected]<mailto:[email protected]>>; Nitish
Gupta (nitisgup) <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
Cc: Jeff Haas <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; Aditya Dogra (addogra)
<[email protected]<mailto:[email protected]>>
Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt
Hi Chris,
greatly appreciate your thorough review and the most detailed comments. As
we've contributed p2mp BFD applicability to VRRP part of the draft I'll address
your comments, that I've copied below, to Section 4. Please find my notes
tagged GIM>>
4) I don't understand Section 4 which describes how to use p2mp BFD.
GIM>> Hope that will be clearer once I address your questions to the Section 4
below.
A) The text says that "The Master router starts transmitting BFD control
packets with VRID as source IP address." According to RFC5798, the VRID is an
integer in the range from 1-255. Is the idea to encode the integer VRID as an
IP address? Or should the BFD control packets be sent with the source IP
address set to an IPvX address associated with the virtual router? Or are both
used? In any case, it seems like this needs clarification.
GIM>> Very good catch. Indeed, the idea is to use IPvX address associated with
the particular VRID. Would the following change clarify selection of source IP
address:
The Master router starts transmitting BFD control packets with IPvX address
associated with the VRID as source IP address. Backup router demultiplexes p2mp
BFD test sessions based on IP source address associated with the virtual router
that it been configured with.
B) What is the destination IP address of the p2mp BFD control packet? Is it
224.0.0.18 or FF02:0:0:0:0:0:0:12, then IPv4 and IPv6 multicast addresses for
VRRP? If so, this should be made explicit.
GIM>> I think that VRRP multicast address MAY be used as destination IP address
for p2mp BFD which has VRRP as its client. I think that subnet broadcast
address SHOULD be used as destination IP address. I'll add the text to the
Section 4.
C) Again, a state machine description would help readers and future
implementers understand exactly what is intended.
GIM>> p2mp BFD, as I think, does not change VRRP state machine. I'll add
statement to that to the text for the next version.
-----Original Message-----
From: Chris Bowers [mailto:[email protected]]
Sent: Tuesday, January 19, 2016 11:54 AM
To: Nitish Gupta (nitisgup); [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Cc: Gregory Mirsky; Jeff Haas; [email protected]<mailto:[email protected]>;
Aditya Dogra (addogra)
Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt
Nitish and co-authors,
I have read this draft and have several comments below. In general, I prefer
that authors address outstanding comments in a new revision before we conduct a
poll for adoption in RTGWG. Since an adoption poll usually triggers quite a
few people read a draft in detail, it makes better use of the working groups
time to have them reading the most up-to-date version. However, an argument
could also be made for filling in some of the additional detail that I am
asking for below after WG adoption (assuming it is adopted), when the WG has
more direct control of the document. So I am open to either approach.
So please respond to the feedback below and tell me if you would like to
address some of it in a new revision before I conduct a poll for WG adoption,
or if you would prefer to do the WG adoption poll using the current revision.
There has also been feedback from others on this draft in response to your
email, so you should respond to that as well.
In general, I think the draft would benefit from specifying the VRRP state
machine for this BFD mode of operation at the same level of detail that RFC5798
specifies the existing VRRP state machine. There are several places where it
is probably possible to infer the correct behavior, but making it very explicit
will make for a better document.
1) Section 3.5 of this draft defines the Critical BFD session which is the BFD
session between the VRRP Master and the next best VRRP backup. In the existing
VRRP state machine, a VRRP router in the backup state is not able to determine
if it is the next best VRRP backup. Presumably, in the VRRP state machine for
the BFD mode of operation, a VRRP router in the backup state will look at the
peer table populated by the Backup Advertisements and figure out which router
is the next best VRRP router based on highest priority value with highest IPvX
address as tie breaker. However, it would be better to be as explicit as
RFC5798 about how this new state machine operates.
2) Section 5 says that "To reduce the number of packets generated at a regular
interval, Backup Advert packets may be sent at a reduced rate as compared to
Advert packets sent by the VRRP Master." It seems that the state machine for
VRRP BFD mode will have to be enhanced in some way to support this. One way
to do this would be for each router to have a Backup_Advertisement_Interval
which it uses to populate the Maximum Advertisement Interval in the BACKUP
ADVERTISEMENT, and have each receiving router maintain a
Peer_Advert_Interval(P) for each peer(P), and remove a peer entry when a BACKUP
ADVERTISEMENT is not received from P for 3* Peer_Advert_Interval(P). But this
is just one possible approach. In any case, it would be good to choose a
mechanism and describe the corresponding state machine.
3) The text should clarify how the VRRP state machine interacts with the BFD
state machine. One can imagine scenarios where a BFD session stays up but the
VRRP advertisements stop being received, or vice versa. This scenario is not
very far-fetched because BFD may use unicast and VRRP uses multicast. Behavior
can probably be inferred from existing text, but I think more precision is
better here.
4) I don't understand Section 4 which describes how to use p2mp BFD.
A) The text says that "The Master router starts transmitting BFD control
packets with VRID as source IP address." According to RFC5798, the VRID is an
integer in the range from 1-255. Is the idea to encode the integer VRID as an
IP address? Or should the BFD control packets be sent with the source IP
address set to an IPvX address associated with the virtual router? Or are both
used? In any case, it seems like this needs clarification.
B) What is the destination IP address of the p2mp BFD control packet? Is it
224.0.0.18 or FF02:0:0:0:0:0:0:12, then IPv4 and IPv6 multicast addresses for
VRRP? If so, this should be made explicit.
C) Again, a state machine description would help readers and future
implementers understand exactly what is intended.
Thanks,
Chris
-----Original Message-----
From: rtgwg [mailto:[email protected]] On Behalf Of Nitish Gupta (nitisgup)
Sent: Wednesday, January 13, 2016 3:31 AM
To: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Cc: Gregory Mirsky
<[email protected]<mailto:[email protected]>>; Jeff Haas
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; Aditya Dogra (addogra)
<[email protected]<mailto:[email protected]>>
Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt
Hi,
We had presented the Draft for VRRP BFD integration in IETF 93 and we had taken
care of all the comments that came as part of the WG meeting.
We had also merged the two drafts as per the comments in IETF 93:
http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01
https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00
We had presented the merged draft in IETF 94 and there were no specific
comments on the draft.
We would like to ask the RTGWG to adopt the Draft as a WG document.
Thanks,
Nitish
On 26/10/15 11:57 am, "Nitish Gupta (nitisgup)"
<[email protected]<mailto:[email protected]>> wrote:
>Hi,
>
>We have submitted a new version of the draft. As discussed in IETF 93
>at prague.
>
>We have merged the following drafts:
>http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01
>
>https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00
>
>
>
>We have also taken care of all the comments that were discussed in the
>RTGWG meeting.
>We welcome any comments and suggestions on the draft.
>
>Thanks,
>Nitish
>
>On 13/10/15 9:09 pm,
>"[email protected]<mailto:[email protected]>"
><[email protected]<mailto:[email protected]>>
>wrote:
>
>>
>>A new version of I-D, draft-nitish-vrrp-bfd-02.txt has been
>>successfully submitted by Nitish Gupta and posted to the IETF
>>repository.
>>
>>Name: draft-nitish-vrrp-bfd
>>Revision: 02
>>Title: Fast failure detection in VRRP with BFD
>>Document date: 2015-10-13
>>Group: Individual Submission
>>Pages: 10
>>URL:
>>https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt
>>Status: https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/
>>Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02
>>Diff:
>>https://www.ietf.org/rfcdiff?url2=draft-nitish-vrrp-bfd-02
>>
>>Abstract:
>> This document describes how Bidirectional Forwarding Detection (BFD)
>> can be used to support sub-second detection of a Master Router
>> failure in the Virtual Router Redundancy Protocol (VRRP).
>>
>>
>>
>>
>>
>>Please note that it may take a couple of minutes from the time of
>>submission until the htmlized version and diff are available at
>>tools.ietf.org.
>>
>>The IETF Secretariat
>>
>
_______________________________________________
rtgwg mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/rtgwg
