Hi Chris, Thanks for your comments. We would like to take care of the comments you have given before we ask the WG for adoption.
Thanks, Nitish On 20/01/16 1:23 am, "Chris Bowers" <[email protected]> wrote: >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]; [email protected] >Cc: Gregory Mirsky <[email protected]>; Jeff Haas ><[email protected]>; [email protected]; Aditya Dogra (addogra) ><[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]> >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]" >><[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] >https://www.ietf.org/mailman/listinfo/rtgwg
