Internet DRAFT - draft-ietf-trill-p2mp-bfd
draft-ietf-trill-p2mp-bfd
TRILL M. Zhang
Internet-Draft Huawei Technologies
Intended status: Standards Track S. Pallagatti
Updates: 7175, 7177
V. Govindan
Cisco Systems
Expires: August 11, 2018 February 7, 2018
TRILL Support of Point to Multipoint BFD
draft-ietf-trill-p2mp-bfd-09
Abstract
Point to multipoint (P2MP) BFD is designed to verify multipoint
connectivity. This document specifies the support of P2MP BFD in
TRILL. Similar to TRILL point-to-point BFD, BFD Control packets in
TRILL P2MP BFD are transmitted using RBridge Channel messages. This
document updates RFC 7175 and RFC 7177.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Zhang, et al. Expires August 11, 2018 [Page 1]
Internet-Draft P2MP BFD for TRILL February 7, 2018
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . . 2
2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 3
4. A New RBridge Channel Message for P2MP BFD . . . . . . . . . . 3
5. Discriminators and Packet Demultiplexing . . . . . . . . . . . 4
6. Tracking Active Tails . . . . . . . . . . . . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . 4
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
10.1. Normative References . . . . . . . . . . . . . . . . . . 5
10.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
TRILL supports multicast forwarding. Applications based on TRILL
multicast may need quick detection of multicast failures using P2MP
BFD [I-D.ietf-bfd-multipoint]. This document specifies TRILL support
of P2MP BFD.
To use P2MP BFD, the head end needs to periodically transmit BFD
Control packets to all tails using TRILL multicast. A new RBridge
Channel message is allocated for this purpose.
In order to execute the global protection of distribution used for
multicast forwarding [I-D.ietf-trill-resilient-trees], the head needs
to track the active status of tails
[I-D.ietf-bfd-multipoint-active-tail]. If the tail loses
connectivity as detected by not receiving the new RBridge Channel
message from the head, the tail should notify the head of the lack of
multipoint connectivity with unicast BFD Control packets. These
unicast BFD Control packets are transmitted using the existing
RBridge Channel message assigned to BFD Control [RFC7175].
This document updates [RFC7177] as specified in Section 3 and updates
[RFC7175] as specified in Section 4 and Section 5.
2. Acronyms and Terminology
Zhang, et al. Expires August 11, 2018 [Page 2]
Internet-Draft P2MP BFD for TRILL February 7, 2018
2.1. Acronyms
Data Label: VLAN or Fine Grained Label [RFC7172].
BFD: Bidirectional Forwarding Detection
P2MP: Point to Multi-Point
TRILL: Transparent Interconnection of Lots of Links or Tunneled
Routing in the Link Layer
2.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Familiarity with [RFC6325], [RFC7175], and [RFC7178] is assumed in
this document.
3. Bootstrapping
The TRILL adjacency mechanism bootstraps the establishment of one-hop
TRILL BFD sessions [RFC7177]. Multi-hop sessions are expected to be
configured by the network manager. A slight wording update to the
second sentence in Section 6 of [RFC7177] is required.
It currently read:
If an RBridge supports BFD [RFC7175], it will have learned whether
the other RBridge has BFD enabled by whether or not a BFD-Enabled
TLV [RFC6213] was included in its Hellos.
Now it should read:
If an RBridge supports BFD [RFC7175] [this document], it will have
learned whether the other RBridge has BFD enabled by whether or
not a BFD-Enabled TLV [RFC6213] was included in its Hellos.
4. A New RBridge Channel Message for P2MP BFD
RBridge Channel message protocol 0x002 is defined for TRILL point-to-
point BFD Control packets in [RFC7175]. That RFC provides that if
the M bit of the TRILL Header of the RBridge channel packet
containing a BFD Control packet is non-zero, the packet is generally
dropped. In P2MP BFD, the head is required to probe tails using
Zhang, et al. Expires August 11, 2018 [Page 3]
Internet-Draft P2MP BFD for TRILL February 7, 2018
multicast. This means the M bit will be set to 1. For this reason,
a new RBridge Channel message, whose protocol code point is TBD, is
specified in this document. An RBridge that supports P2MP BFD MUST
support the new RBridge Channel message for P2MP BFD. The capability
to support the RBridge Channel message for P2MP BFD, and therefore
support performing P2MP BFD, is announced within the "RBridge Channel
Protocols Sub-TLV" in LSPs [RFC7176].
As specified in [RFC7178], when the tail receives TRILL Data packets
sent as BFD RBridge channel messages, it will absorb the packets
itself rather than deliver these packets to its attached end-
stations.
5. Discriminators and Packet Demultiplexing
The processing in Section 3.2 of [RFC7175] generally applies except
that the test on the M bit in the TRILL Header is reversed. If the M
bit is zero, the packet MUST be discarded. If the M bit is one, it
is processed.
After the Section 3.2 of [RFC7175] processing, the tail demultiplexes
incoming BFD packets based on a combination of the source address and
My Discriminator as specified in [I-D.ietf-bfd-multipoint]. In
addition to this combination, TRILL P2MP BFD requires that the tail
use the Data Label, which is either the inner VLAN or the Fine
Grained Label [RFC7172], for demultiplexing. If the tail needs to
notify the head about the failure of a multipath, the tail is
required to send unicast BFD Control packets using the same Data
Label as used by the head.
6. Tracking Active Tails
According to [I-D.ietf-bfd-multipoint], the head has a session of
type MultipointHead that is bound to a multipoint path. Multipoint
BFD Control packets are sent by this session over the multipoint
path, and no BFD Control packets are received by it. Each tail
dynamically creates a MultipointTail per a multipoint path.
MultipointTail sessions receive BFD Control packets from the head
over multipoint paths.
An example use is when a multicast tree root needs to keep track of
all the receivers as in [I-D.ietf-trill-resilient-trees]; this can be
done by maintaining a session of type MultipointClient per receiver
that is of interest, as described in [I-D.ietf-bfd-multipoint-active-
tail]. See [I-D.ietf-bfd-multipoint-active-tail] for detail
operations of tracking active tails.
7. Security Considerations
Zhang, et al. Expires August 11, 2018 [Page 4]
Internet-Draft P2MP BFD for TRILL February 7, 2018
Multipoint BFD provides its own authentication but does not provide
encryption (see Security Considerations in [I-D.ietf-bfd-
multipoint]). As specified in this document, the point-to-multipoint
BFD payloads are encapsulated in RBridge Channel messages which have
been extended by [RFC7978] to provide security. [RFC7978] provides
encryption only for point-to-point extended RBridge Channel messages
so its encryption facilities are not applicable to this draft.
However [RFC7978] provides stronger authentication than that
currently provided in BFD. Thus, there is little reason to use the
BFD security mechanisms if [RFC7978] authentication is in use. It is
expected that a future TRILL document will provide for group keying;
when that occurs, the use of [RFC7978] RBridge Channel security will
be able to provide both encryption and authentication.
For general multipoint BFD security considerations, see
[I-D.ietf-bfd-multipoint].
For general RBridge Channel security considerations, see [RFC7178].
8. IANA Considerations
IANA is required to allocate a number from the Standards Action range
of the RBridge Channel Protocols registry which is part of the
Transparent Interconnection of Lots of Links (TRILL) Parameters. The
number to be allocated is as follows:
Protocol Number
---------------- ------
P2MP BFD Control TBD
9. Acknowledgements
Authors would like to thank the comments and suggestions from Gayle
Noble and Donald Eastlake.
10. References
10.1. Normative References
[I-D.ietf-bfd-multipoint]
Katz, D., Ward, D., and J. Networks, "BFD for Multipoint
Networks", draft-ietf-bfd-multipoint (work in progress).
[I-D.ietf-bfd-multipoint-active-tail]
Katz, D., Ward, D., and J. Networks, "BFD Multipoint
Active Tails.", draft-ietf-bfd-multipoint-active-tail
(work in progress).
Zhang, et al. Expires August 11, 2018 [Page 5]
Internet-Draft P2MP BFD for TRILL February 7, 2018
[RFC7978] Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent
Interconnection of Lots of Links (TRILL): RBridge Channel
Header Extension", RFC 7978, DOI 10.17487/RFC7978,
September 2016, <http://www.rfc-editor.org/info/rfc7978>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, July 2011.
[RFC7172] Eastlake, D., Zhang, M., Agarwal, P., Perlman, R., and D.
Dutt, "Transparent Interconnection of Lots of Links
(TRILL): Fine-Grained Labeling", RFC 7172, May 2014.
[RFC7175] Manral, V., Eastlake, D., Ward, D., and A. Banerjee,
"Transparent Interconnection of Lots of Links (TRILL):
Bidirectional Forwarding Detection (BFD) Support", RFC
7175, May 2014.
[RFC7176] Eastlake, D., Senevirathne, T., Ghanwani, A., Dutt, D.,
and A. Banerjee, "Transparent Interconnection of Lots of
Links (TRILL) Use of IS-IS", RFC 7176, May 2014.
[RFC7177] Eastlake, D., Perlman, R., Ghanwani, A., Yang, H., and V.
Manral, "Transparent Interconnection of Lots of Links
(TRILL): Adjacency", RFC 7177, May 2014.
[RFC7178] Eastlake, D., Manral, V., Li, Y., Aldrin, S., and D. Ward,
"Transparent Interconnection of Lots of Links (TRILL):
RBridge Channel Support", RFC 7178, May 2014.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References
[RFC6213] Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled TLV", RFC
6213, April 2011.
[I-D.ietf-trill-resilient-trees]
Zhang, M., Senevirathne, T., Pathangi, J., Banerjee, A.,
and A. Ghanwani, "TRILL Resilient Distribution Trees",
draft-ietf-trill-resilient-trees (work in progress).
Zhang, et al. Expires August 11, 2018 [Page 6]
Internet-Draft P2MP BFD for TRILL February 7, 2018
Authors' Addresses
Mingui Zhang
Huawei Technologies
No.156 Beiqing Rd. Haidian District
Beijing 100095
P.R. China
Email: zhangmingui@huawei.com
Santosh Pallagatti
India
Email: santosh.pallagatti@gmail.com
Vengada Prasad Govindan
Cisco Systems
Email: venggovi@cisco.com
Zhang, et al. Expires August 11, 2018 [Page 7]
