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:rtgwg-boun...@ietf.org] On Behalf Of Nitish Gupta (nitisgup) Sent: Wednesday, January 13, 2016 3:31 AM To: rt...@ietf.org; rtg-bfd@ietf.org Cc: Gregory Mirsky <gregory.mir...@ericsson.com>; Jeff Haas <jh...@juniper.net>; co...@doch.org.uk; Aditya Dogra (addogra) <addo...@cisco.com> 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)" <nitis...@cisco.com> 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, "internet-dra...@ietf.org" ><internet-dra...@ietf.org> >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 rt...@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
