Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt

From: "Nitish Gupta (nitisgup)" <[email-masked]>
Date: Wed, 13 Jan 2016 09:31:29 +0000

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-masked]> 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-masked]" <[email-masked]>
>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
>>
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 17 Jan 2016 10:04:49 +0000

Hi all,
I have read the draft and I have one (presumably, minor) comment:
- The IANA Considerations section of says that there are no IANA request.
- At the same time the draft defines a new type of VRRP messages (2 - Backup Advertisement).

As long as here was just one type of VRRP messages (1 - Advertisement), we could avoid setting up a IANA registry for VRRP message types. If we are going to have two, does not this justify setting up such a registry?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Nitish Gupta (nitisgup)
Sent: Wednesday, January 13, 2016 11:31 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; Aditya Dogra (addogra)
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-masked]> wrote:

>Hi,
>
>We have submitted a new version of the draft. As discussed in IETF 93 
>at prague.
>
>>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.
>>
>>submission until the htmlized version and diff are available at 
>>tools.ietf.org.
>>
>>The IETF Secretariat
>>
>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sun, 17 Jan 2016 20:10:31 -0800

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-masked]> wrote:
> 
> Hi,
> 
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-nitish-vrrp-bfd-02
>> 
>> Abstract:

Mahesh Jethanandani
[email-masked]

---

From: Chris Bowers <[email-masked]>
Date: Mon, 18 Jan 2016 18:38:40 +0000

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 at https://datatracker.ietf.org/wg/rtgwg/documents/ at the bottom under the header of “Related Internet-Drafts”.

Thanks,
Chris

From: rtgwg [mailto:[email-masked]] On Behalf Of Mahesh Jethanandani
Sent: Sunday, January 17, 2016 10:11 PM
To: Nitish Gupta (nitisgup) <[email-masked]>
Cc: Jeff Haas <[email-masked]>; [email-masked]; Aditya Dogra (addogra) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt

On Oct 25, 2015, at 11:27 PM, Nitish Gupta (nitisgup) <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Thanks,
Nitish

On 13/10/15 9:09 pm, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
wrote:

Abstract:

The IETF Secretariat

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 18 Jan 2016 19:13:24 +0000

Chris, Mahesh,
I agree with this characterization of the draft and believe that, if adopted, it belongs in the RTG WG.
Thanks,
Acee

From: rtgwg <[email-masked]<mailto:[email-masked]>> on behalf of Chris Bowers <[email-masked]<mailto:[email-masked]>>
Date: Monday, January 18, 2016 at 1:38 PM
To: Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>, "Nitish Gupta (nitisgup)" <[email-masked]<mailto:[email-masked]>>
Cc: Jeff Haas <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Aditya Dogra (addogra)" <[email-masked]<mailto:[email-masked]>>, Routing WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt

Mahesh,

Thanks,
Chris

From: rtgwg [mailto:[email-masked]] On Behalf Of Mahesh Jethanandani
Sent: Sunday, January 17, 2016 10:11 PM
To: Nitish Gupta (nitisgup) <[email-masked]<mailto:[email-masked]>>
Cc: Jeff Haas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Aditya Dogra (addogra) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt

Hi,

Thanks,
Nitish

Abstract:

The IETF Secretariat

Mahesh Jethanandani

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 18 Jan 2016 22:13:49 -0800

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-masked]> wrote:
> 
> Mahesh,
>  
> 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-masked] <mailto:[email-masked]>] On Behalf Of Mahesh Jethanandani
> To: Nitish Gupta (nitisgup) <[email-masked] <mailto:[email-masked]>>
> Cc: Jeff Haas <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Aditya Dogra (addogra) <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> On Oct 25, 2015, at 11:27 PM, Nitish Gupta (nitisgup) <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi,
> 
> 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>
> 
> 
> 
> On 13/10/15 9:09 pm, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
> 
> 
> 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:
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
>  
>  
> Mahesh Jethanandani
> [email-masked] <mailto:[email-masked]>
Mahesh Jethanandani
[email-masked]

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 19 Jan 2016 09:39:05 -0500

[Wearing my BFD co-chair hat.]

On Mon, Jan 18, 2016 at 06:38:40PM +0000, Chris Bowers wrote:
> 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.

The general policy of the BFD Working Group has been that protocol changes
to BFD belong in the BFD working group.  Uses of BFD should be carried out
in the Working Group that carries the appropriate expertise, but BFD is
chartered to help with review of uses of BFD elsewhere.

Thus, rtgwg is a perfectly fine place for this draft.  If the rtgwg chairs
think it's appropriate, last call can occur also in BFD for additional
review.

-- Jeff

---

From: Chris Bowers <[email-masked]>
Date: Tue, 19 Jan 2016 19:53:49 +0000

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-masked]] On Behalf Of Nitish Gupta (nitisgup)
Sent: Wednesday, January 13, 2016 3:31 AM
To: [email-masked]; [email-masked]
Cc: Gregory Mirsky <[email-masked]>; Jeff Haas <[email-masked]>; [email-masked]; Aditya Dogra (addogra) <[email-masked]>
Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt

Hi,

Thanks,
Nitish

>>submission until the htmlized version and diff are available at 

_______________________________________________
rtgwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtgwg

---

From: "Nitish Gupta (nitisgup)" <[email-masked]>
Date: Wed, 20 Jan 2016 05:11:14 +0000

Hi Alexander,

Thanks for your comments. We would be adding the IANA considerations in
the next version of the draft for setting up a registry for VRRP Advert
types.

Thanks,
Nitish

On 17/01/16 3:34 pm, "Alexander Vainshtein"
<[email-masked]> wrote:

>As long as here was just one type of VRRP messages (1 - Advertisement),
>we could avoid setting up a IANA registry for VRRP message types. If we
>are going to have two, does not this justify setting up such a registry?
>
>Regards,
>Sasha
>
>Office: +972-39266302
>Cell:      +972-549266302

---

From: "Nitish Gupta (nitisgup)" <[email-masked]>
Date: Wed, 20 Jan 2016 05:32:48 +0000

Hi Mahesh,

Thanks for your comments please see inline.

Thanks,
Nitish

From: Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 19 January 2016 11:43 am
To: Chris Bowers <[email-masked]<mailto:[email-masked]>>
Cc: Nitish Gupta <[email-masked]<mailto:[email-masked]>>, Jeff Haas <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Aditya Dogra (addogra)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt

Chris,

[nitish] I just want to clarify one point that there will be only one session between a pair of VRRP router instance for example in this case if there is only one VRRP Master and one VRRP backup Router there will be only one BFD session.  Though both the devices would require to initiate BFD bootup sequence but there will be only one BFD session formed between them. As Section 3 of RFC 5881 (Bidirectional Forwarding Detection (BFD)
for IPv4 and IPv6 (Single Hop)
) mandates that the session be initiated by both the participating peers for a session to be formed between them. Hence the Backup router needs to know the Master IPVX address to initiate a BFD session.

[nitish] There is no particular requirement that we can see from BFD YANG model perspective. As VRRP should interface with BFD as another protocol using BFD as a means of fast failure detection of its peer.

Cheers.

On Jan 18, 2016, at 10:38 AM, Chris Bowers <[email-masked]<mailto:[email-masked]>> wrote:

Mahesh,

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/ at the bottom under the header of “Related Internet-Drafts”.

Thanks,
Chris

Hi,

Thanks,
Nitish

Abstract:

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

Mahesh Jethanandani

---

From: "Nitish Gupta (nitisgup)" <[email-masked]>
Date: Wed, 20 Jan 2016 07:06:17 +0000

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-masked]> 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.
>
>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
>
>Cc: Gregory Mirsky <[email-masked]>; Jeff Haas
><[email-masked]>; [email-masked]; Aditya Dogra (addogra)
><[email-masked]>

---

From: Jeff Haas <[email-masked]>
Date: Wed, 20 Jan 2016 10:10:29 -0500

> On Jan 20, 2016, at 12:32 AM, Nitish Gupta (nitisgup) <[email-masked]> wrote:
> 

The desired behavior we're looking for in yang is ideally making use of the groupings exported by the BFD yang module.  This permits a simple maintainable place to put BFD session parameters.

There are two issues Mahesh is alluding to:
1. Multipoint is currently not in the BFD yang spec.  Thus, the BFD yang team has homework to provide support for that option to allow modules such as a vrrp module supporting this feature to import it.
2. VRRP would only utilize this in *some* circumstances; namely the master/backup scenario rather than each backup.  Configuration state would likely be consistent, but ti does make the operational state a bit trickier.  The session is provisioned, but may not be started - and it may not even be *instantiated* depending on the implementation and whether the priority of the VRRP router is lower than the first available backup.

-- Jeff

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 21 Jan 2016 18:56:38 +0000

<Speaking as individual contributor>

BFD YANG spec doesn't currently support multipoint, what I recall is that the DT had agreed to wait for the multipoint draft to become RFC.

I assume the YANG model in draft-liu-rtgwg-yang-vrrp would need to be modified/augmented to support this capability?

Regards,
Reshad.

From: Rtg-bfd <[email-masked]<mailto:[email-masked]>> on behalf of Jeff Haas <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, January 20, 2016 at 10:10 AM
To: "Nitish Gupta (nitisgup)" <[email-masked]<mailto:[email-masked]>>
Cc: "Aditya Dogra (addogra)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt

On Jan 20, 2016, at 12:32 AM, Nitish Gupta (nitisgup) <[email-masked]<mailto:[email-masked]>> wrote:

-- Jeff

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 28 Jan 2016 01:42:39 +0000

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>>

GIM>>  Hope that will be clearer once I address your questions to the Section 4 below.

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.

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.

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-masked]]
Sent: Tuesday, January 19, 2016 11:54 AM
To: Nitish Gupta (nitisgup); [email-masked]; [email-masked]
Cc: Gregory Mirsky; Jeff Haas; [email-masked]; Aditya Dogra (addogra)
Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt

Nitish and co-authors,

Thanks,

Chris

-----Original Message-----

To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Cc: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>; Jeff Haas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Aditya Dogra (addogra) <[email-masked]<mailto:[email-masked]>>

Hi,

Thanks,

Nitish

>On 13/10/15 9:09 pm, "[email-masked]<mailto:[email-masked]>"

><[email-masked]<mailto:[email-masked]>>

rtgwg mailing list

[email-masked]<mailto:[email-masked]>

---

From: Chris Bowers <[email-masked]>
Date: Thu, 28 Jan 2016 15:40:17 +0000

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-masked]]
Sent: Wednesday, January 27, 2016 7:43 PM
To: Chris Bowers <[email-masked]>; Nitish Gupta (nitisgup) <[email-masked]>; [email-masked]; [email-masked]
Cc: Jeff Haas <[email-masked]>; [email-masked]; Aditya Dogra (addogra) <[email-masked]>
Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt

Hi Chris,

-----Original Message-----
From: Chris Bowers [mailto:[email-masked]]
Sent: Tuesday, January 19, 2016 11:54 AM
To: Nitish Gupta (nitisgup); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Gregory Mirsky; Jeff Haas; [email-masked]<mailto:[email-masked]>; Aditya Dogra (addogra)
Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt

Nitish and co-authors,

Thanks,

Chris

-----Original Message-----

Hi,

Thanks,

Nitish

rtgwg mailing list

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 28 Jan 2016 20:13:48 +0000

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-masked]]
Sent: Thursday, January 28, 2016 7:40 AM
To: Gregory Mirsky; Nitish Gupta (nitisgup); [email-masked]; [email-masked]
Cc: Jeff Haas; [email-masked]; Aditya Dogra (addogra)
Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt

Greg,

Draft authors,

Thanks,
Chris

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Wednesday, January 27, 2016 7:43 PM
To: Chris Bowers <[email-masked]<mailto:[email-masked]>>; Nitish Gupta (nitisgup) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Jeff Haas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Aditya Dogra (addogra) <[email-masked]<mailto:[email-masked]>>
Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt

Hi Chris,

-----Original Message-----
From: Chris Bowers [mailto:[email-masked]]
Sent: Tuesday, January 19, 2016 11:54 AM
To: Nitish Gupta (nitisgup); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Gregory Mirsky; Jeff Haas; [email-masked]<mailto:[email-masked]>; Aditya Dogra (addogra)
Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt

Nitish and co-authors,

Thanks,

Chris

-----Original Message-----

Hi,

Thanks,

Nitish

rtgwg mailing list