< draft-nitish-vrrp-bfd-01.txt   draft-nitish-vrrp-bfd-02.txt >
Network Working Group N. Gupta Network Working Group N. Gupta
Internet-Draft A. Dogra Internet-Draft A. Dogra
Intended status: Informational Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: December 27, 2015 C. Docherty Expires: April 15, 2016 C. Docherty
June 25, 2015
Fast failure detection using peer learning in VRRP with BFD G. Mirsky
draft-nitish-vrrp-bfd-01 J. Tantsura
Ericsson
October 13, 2015
Abstract Fast failure detection in VRRP with BFD
draft-nitish-vrrp-bfd-02
This draft presents an enhanced failure detection mechanism to detect Abstract
the failure of VRRP Master router on the LAN using a peer learning
mode. Typically the VRRP protocol is able to perform the transparent
fail-over detection within a time period of 3 seconds with default
fail-over timers. Real-time protocols (voice/video/real-time
transactional) require a maximum network disruption in the order of
150ms for traffic on the network. A failure detection and fail-over
time of 150ms on conventionally configured VRRP protocol is extremely
aggressive and may impact the reliability and performance of the
network.
A more efficient mechanism for real-time failure detection can be This document describes how Bidirectional Forwarding Detection (BFD)
enabled in VRRP protocol by building a peer table, using a new VRRP can be used to support sub-second detection of a Master Router
Advert packet type. This will help in forming a mesh of BFD failure in the Virtual Router Redundancy Protocol (VRRP).
sessions. Once the BFD sessions are created, VRRP can receive faster
notification of failures, without the overhead of increased VRRP
protocol Advert messages.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 27, 2015. This Internet-Draft will expire on April 15, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Extension to VRRP protocol . . . . . . . . . . . . . . . . . . 6 3. Applicability of Single-hop BFD . . . . . . . . . . . . . . . 3
3.1. VRRP Peer Table . . . . . . . . . . . . . . . . . . . . . 6 3.1. Extension to VRRP protocol . . . . . . . . . . . . . . . 4
3.2. VRRP BACKUP ADVERTISEMENT Packet Type . . . . . . . . . . 7 3.2. VRRP Peer Table . . . . . . . . . . . . . . . . . . . . . 4
4. Sample configuration . . . . . . . . . . . . . . . . . . . . . 8 3.3. VRRP BACKUP ADVERTISEMENT Packet Type . . . . . . . . . . 4
5. Critical BFD session . . . . . . . . . . . . . . . . . . . . . 10 3.4. Sample configuration . . . . . . . . . . . . . . . . . . 5
6. Scalability Considerations . . . . . . . . . . . . . . . . . . 11 3.5. Critical BFD session . . . . . . . . . . . . . . . . . . 7
7. Operational Considerations . . . . . . . . . . . . . . . . . . 12 4. Applicability of p2mp BFD . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. Scalability Considerations . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Operational Considerations . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
11.1. Informative References . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
11.2. Normative References . . . . . . . . . . . . . . . . . . . 16 10. Normative References . . . . . . . . . . . . . . . . . . . . 9
Appendix A. Using Multipoint BFD sessions . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Fast failure detection in the network is becoming increasingly The Virtual Router Redundancy Protocol (VRRP) provides redundant
important. VRRP helps in providing redundant Virtual gateways in the Virtual gateways in the Local Area Network (LAN), which is typically
LAN, which is typically the first point of failure for end-hosts the first point of failure for end-hosts sending traffic out of the
sending traffic out of the LAN. A faster failure detection of VRRP LAN. Fast failure detection of VRRP Master is critical in supporting
master becomes very critical as it can isolate all end-hosts that are high availability of services and improved Quality of Experience to
unable to detect any alternate path. In VRRP [RFC5798] protocol users. In VRRP [RFC5798] specification, Backup routers depend on
specification, Backup routers depends on Advert packets generated at VRRP packets generated at a regular interval by the Master router, to
a regular interval by the Master router, to detect the health of the detect the health of the VRRP Master. Faster failure detection can
VRRP Master. Faster failure detection can be achieved within VRRP be achieved within VRRP protocol by reducing the Advertisement
protocol by reducing the Advert and hold down timers. But Aggressive Interval and hold down timers. However, aggressive timers can put
timers can put extra load on the network bandwidth which may not be extra load on CPU and the network bandwidth which may not be
desirable. desirable.
As the VRRP protocol depends on the availability of L3 IPv4 or IPv6 Since the VRRP protocol depends on the availability of Layer 3 IPv4
between redundant peers, VRRP protocol can interact with the L3 or IPv6 connectivity between redundant peers, the VRRP protocol can
variant of BFD as described in [RFC5881], to achieve a much faster interact with the Layer 3 variant of BFD as described in [RFC5881]
failure detection of the VRRP Master in the LAN. BFD as specified by or [I-D.draft-ietf-bfd-multipoint] to achieve a much faster failure
the RFC [RFC5880] can provide a much faster failure detection in the detection of the VRRP Master on the LAN. BFD, as specified by the
range of 150ms. [RFC5880] or [I-D.draft-ietf-bfd-multipoint] can provide a much
faster failure detection in the range of 150ms, if implemented in the
part of a Network device which scales better than VRRP when
aggressive timers are used.
BFD IPv4 or IPv6 [RFC5881] requires that for a BFD session to be 2. Requirements Language
formed, both peers participating in a BFD session need to know to its
peer IPv4 or IPV6 address. This poses a unique problem with the
definition of the VRRP [RFC5798] protocol, that makes the operation
with BFD IPv4 or IPv6 [RFC5881] more challenging. As in VRRP it is
only the Master peer that sends Advert packets. This means that a
Master peer is not aware of any Backup peers, and Backup peers are
only aware of the Master peer. This also means that Backup peers are
not aware of other Backups in the Network.
Since BFD IPv4 or IPv6 [RFC5881] requires that a session be formed by In this document, several words are used to signify the requirements
both peers using a full destination and source address, there needs of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
to be some external means to provide this information to BFD on "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
behalf of VRRP. Once the peer information is made available, VRRP and "OPTIONAL" in this document are to be interpreted as described in
can form BFD sessions with each of the peers that exist in the RFC 2119. [RFC2119]
3. Applicability of Single-hop BFD
BFD for IPv4 or IPv6 (Single Hop) [RFC5881] requires that in order
for a BFD session to be formed both peers participating in a BFD
session need to know to its peer IPv4 or IPV6 address. This poses a
unique problem with the definition of the VRRP protocol, that makes
the use of BFD for IPv4 or IPv6 [RFC5881] more challenging. In VRRP
it is only the Master router that sends Advert packets. This means
that a Master router is not aware of any Backup routers, and Backup
routers are only aware of the Master router. This also means that a
Backup router is not aware of any other Backup routers in the
Network.
Since BFD for IPv4 or IPv6 [RFC5881] requires that a session be
formed by both peers using a full destination and source address,
there needs to be some external means to provide this information to
BFD on behalf of VRRP. Once the peer information is made available,
VRRP can form BFD sessions with each of the peers that exist in the
Virtual Router. The most important BFD session for a given Virtual Virtual Router. The most important BFD session for a given Virtual
Router is identified as the Critical Path BFD Session, which is the Router is identified as the Critical Path BFD Session, which is the
session that forms between the current VRRP Master, and the highest session that forms between the current VRRP Master router, and the
priority Backup. Should the Critical Path BFD Session be identified highest priority Backup router. When the Critical Path BFD Session
by the VRRP as having changed state from UP to DOWN, then this will identified by VRRP as having changed state from Up to Down, then this
be interpreted by the VRRP state machine on the highest priority will be interpreted by the VRRP state machine on the highest priority
Backup peer as a Master Down event. A Master Down event means that Backup router as a Master Down event. A Master Down event means that
the highest priority Backup peer will immediately become the new the highest priority Backup peer will immediately become the new
Master for the Virtual Router. Master for the Virtual Router.
NOTE: At all times, the normal fail-over mechanism defined in the NOTE: At all times, the normal fail-over mechanism defined in the
VRRP [RFC5798] will be unaffected, and the BFD fail-over mechanism VRRP [RFC5798] will be unaffected, and the BFD fail-over mechanism
will always resort to normal VRRP fail-over. will always resort to normal VRRP fail-over.
This draft defines the mechanism used by VRRP protocol to Build a This draft defines the mechanism used by the VRRP protocol to build a
peer table that will help in forming a mesh of BFD sessions and the peer table that will help in forming a mesh of BFD sessions and the
detection of Critical Path BFD session. If the Critical Path BFD detection of Critical Path BFD session. If the Critical Path BFD
session were to go down it will signal a Master down event and make session were to go down, it will signal a Master Down event and make
the most preferred Backup router as the VRRP Master. This requires the most preferred Backup router as the VRRP Master router. This
an extension to the VRRP protocol. requires an extension to the VRRP protocol.
This can be achieved by defining a new type in the VRRP Advert This can be achieved by defining a new type in the VRRP Advert
packet, and allowing VRRP peers to build a peer table in any of the packet, and allowing VRRP peers to build a peer table in any of the
operational state, Master or Backup. operational state, Master or Backup.
2. Requirements Language 3.1. Extension to VRRP protocol
In this document, several words are used to signify the requirements
of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in
RFC 2119. [RFC2119]
3. Extension to VRRP protocol
In this mode of operation VRRP peers learn the adjacent peers, and In this mode of operation VRRP peers learn the adjacent routers, and
form BFD sessions between the learnt peers. In order to build the form BFD sessions between the learnt routers. In order to build the
peer table, all peers send VRRP Advert packets whilst in any of the peer table, all routers send VRRP Advert packets whilst in any of the
operational states (Master or Backup). Normally VRRP [RFC5798] peers operational states (Master or Backup). Normally VRRP peers only send
only send Advert packets whilst in the Master state, however in this Advert packets whilst in the Master state, however in this mode VRRP
mode VRRP Backup peers will also send Advert packets with the type Backup peers will also send Advert packets with the type field set to
field set to BACKUP ADVERTISEMENT type defined in Section 3.2. VRRP BACKUP ADVERTISEMENT type defined in Section 3.3 of this document.
Master peer will still continue to send packets with Advert type as The VRRP Master router will still continue to send packets with the
ADVERTISEMENT as defined in the VRRP [RFC5798] protocol. This is to Advert type as ADVERTISEMENT as defined in the VRRP protocol. This
maintain inter-operability with peers complying to VRRP [RFC5798] is to maintain inter-operability with peers complying to VRRP
protocol. protocol.
Additionally Advert packets sent from Backup Peers must not use the Additionally Advert packets sent from Backup Peers must not use the
Virtual router MAC address as the source address. Instead it must Virtual router MAC address as the source address. Instead it must
use the Interface MAC address as the source address from which the use the Interface MAC address as the source address from which the
packet is sent from. This is because the source MAC override feature packet is sent from. This is because the source MAC override feature
is used by the Master to send Advert packets from the Virtual Router is used by the Master to send Advert packets from the Virtual Router
MAC address, which is used to keep the bridging cache on LAN switches MAC address, which is used to keep the bridging cache on LAN switches
and bridging devices refreshed with the destination port for the and bridging devices refreshed with the destination port for the
Virtual Router MAC. Virtual Router MAC.
3.1. VRRP Peer Table 3.2. VRRP Peer Table
VRRP peers can now form the peer table by learning the source address VRRP peers can now form the peer table by learning the source address
in the ADVERTISEMENT or BACKUP ADVERTISEMENT packet sent by VRRP in the ADVERTISEMENT or BACKUP ADVERTISEMENT packet sent by VRRP
Master or Backup peers. This allows all peers to create a mesh of Master or Backup peers. This allows all peers to create a mesh of
BFD sessions with all other operational peers. BFD sessions with all other operational peers.
A peer entry should be removed from the peer table if Advert is not A peer entry should be removed from the peer table if Advert is not
received from a peer for a period of (3 * the Advert interval). received from a peer for a period of (3 * the Advert interval).
3.2. VRRP BACKUP ADVERTISEMENT Packet Type 3.3. VRRP BACKUP ADVERTISEMENT Packet Type
The following figure shows the VRRP packet as defined in VRRP The following figure shows the VRRP packet as defined in VRRP
[RFC5798] RFC. [RFC5798] RFC.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Fields or IPv6 Fields | | IPv4 Fields or IPv6 Fields |
... ... ... ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 5 skipping to change at page 5, line 42
VRRP Master Router. Type 2 (BACKUP ADVERTISEMENT) is used by the VRRP Master Router. Type 2 (BACKUP ADVERTISEMENT) is used by the
VRRP Backup router. This is to distinguish the packets sent by the VRRP Backup router. This is to distinguish the packets sent by the
VRRP backup Router. Rest of the fields in Advert packet remain the VRRP backup Router. Rest of the fields in Advert packet remain the
same. same.
1 ADVERTISEMENT 1 ADVERTISEMENT
2 BACKUP ADVERTISEMENT 2 BACKUP ADVERTISEMENT
A packet with unknown type MUST be discarded. A packet with unknown type MUST be discarded.
4. Sample configuration 3.4. Sample configuration
The following figure shows a simple network with three VRRP routers The following figure shows a simple network with three VRRP routers
implementing one virtual router. implementing one virtual router.
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
| Rtr1 | | Rtr2 | | Rtr3 | | Rtr1 | | Rtr2 | | Rtr3 |
|(MR VRID=1)| |(BR VRID=1)| |(BR VRID=1)| |(MR VRID=1)| |(BR VRID=1)| |(BR VRID=1)|
| (PR=200) | | (PR=150) | | (PR=100) | | (PR=200) | | (PR=150) | | (PR=100) |
| VRIPVX= A | | VRIPVX= A | | VRIPVX= A | | VRIPVX= A | | VRIPVX= A | | VRIPVX= A |
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
B C D B C D
skipping to change at page 8, line 34 skipping to change at page 6, line 31
BR = Backup Router BR = Backup Router
PR = VRRP Router priority PR = VRRP Router priority
VRID = VRRP Router ID VRID = VRRP Router ID
VRIPVX= IPv4 or IPv6 address protected by VRIPVX= IPv4 or IPv6 address protected by
the VRRP Router the VRRP Router
B,C,D = Interface IPv4 or IPv6 address of B,C,D = Interface IPv4 or IPv6 address of
the Virtual Router the Virtual Router
In the above configuration there are three routers on the LAN In the above configuration there are three routers on the LAN
protecting an IPv4 or IPv6 address associated to a Virtual Router ID protecting an IPv4 or IPv6 address associated to a Virtual Router ID
1. The Rtr1 is the master router as it has the highest priority 1. Rtr1 is the Master router since it has the highest priority
compared the Rtr2 and Rtr3. Now if peer learning extension is compared to Rtr2 and Rtr3. Now if peer learning extension is enabled
enabled on all the peers. Rtr1 will send the Advert packet with type on all the peers. Rtr1 will send the Advert packet with type field
field set to 1. While Rtr2 and Rtr3 will send the Advert packet with set to 1. While Rtr2 and Rtr3 will send the Advert packet with type
type field set to 2. In the above configuration the peer table built field set to 2. In the above configuration the peer table built at
at each router is shown below: each router is shown below:
Rtr1 Peer table Rtr1 Peer table
+------------------------------------+ +------------------------------------+
| Peer Address | Priority | | Peer Address | Priority |
+------------------------------------+ +------------------------------------+
| C | 150 | | C | 150 |
+------------------------------------+ +------------------------------------+
| D | 100 | | D | 100 |
+------------------------------------+ +------------------------------------+
skipping to change at page 10, line 5 skipping to change at page 7, line 27
| Peer Address | Priority | | Peer Address | Priority |
+------------------------------------+ +------------------------------------+
| B | 200 | | B | 200 |
+------------------------------------+ +------------------------------------+
| C | 150 | | C | 150 |
+------------------------------------+ +------------------------------------+
Once the peer tables are formed, VRRP on each router can form a mesh Once the peer tables are formed, VRRP on each router can form a mesh
of BFD sessions with all the learnt peers. of BFD sessions with all the learnt peers.
5. Critical BFD session 3.5. Critical BFD session
Critical BFD Session is determined to be the session between the VRRP The Critical BFD Session is determined to be the session between the
Master and the next best VRRP Backup. Failure of the Critical BFD VRRP Master and the next best VRRP Backup. Failure of the Critical
session indicates that the Master is no longer available and the most BFD session indicates that the Master is no longer available and the
preferred Backup will now become Master. most preferred Backup will now become Master.
In the above example the Critical BFD session is shared between Rtr1 In the above example the Critical BFD session is shared between Rtr1
and Rtr2. If the BFD Session goes from UP to DOWN state, Rtr2 can and Rtr2. If the BFD Session goes from Up to Down state, Rtr2 can
treat it as a Master down event and immediately assume the role of treat it as a Master down event and immediately assume the role of
VRRP Master router for VRID 1 and Rtr3 will become the critical VRRP Master router for VRID 1 and Rtr3 will become the critical
backup. Backup.
6. Scalability Considerations 4. Applicability of p2mp BFD
[I-D.draft-ietf-bfd-multipoint] provides an alternative solution that
uses default route rather than dynamic routing. This approach can be
an efficient in some network deployments. Each redundancy group
presents itself as p2mp BFD session with its Master being the root
and Backup routers being tails of the p2mp BFD session. The Master
router starts transmitting BFD control packets with VRID as source IP
address. Backup router demultiplexes p2mp BFD test sessions based on
VRID that it been configured with. Once Backup router accepts p2mp
session from the new Master router backup router the Backup router
MAY use My Discriminator from received p2mp BFD control packet to
demultiplex p2mp BFD sessions. When a Backup router detects failure
of the Master router it re-evaluates its role in the VRID. As
result, the Backup router may become the Master router of the given
VRID or continue as a Backup router. If the former is the case, then
the new Master router MUST select My Discriminator and start
transmitting p2mp BFD control packets using Master IP address as
source IP address for p2mp BFD control packets. If the latter is the
case, then the Backup router MUST wait for p2mp BFD control packet
with source IP address set to VRID.
5. Scalability Considerations
When forming mesh of BFD sessions one possible scenario can occur if When forming mesh of BFD sessions one possible scenario can occur if
the system is not able to scale well with the increased load of the system is not able to scale well with the increased load of
multiple BFD sessions. To mitigate this problem sharing of BFD multiple BFD sessions. To mitigate this problem sharing of BFD
sessions with other protocols and opening less number of BFD sessions sessions with other protocols and opening less number of BFD sessions
should be considered, i.e between Master and the most preferred should be considered, i.e. between Master and the most preferred
Backup router part of the VRRP instance. Backup router of the VRRP instance.
To reduce the number of packets generated at a regular interval, To reduce the number of packets generated at a regular interval,
Backup Advert packets may be sent at a reduced rate as compared to Backup Advert packets may be sent at a reduced rate as compared to
Advert packets sent by the VRRP Master. Advert packets sent by the VRRP Master.
7. Operational Considerations In a Data Centre with VXLAN extending the Layer 2 network, when
implementing Section 4 of this document, inherently multicast traffic
is flooded or replicated to all the Virtual Tunneling End Points by
means of multicast traffic in the underlay network. The amount of
replication or flooding depends on the number of Virtual Tunnelling
End Points connected to the VXLAN network. VRRP is typically
deployed on the Virtual Tunneling End Points. If Multipoint BFD is
used for tracking the state of VRRP Master Router the Multipoint BFD
packets will get carried over the Layer 2 Overlay, this can lead to a
lot of traffic getting flooded on the overlay as the rate at which
BFD packets are generated will be typically in sub second range.
Which is the problem if VRRP is configured with sub second timers.
So in such scenarios where flooding of Multicast traffic is a
concern, it is recommended to use Point to Point BFD sessions to
avoid inherent flooding of Multicast traffic and configure VRRP to
default or slow timers.
A VRRP [RFC5798] peer that forms a member of this Virtual Router, but 6. Operational Considerations
does not support this feature or extension must be configured with
the lowest priority, and will only operate as the Router of last A VRRP peer that forms a member of this Virtual Router, but does not
resort on failure of all other VRRP routers supporting this support this feature or extension must be configured with the lowest
functionality. priority, and will only operate as the Router of last resort on
failure of all other VRRP routers supporting this functionality.
It is recommended that mechanism defined by this draft, to interface It is recommended that mechanism defined by this draft, to interface
VRRP with BFD should be used when BFD can support more aggressive VRRP with BFD should be used when BFD can support more aggressive
monitoring timers than VRRP. Otherwise it is desirable not to monitoring timers than VRRP. Otherwise it is desirable not to
interface VRRP with BFD for determining the health of VRRP Master. interface VRRP with BFD for determining the health of VRRP Master.
This Draft does not preclude the possibility of the peer table being This Draft does not preclude the possibility of the peer table being
populated by means of manual configuration, instead of using the populated by means of manual configuration, instead of using the
BACKUP ADVERTISEMENT as defined by the Draft. BACKUP ADVERTISEMENT as defined by the Draft.
8. IANA Considerations 7. IANA Considerations
This draft includes no request to IANA. This draft includes no request to IANA.
9. Security Considerations 8. Security Considerations
Security considerations are discussed in the Section 9 of VRRP Security considerations discussed in [RFC5798], [RFC5880] and
protocol [RFC5798] specification. There are no additional security [I-D.draft-ietf-bfd-multipoint], apply to this document. There are
considerations identified by this draft. no additional security considerations identified by this draft.
10. Acknowledgements 9. Acknowledgements
The authors gratefully acknowledge the contributions of Gerry Meyer, The authors gratefully acknowledge the contributions of Gerry Meyer,
and Mouli Chandramouli, for their contributions to the draft. The and Mouli Chandramouli, for their contributions to the draft. The
authors will also like to thank Jeffrey Hass, Maik Pfeil and Vengada authors will also like to thank Jeffrey Haas, Maik Pfeil and Vengada
Prasad Govindan for their comments and suggestions. Prasad Govindan for their comments and suggestions.
11. References 10. Normative References
11.1. Informative References
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880. (BFD)", RFC 5880, 2010.
11.2. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119. Requirement Levels", RFC 2119, 1997.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881. (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 2010.
[RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP)
Version 3 for IPv4 and IPv6", RFC 5798. Version 3 for IPv4 and IPv6", RFC 5798, 2010.
[I-D.draft-ietf-bfd-multipoint] [I-D.draft-ietf-bfd-multipoint]
Katz, D., Ward, D., and S. Pallagatti, "BFD for Multipoint Katz, D., Ward, D., and S. Pallagatti, "BFD for Multipoint
Networks", Work in Progress draft-ietf-bfd-multipoint-06. Networks", Work in Progress draft-ietf-bfd-multipoint-07,
2015.
Appendix A. Using Multipoint BFD sessions
Possibility of detecting the failure of VRRP Master using Multipoint
BFD [I-D.draft-ietf-bfd-multipoint] sessions is still under
consideration.
Authors' Addresses Authors' Addresses
Nitish Gupta Nitish Gupta
Cisco Systems, Inc. Cisco Systems, Inc.
Sarjapur Outer Ring Road Sarjapur Outer Ring Road
Bangalore 560103 Bangalore 560103
India India
Phone: +91 80 4429 2530 Phone: +91 80 4429 2530
skipping to change at line 410 skipping to change at page 10, line 34
Email: addogra@cisco.com Email: addogra@cisco.com
URI: http://www.cisco.com/ URI: http://www.cisco.com/
Colin Docherty Colin Docherty
25 George Grieve Way 25 George Grieve Way
Tranent Tranent
East Lothian, Scotland EH332QT East Lothian, Scotland EH332QT
United Kingdom United Kingdom
Email: colin@doch.org.uk Email: colin@doch.org.uk
Greg Mirsky
Ericsson
Email: gregory.mirsky@ericsson.com
Jeff Tantsura
Ericsson
Email: jeff.tantsura@ericsson.com
 End of changes. 42 change blocks. 
150 lines changed or deleted 173 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/