Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt
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: rtgwg@ietf.org; rtg-...@ietf.org >>Cc: Gregory Mirsky ; Jeff Haas >>; co...@doch.org.uk; 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)" >>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" >>> >>>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 >>rtgwg@ietf.org >>https://www.ietf.org/mailman/listinfo/rtgwg > ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt
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:cbow...@juniper.net] Sent: Thursday, January 28, 2016 7:40 AM To: Gregory Mirsky; Nitish Gupta (nitisgup); rtgwg@ietf.org; rtg-...@ietf.org Cc: Jeff Haas; co...@doch.org.uk; Aditya Dogra (addogra) Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt 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:gregory.mir...@ericsson.com] Sent: Wednesday, January 27, 2016 7:43 PM To: Chris Bowers mailto:cbow...@juniper.net>>; Nitish Gupta (nitisgup) mailto:nitis...@cisco.com>>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>; rtg-...@ietf.org<mailto:rtg-...@ietf.org> Cc: Jeff Haas mailto:jh...@juniper.net>>; co...@doch.org.uk<mailto:co...@doch.org.uk>; Aditya Dogra (addogra) mailto:addo...@cisco.com>> Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt 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>> 4) I don't understand Section 4 which describes how to use p2mp BFD. GIM>> Hope that will be clearer once I address your questions to the Section 4 below. 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. 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. 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. 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. C) Again, a state machine description would help readers and future impleme
RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt
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:gregory.mir...@ericsson.com] Sent: Wednesday, January 27, 2016 7:43 PM To: Chris Bowers ; Nitish Gupta (nitisgup) ; rtgwg@ietf.org; rtg-...@ietf.org Cc: Jeff Haas ; co...@doch.org.uk; Aditya Dogra (addogra) Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt 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>> 4) I don't understand Section 4 which describes how to use p2mp BFD. GIM>> Hope that will be clearer once I address your questions to the Section 4 below. 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. 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. 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. 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. C) Again, a state machine description would help readers and future implementers understand exactly what is intended. 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:cbow...@juniper.net] Sent: Tuesday, January 19, 2016 11:54 AM To: Nitish Gupta (nitisgup); rtgwg@ietf.org<mailto:rtgwg@ietf.org>; rtg-...@ietf.org<mailto:rtg-...@ietf.org> Cc: Gregory Mirsky; Jeff Haas; co...@doch.org.uk<mailto:co...@doch.org.uk>; Aditya Dogra (addogra) Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt 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 eit
RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt
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>> 4) I don't understand Section 4 which describes how to use p2mp BFD. GIM>> Hope that will be clearer once I address your questions to the Section 4 below. 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. 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. 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. 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. C) Again, a state machine description would help readers and future implementers understand exactly what is intended. 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:cbow...@juniper.net] Sent: Tuesday, January 19, 2016 11:54 AM To: Nitish Gupta (nitisgup); rtgwg@ietf.org; rtg-...@ietf.org Cc: Gregory Mirsky; Jeff Haas; co...@doch.org.uk; Aditya Dogra (addogra) Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt 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
Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt
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 mailto:rtg-bfd-boun...@ietf.org>> on behalf of Jeff Haas mailto:jh...@juniper.net>> Date: Wednesday, January 20, 2016 at 10:10 AM To: "Nitish Gupta (nitisgup)" mailto:nitis...@cisco.com>> Cc: "Aditya Dogra (addogra)" mailto:addo...@cisco.com>>, "co...@doch.org.uk<mailto:co...@doch.org.uk>" mailto:co...@doch.org.uk>>, "rtg-...@ietf.org<mailto:rtg-...@ietf.org>" mailto:rtg-...@ietf.org>>, "rtgwg@ietf.org<mailto:rtgwg@ietf.org>" mailto:rtgwg@ietf.org>> Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt On Jan 20, 2016, at 12:32 AM, Nitish Gupta (nitisgup) mailto:nitis...@cisco.com>> wrote: 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. [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. 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 ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt
> On Jan 20, 2016, at 12:32 AM, Nitish Gupta (nitisgup) > wrote: > > 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. > > [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. 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 ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt
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" 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:rtgwg-boun...@ietf.org] On Behalf Of Nitish Gupta >(nitisgup) >Sent: Wednesday, January 13, 2016 3:31 AM >To: rtgwg@ietf.org; rtg-...@ietf.org >Cc: Gregory Mirsky ; Jeff Haas >; co...@doch.org.uk; Aditya Dogra (addogra) > >Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt > >Hi, > &g
Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt
Hi Mahesh, Thanks for your comments please see inline. Thanks, Nitish From: Mahesh Jethanandani mailto:mjethanand...@gmail.com>> Date: Tuesday, 19 January 2016 11:43 am To: Chris Bowers mailto:cbow...@juniper.net>> Cc: Nitish Gupta mailto:nitis...@cisco.com>>, Jeff Haas mailto:jh...@juniper.net>>, "rtg-...@ietf.org<mailto:rtg-...@ietf.org>" mailto:rtg-...@ietf.org>>, "Aditya Dogra (addogra)" mailto:addo...@cisco.com>>, "co...@doch.org.uk<mailto:co...@doch.org.uk>" mailto:co...@doch.org.uk>>, "rtgwg@ietf.org<mailto:rtgwg@ietf.org>" mailto:rtgwg@ietf.org>> Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt 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? [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. 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. [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 mailto:cbow...@juniper.net>> 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-, 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 From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Mahesh Jethanandani Sent: Sunday, January 17, 2016 10:11 PM To: Nitish Gupta (nitisgup) mailto:nitis...@cisco.com>> Cc: Jeff Haas mailto:jh...@juniper.net>>; rtg-...@ietf.org<mailto:rtg-...@ietf.org>; Aditya Dogra (addogra) mailto:addo...@cisco.com>>; co...@doch.org.uk<mailto:co...@doch.org.uk>; rtgwg@ietf.org<mailto:rtgwg@ietf.org> 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) mailto: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 ha
Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt
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" wrote: >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: alexander.vainsht...@ecitele.com > >-Original Message- >From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of Nitish Gupta >(nitisgup) >Sent: Wednesday, January 13, 2016 11:31 AM >To: rtgwg@ietf.org; rtg-...@ietf.org >Cc: jh...@juniper.net; co...@doch.org.uk; 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)" >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" >> >>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 rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt
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: rtgwg@ietf.org; rtg-...@ietf.org Cc: Gregory Mirsky ; Jeff Haas ; co...@doch.org.uk; 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. Tha
Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt
[Wearing my BFD co-chair hat.] On Mon, Jan 18, 2016 at 06:38:40PM +, 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 ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt
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 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-, 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:rtgwg-boun...@ietf.org <mailto:rtgwg-boun...@ietf.org>] > On Behalf Of Mahesh Jethanandani > Sent: Sunday, January 17, 2016 10:11 PM > To: Nitish Gupta (nitisgup) mailto:nitis...@cisco.com>> > Cc: Jeff Haas mailto:jh...@juniper.net>>; > rtg-...@ietf.org <mailto:rtg-...@ietf.org>; Aditya Dogra (addogra) > mailto:addo...@cisco.com>>; co...@doch.org.uk > <mailto:co...@doch.org.uk>; rtgwg@ietf.org <mailto:rtgwg@ietf.org> > 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) <mailto: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 > <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, "internet-dra...@ietf.org > <mailto:internet-dra...@ietf.org>" <mailto: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 > <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://
Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt
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 mailto:rtgwg-boun...@ietf.org>> on behalf of Chris Bowers mailto:cbow...@juniper.net>> Date: Monday, January 18, 2016 at 1:38 PM To: Mahesh Jethanandani mailto:mjethanand...@gmail.com>>, "Nitish Gupta (nitisgup)" mailto:nitis...@cisco.com>> Cc: Jeff Haas mailto:jh...@juniper.net>>, "co...@doch.org.uk<mailto:co...@doch.org.uk>" mailto:co...@doch.org.uk>>, "rtg-...@ietf.org<mailto:rtg-...@ietf.org>" mailto:rtg-...@ietf.org>>, "Aditya Dogra (addogra)" mailto:addo...@cisco.com>>, Routing WG mailto:rtgwg@ietf.org>> Subject: RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt 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-, 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:rtgwg-boun...@ietf.org] On Behalf Of Mahesh Jethanandani Sent: Sunday, January 17, 2016 10:11 PM To: Nitish Gupta (nitisgup) mailto:nitis...@cisco.com>> Cc: Jeff Haas mailto:jh...@juniper.net>>; rtg-...@ietf.org<mailto:rtg-...@ietf.org>; Aditya Dogra (addogra) mailto:addo...@cisco.com>>; co...@doch.org.uk<mailto:co...@doch.org.uk>; rtgwg@ietf.org<mailto:rtgwg@ietf.org> 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) mailto: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<mailto:internet-dra...@ietf.org>" mailto: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 Mahesh Jethanandani mjethanand...@gmail.com<mailto:mjethanand...@gmail.com> ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt
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-, 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:rtgwg-boun...@ietf.org] On Behalf Of Mahesh Jethanandani Sent: Sunday, January 17, 2016 10:11 PM To: Nitish Gupta (nitisgup) Cc: Jeff Haas ; rtg-...@ietf.org; Aditya Dogra (addogra) ; co...@doch.org.uk; rtgwg@ietf.org 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) mailto: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<mailto:internet-dra...@ietf.org>" mailto: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 Mahesh Jethanandani mjethanand...@gmail.com<mailto:mjethanand...@gmail.com> ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
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) > 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" > 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 >> > Mahesh Jethanandani mjethanand...@gmail.com ___ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
RE: New Version Notification for draft-nitish-vrrp-bfd-02.txt
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: alexander.vainsht...@ecitele.com -Original Message- From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of Nitish Gupta (nitisgup) Sent: Wednesday, January 13, 2016 11:31 AM To: rtgwg@ietf.org; rtg-...@ietf.org Cc: jh...@juniper.net; co...@doch.org.uk; 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)" 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" > >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 rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
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)" 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" >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 rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
