Chris,

Thanks for the clarification. Please cross-post the draft to rtg-bfd (as you 
have been doing) to make sure you get the BFD experts to review the draft.

One clarification and then a question in section 3 of the document. You say 
that BFD requires that a session be formed by both peers. You can very well 
form a one way session from the VRRP Master router to your Backup router. When 
the Backup Router detects loss of 3 BFD packets, it can declare the Master as 
Down and take over as the new Master router. The question is why do you need a 
BFD session from the Backup router to the Master router?

The other thing I want to make sure if there is any particular configuration 
requirement from a BFD YANG model perspective. I understand that you are using 
the fast timer in BFD to detect next-hop IP address liveliness check. We 
address that configuration in the BFD YANG model today. However, we have not 
addressed the issue of p2mp BFD configuration as yet. Depending on how that 
discussion proceeds we might want to look at that also.

Cheers.

> On Jan 18, 2016, at 10:38 AM, Chris Bowers <[email protected]> wrote:
> 
> Mahesh,
>  
> As I understand it, the authors eventually want this draft to be adopted by 
> the RTGWG.  This makes sense because it includes VRRP protocol extensions, so 
> it would normally go to the VRRP WG.   Since the VRRP WG is concluded, the 
> RTGWG is a reasonable place to do this work.
>  
> One might also consider doing this work in the BFD WG to take advantage of 
> the concentration of BFD expertise there.  However, since the main content of 
> the document deals with VRRP behavior and defining a new VRRP packet type, it 
> seems like it might be a diversion from the main work of the BFD WG.
>  
> If the RTGWG does adopt the draft, the name of the adopted draft should start 
> with draft-ietf-rtgwg (as you point out, following RFC7221). 
>  
> As an individual submission at this point, there are no hard requirements on 
> the name of the draft, except that it not start with draft-ietf.  However, 
> when authors are submitting drafts that they intend to eventually be 
> considered for adoption by the RTGWG, it is quite useful to name them 
> draft-authorname-rtgwg-yyyy, so that they automatically show up 
> athttps://datatracker.ietf.org/wg/rtgwg/documents/ 
> <https://datatracker.ietf.org/wg/rtgwg/documents/> at the bottom under the 
> header of “Related Internet-Drafts”. 
>  
> Thanks,
> Chris
>  
> From: rtgwg [mailto:[email protected] <mailto:[email protected]>] 
> On Behalf Of Mahesh Jethanandani
> Sent: Sunday, January 17, 2016 10:11 PM
> To: Nitish Gupta (nitisgup) <[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]>>; [email protected] 
> <mailto:[email protected]>; [email protected] <mailto:[email protected]>
> Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt
>  
> Shouldn’t the draft be named draft-nitish-bfd-vrrp or something like that to 
> follow the naming convention described in RFC 7221?
>  
> On Oct 25, 2015, at 11:27 PM, 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 
> <http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01>
> 
> https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 
> <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 
> <https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt>
> Status:         https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ 
> <https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/>
> Htmlized:       https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02 
> <https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02>
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-nitish-vrrp-bfd-02 
> <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 
> <http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
>  
>  
> Mahesh Jethanandani
> [email protected] <mailto:[email protected]>
Mahesh Jethanandani
[email protected]





Reply via email to