Hi Chris,

We have taken care of all the comments that WG had given on this draft and
the below version of the draft has all the updates:

URL: https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-04.txt
Status:         https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/
Htmlized:       https://tools.ietf.org/html/draft-nitish-vrrp-bfd-04
Diff:           https://www.ietf.org/rfcdiff?url2=draft-nitish-vrrp-bfd-04

Major updates that we have done in this version:
1. Added few Variables for VRRP Protocol for P2P mode of operation.

2. Included State Machine for VRRP in the case of P2P BFD mode of
   Which outlines the details of how to form the Peer table and when to
start and stop the BFD sessions.

3. We have also updated the p2mp Section with the comments that you had
given, for the source ip to use in the P2mp BFD packets.
   We have also mentioned the state machine of VRRP in the mode of
operation, Just to outline the interactions VRRP will have with Multipoint
   This is for making it explicit in the state machine.
   Although there is no update to the Protocol state machine in this case,
we have mentioned this in the document.

4. IANA considerations updated in the document to allocate the namespace
for VRRP Packet types.

If there are no further comments on the draft we would like to ask the WG
for Adoption. Looking forward to hearing from you.



On 20/01/16, 12:36 PM, "Nitish Gupta (nitisgup)" <nitis...@cisco.com>

>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.
>On 20/01/16 1:23 am, "Chris Bowers" <cbow...@juniper.net> 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
>>B) What is the destination IP address of the p2mp BFD control packet?  Is
>>it 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.
>>-----Original Message-----
>>From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Nitish Gupta
>>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)
>>Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt
>>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:
>>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.
>>On 26/10/15 11:57 am, "Nitish Gupta (nitisgup)" <nitis...@cisco.com>
>>>We have submitted a new version of the draft. As discussed in IETF 93
>>>at prague.
>>>We have merged the following drafts:
>>>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.
>>>On 13/10/15 9:09 pm, "internet-dra...@ietf.org"
>>>>A new version of I-D, draft-nitish-vrrp-bfd-02.txt has been
>>>>successfully submitted by Nitish Gupta and posted to the IETF
>>>>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
>>>>Status:         https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/
>>>>Htmlized:       https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02
>>>>   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
>>>>The IETF Secretariat
>>rtgwg mailing list

Reply via email to