wdiff rfc7175.original rfc7175.txt

TRILL Working Group
Internet Engineering Task Force (IETF) V. Manral
INTERNET-DRAFT Hewlett Packard Co.
Intended status: Proposed Standard
Request for Comments: 7175 Ionos Corp.
Category: Standards Track D. Eastlake 3rd
ISSN: 2070-1721 Huawei R&D USA
D. Ward
Cisco Systems
A. Banerjee
Cumulus Networks
Expires: January 15, 2013 July 16, 2012

TRILL (Transparent Interconnetion
April 2014

Transparent Interconnection of Lots of Links): Links (TRILL):
Bidirectional Forwarding Detection (BFD) Support
<draft-ietf-trill-rbridge-bfd-07.txt>

Abstract

This document specifies use of the BFD (Bidirectional Bidirectional Forwarding
Detection) Detection
(BFD) protocol in RBridge Routing Bridge (RBridge) campuses based on the Rbridge
RBridge Channel extension to the the TRILL (TRansparent Transparent Interconnection of Lots
of
Links) Links (TRILL) protocol.

BFD is a widely deployed OAM (Operations, Operations, Administration, and
Maintenance) Maintenance
(OAM) mechanism in IP and MPLS (Multi Protocol Label
Switching) networks, using UDP and ACH (Associated Associated
Channel Header) Header (ACH) encapsulation respectively. This document
specifies the BFD encapsulation over TRILL.

Status of This Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. Distribution of this an Internet Standards Track document.

This document is
unlimited. Comments should be sent to the TRILL working group mailing
list: <rbridge@postel.org>.

Internet-Drafts are working documents a product of the Internet Engineering Task Force (IETF), its areas,
(IETF). It represents the consensus of the IETF community. It has
received public review and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It
http://www.rfc-editor.org/info/rfc7175.

This document is inappropriate subject to use Internet-Drafts 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 reference
material or they describe your rights and restrictions with respect
to cite them other than this document. Code Components extracted from this document must
include Simplified BSD License text as "work described in progress."

INTERNET-DRAFT BFD TRILL Encapsulation

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html. The list Section 4.e of Internet-Draft
Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

INTERNET-DRAFT BFD TRILL Encapsulation
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction............................................4
1.1 Terminology............................................4 Introduction ....................................................2
1.1. Terminology ................................................3
2. BFD over TRILL.........................................6
2.1 TRILL ..................................................3
2.1. Sessions and Initialization............................6 Initialization ................................4
3. TRILL BFD Control Protocol..............................8
3.1 Protocol ......................................4
3.1. One-Hop TRILL BFD Control..............................8
3.2 Control ..................................5
3.2. BFD Control Frame Processing...........................8 Processing ...............................5
4. TRILL BFD Echo Protocol.................................9
4.1 Protocol .........................................5
4.1. BFD Echo Frame Processing.............................9 Processing ..................................6
5. Management and Operations Considerations...............11 Considerations ........................7
6. Default Authentication.................................12 Authentication ..........................................7
7. Security Considerations................................14 Considerations .........................................8
8. IANA Considerations....................................15 Considerations .............................................9
9. Acknowledgements.......................................15 Acknowledgements ................................................9
10. References .....................................................9
10.1. Normative References......................................16 References ......................................9
10.2. Informative References....................................16
Recent Changes Record.....................................18

INTERNET-DRAFT BFD TRILL Encapsulation References ...................................10

1. Introduction

Faster convergence is a critical feature of TRILL (Transparent Transparent
Interconnection of Lots of Links [RFC6325]) (TRILL) [RFC6325] networks. The
TRILL IS-
IS IS-IS Hellos [RFC6327] [RFC7177] [IS-IS] used between RBridges provide a
basic neighbor and continuity check for TRILL links. However,
failure detection by non- receipt non-receipt of such Hellos is based on the holding time
Holding Time parameter that is commonly set to a value of tens of
seconds and, in any case, has a minimum expressible value of one
second.

Some applications, including voice Voice over IP, may wish, with high
probability, to detect interruptions in continuity within a much
shorter time period. In some cases physical layer cases, physical-layer failures can be
detected very rapidly rapidly, but this is not always possible, such as when
there is a failure between two bridges that are in turn between two
RBridges. There are also many subtle failures possible at higher
levels. For example, some forms of failure could affect unicast
frames while still letting multicast frames through; since all TRILL
IS-IS Hellos are multicast multicast, such a failure cannot be detected with
Hellos. Thus, a low overhead low-overhead method for frequently testing
continuity for the TRILL Data between neighbor RBridges is necessary
for some applications. The BFD (Bi-directional Forwarding Detection
[RFC5880]) protocol [RFC5880] provides a low-overhead low-
overhead method for the rapid detection of connectivity failures.

BFD is a widely deployed OAM (Operations, Administration, and
Maintenance, [RFC6291]) [RFC6291] mechanism in IP and MPLS (Multi Protocol
Label Switching)
networks, using UDP and ACH (Associated Channel
Header) encapsulation encapsulation, respectively. This
document describes a TRILL encapsulation for BFD packets for networks
that forward based on the TRILL Header.

1.1

1.1. Terminology

This document uses the acronyms defined in [RFC6325] along with the
following:

BFD: Bi-directional Bidirectional Forwarding Detection

IP: Internet Protocol

IS-IS: Intermediate-System Intermediate System to Intermediate-System Intermediate System

MH: Multi-Hop

PPP: Point-to-Point Protocol

INTERNET-DRAFT BFD TRILL Encapsulation

OAM: Operations, Administration, and Maintenance

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 [RFC2119].

INTERNET-DRAFT BFD TRILL Encapsulation

2. BFD over TRILL

TRILL supports unicast neighbor BFD Echo and one-hop and multi-hop
BFD Control, as specified below, over the Rbridge RBridge Channel facility
[TRILLChannel].
[RFC7178]. (Multi-destination BFD is a work in progress [MultiBFD].) BFD over TRILL
BFD-over-TRILL support is similar to BFD over IP BFD-over-IP support
[RFC5881] [RFC5881],
except where differences are explicitly mentioned.

Asynchronous and demand modes MUST BE be supported [RFC5880]. BFD over
TRILL supports the Echo function, however function; however, implementation of TRILL
BFD Echo is optional optional, and it can only be used for single-hop
sessions.

The TRILL Header hop count in the BFD packets is sent out with the
maximum value of 0x3F. To prevent spoofing attacks, the TRILL hop
count of a received session is checked [RFC5082]. For a single-hop
session
session, if the hop count is less than 0x3F and the Rbridge RBridge Channel
Header MH flag is zero, the packet is discarded. For multihop
sessions multi-hop
sessions, the hop count check can be disabled if the MH flag is one.

As in BFD for IP IP, the format of the Echo Packet content is not
defined.

New Rbridge RBridge Channel code points for BFD TRILL Control and BFD Echo
packets are specified.

Authentication mechanisms as supported in BFD are also supported for
BFD running over TRILL.

2.1

2.1. Sessions and Initialization

Within an RBridge campus, there will be no more than one TRILL BFD
Control session from any RBridge RB1 to RBridge RB2 for each RB1
TRILL port. This BFD session must be bound to this interface. As
such, both sides of a session MUST take the "Active" role (sending
initial BFD Control packets with a zero value of Your Discriminator),
and any BFD packet from the remote machine with a zero value of Your
Discriminator MUST be associated with the session bound to the remote
system and interface.

Note that TRILL BFD provides OAM facilities for the TRILL data plane.
This is above whatever protocol is in use on a particular link, such
as a PPP [RFC6361] link or an pseudowire [RFC7173], Ethernet [RFC6325], or PPP link [RFC6325]. Link
technology specific [RFC6361].
Link-technology-specific OAM protocols may be used on a link between
neighbor RBridges, for example example, Continuity Fault Management [802.1Q]
if the link is Ethernet. But such link layer link-layer OAM and (and coordination
between it and OAM in the TRILL data plane layer OAM, data-plane layer, such as TRILL BFD, BFD)
is beyond the scope of this document.

INTERNET-DRAFT BFD TRILL Encapsulation

If lower level mechanisms, lower-level mechanisms are in use, such as link aggregation
[802.1AX], are in
use that present a single logical interface to TRILL IS-IS,
then only a single TRILL BFD session can be established to any other
RBridge over this logical interface. However, lower layer lower-layer OAM could
be aware of and/or run separately on each of the components of an
aggregation.

INTERNET-DRAFT BFD TRILL Encapsulation

3. TRILL BFD Control Protocol

TRILL BFD Control frames are unicast TRILL Rbridge RBridge Channel frames
[TRILLChannel].
[RFC7178]. The Rbridge RBridge Channel Protocol value is given in Section 8.
The protocol specific protocol-specific data associated with the TRILL BFD Control
protocol is as shown in Section 4.1 of [RFC5880].

3.1

3.1. One-Hop TRILL BFD Control

One-hop TRILL BFD Control is typically used to rapidly detect link
and RBridge failures. TRILL BFD frames over one hop for such
purposes SHOULD be sent with high priority; that is, the Inner.VLAN
tag priority should be 7, they should be queued for transmission as
maximum priority frames frames, and, if they are being sent on an Ethernet
link where the output port is configured to include an Outer.VLAN
tag, that tag should specify priority 7.

For neighbor RBridges RB1 and RB2, each RBridge sends one-hop TRILL
BFD Control frames to the other only if TRILL IS-IS has detected bi-
directional connectivity,
bidirectional connectivity; that is, the adjacency is in the Two-Way 2-Way or
Report state [RFC6327] [RFC7177], and both RBridges indicate support of TRILL
BFD is enabled. The BFD Enabled BFD-Enabled TLV is used to indicate this as
specified in [RFC6213].

3.2

3.2. BFD Control Frame Processing

The following tests SHOULD be performed on received TRILL BFD Control
frames before generic BFD processing.

o Is the M-bit M bit in the TRILL Header non-zero? If so, discard the
frame. (Multi-destination BFD is a work in progress [MultiBFD].)
Failure to perform this test would make a denial-of-service attack
using bogus multi-destination BFD Control frames easier.

o If the Channel Header MH flag is zero, indicating one-hop, one hop, test
that the TRILL Header hop count received was 0x3F (i.e., is 0x3E
if it has already been decremented) and decremented); if it is any other value value,
discard the frame. If the MH Channel Header MH flag is one,
indicating multi-hop, test that the TRILL Header hop count
received was not less than a configurable value that defaults to
0x30. If it is less, discard the frame. Failure to perform these
tests would make it easier to spoof BFD Control frames. However,
if forged BFD Control frames are a concern, then BFD
Authentication [RFC5880] should be used.

INTERNET-DRAFT BFD TRILL Encapsulation

4. TRILL BFD Echo Protocol

A TRILL BFD Echo frame is a unicast Rbridge RBridge Channel frame, as
specified in [TRILLChannel], [RFC7178], which should be forwarded back by an
immediate neighbor because both the ingress and egress nicknames are
set to a nickname of the originating RBridge. Normal TRILL Data
frame forwarding will cause the frame to be returned unless micro-
loop suppression logic in the neighbor RBrdge RBridge prohibits sending a
frame back out the port on which it was received or the like.
RBridges with such prohibitions cannot support BFD Echo. The TRILL
OAM protocol number for BFD Echo is given in Section 8.

TRILL BFD Echo frames SHOULD be sent on a link only if the following
conditions are met. An Echo originated originating under other circumstances
will consume bandwidth and CPU resources but is unlikely to be
returned.

- A TRILL BFD Control session has been established,

- TRILL BFD Echo support is indicated by the RBridge that would
potentially echo
responding RBridge, respond to the BFD Echo,

- The adjacency is in the Report state [RFC6327], [RFC7177], and

- The TRILL BFD Echo originating RBridge wishes to make use of this
optional feature.

Since the originating RBridge is the RBridge that will be processing
a returned Echo frame, the entire TRILL BFD Echo protocol specific protocol-specific
data area is considered opaque and left to the discretion of the
originating RBridge. Nevertheless, it is suggested that this data
include information by which the originating RBridge can authenticate
the returned BFD Echo frame and confirm the neighbor that echoed the
frame back. For example, it could include its own SystemID, System ID, the
neighbor's SystemID, System ID, a session identifier identifier, and a sequence count as
well as a Message Authentication Code.

4.1

4.1. BFD Echo Frame Processing

The following tests MUST be performed on returned TRILL BFD Echo
frames before other processing. The RBridge Channel document
[RFC7178] requires that the information in the TRILL Header be given
to the BFD protocol.

o Is the M-bit M bit in the TRILL Header non-zero? If so, discard the
frame. (Multi-destination BFD is a work in progress [MultiBFD].)

o The TRILL BFD Echo frame should have gone exactly two hops hops, so
test

INTERNET-DRAFT BFD TRILL Encapsulation that the TRILL Header hop count as received was 0x3E (i.e.,
0x3D if it has already been decremented) decremented), and if it is any other value
value, discard the frame. The Rbridge RBridge Channel Header in the frame
MUST have the MH bit equal to one one, and if it is zero, discard the frame is discarded.

INTERNET-DRAFT BFD TRILL Encapsulation
frame.

5. Management and Operations Considerations

The TRILL BFD parameters on an RBridge are configurable. The default
values are the same as in the IP BFD case [RFC5881], except where
specified in this document document, such as for Hop Count. hop count.

It is up to the operator of an RBridge campus to configure the rates
at which TRILL BFD frames are transmitted on a link to avoid
congestion (e.g., link, I/O, input/output (I/O), CPU) and false failure
detection. See also the discussion of congestion in Section 2 of
[RFC5881].

As stated in [RFC5880]:

It is worth noting that a single BFD session does not consume a
large amount of bandwidth. An aggressive session that achieves a
detection time of 50 milliseconds, by using a transmit interval of
16.7 milliseconds and a detect multiplier of 3, will generate 60
packets per second. The maximum length of each packet on the wire
is on the order of 100 bytes, for a total of around 48 kilobits
per second of bandwidth consumption in each direction.

INTERNET-DRAFT BFD TRILL Encapsulation

6. Default Authentication

Consistent with TRILL's goal of being able to operate with minimum
configuration, the default for BFD authentication between neighbor
RBridges is based on the state of the IS-IS shared secret
authentication for Hellos between those RBridges as detaled detailed below.
The BFD authentication algorithm and methods in this section MUST be
implemented at an RBridge if TRILL IS-IS authentication and BFD are
implemented at that RBrdge. RBridge. If such BFD authentication is configured
configured, then its configuration is not restricted by the
configuration of IS-
IS IS-IS security.

If IS-IS authentication is not in effect between neighbor RBridges RBridges,
then, by default, TRILL BFD between those RBridges is also unsecured.

If such IS-IS authentication is in effect effect, then, unless configured
otherwise, TRILL BFD Control frames sent between those RBridges MUST
use BFD Meticulous Keyed SHA1 authentication [RFC5880]. The BFD
authentication keys between neighbor RBridges by default are derived
from the IS-IS shared secret authentication keys for Hellos between
those RBridges as detailed below. However, such BFD authentication
keys MAY be configured to some other value.

HMAC-SHA256 ( ( "TRILL BFD Control" | originPortID | originSysID ),
IS-IS-shared-key )
In the above above, "|" indicates concatenation, concatenation; HMAC-SHA256 is as
described in [FIPS180] [RFC6234], and [RFC6234]; and "TRILL BFD Control" is the seventeen byte
17-byte US ASCII [ASCII] string indicated that is then concatenated
with the 2-byte Port ID of the originating port and the 6-bytes 6-byte IS-IS SystemID
System ID of the originating RBridge, the last two items being in
network byte order. The Port and System IDs are included to minimize
exposure of the same key to improve resistance to cryptanalysis.
IS-IS-shared-key is secret keying material being used for IS-IS
authentication on the link.

The use of the above derived key is accomplished by associating the
above default authentication type and key with the Key ID of the IS-
IS-shared key
IS-IS-shared-key used in the derivation and then using that Key ID in
the Authentication Section of the BFD Control frame OAM protocol protocol-
specific data. Also Also, Auth Type would be 5 5, and Auth Len would be 28
in the Authentication Section. RBridges MAY be configured to use
other BFD security modes or keying material or configured to use no
security.

Authentication for TRILL BFD Echo is a local implementation issue as
BFD Echo frames are authenticated by their sender when returned by by a
neighbor. However, if TRILL IS-IS and BFD Control are being
authenticated to a neighbor and BFD Echo is in use, BFD Echo frames
to be returned by that neighbor should be authenticated authenticated, and such

INTERNET-DRAFT BFD TRILL Encapsulation
authentication should use different keying material from other types
of authentication. For example, it could use keying material derived
as follows, where "|" indicates concatenation:

HMAC-SHA256 ( ( "TRILL BFD Echo" | originPortID | originSysID ),
IS-IS-shared-key )

INTERNET-DRAFT BFD TRILL Encapsulation

7. Security Considerations

BFD over TRILL utilizes the RBridge Channel extension to the TRILL
protocol and is generally analogous to BFD over IP. As such, the BFD
authentication faciliity facility is available to authenticate BFD over TRILL BFD-over-TRILL
packet payloads payloads, but no encryption or other security features are
provided at the BFD over TRILL BFD-over-TRILL level. See the following:

- [RFC5881] for general BFD security considerations,

- [TRILLChannel] [RFC7178] for general RBridge Channel security considerations, and

- [RFC6325] for general TRILL protocol security considerations.

Section 3.2 above describes seurity security concerns with multi-hop BFD Control
packets and failure to check the TRILL Header M bit in BFD Control
packets.

INTERNET-DRAFT BFD TRILL Encapsulation

8. IANA Considerations

IANA is requested to allocate has allocated two Rbridge RBridge Channel Protocol protocol numbers
[TRILLChannel] [RFC7178]
from the range allocated by Standards Actions, Action range, as follows:

Protocol Number
-------- ------
BFD Control TBD (2 suggested) 0x002
BFD Echo TBD (3 suggested) 0x003

9. Acknowledgements

The authors would like to specially thank Dave Katz, an author of
[RFC5880] and [RFC5881], from which some material herein has been
reproduced.

The following individuals are thanked for their comments and
suggestions: Scott Bradner, Stewart Bryant, Stephen Farrell, Eric
Gray, Brian Haberman, Barry Leiba, Erik Nordmark, John Scudder,
Robert Sparks, Martin Stiemerling, an and Sean Turner.

This documnt was prepared using raw nroff. All macros used were
defined in the source file.

INTERNET-DRAFT BFD TRILL Encapsulation

10. References

10.1. Normative References

[ASCII] - American National Standards Institute (formerly United
States of America Standards Institute), "USA Institute, "Coded Character
Set - 7-bit American Standard Code for Information
Interchange", ANSI X3.4-1968, 1968. ANSI X3.4-1968
has been replaced by newer versions with slight modifications,
but the 1968 version remains definitive for the Internet. X3.4, 1986.

[FIPS180] - "Secure Hash Standard (SHS)", United States of American, National Institute of Science and Technology, "Secure Hash
Standard (SHS)", Federal Information Processing Standard
(FIPS) 180-4, March 2012,
http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf <http://csrc.nist.gov/
publications/fips/fips180-4/fips-180-4.pdf>.

[IS-IS] - International Organization for Standardization,
"Intermediate system System to Intermediate system System intra-domain
routeing information exchange protocol for use in
conjunction with the
Protocol protocol for providing the Connectionless-mode NetworkService
connectionless-mode network service (ISO 8473)," ISO/IEC 10589:2002, 8473)", Second
Edition, Nov November 2002.

[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC5880] - Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010.

[RFC5881] - Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June
2010.

[RFC6213] - Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled TLV", RFC
6213, April 2011.

[RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, July 2011.

[RFC6327] - Eastlake,

[RFC7177] Eastlake 3rd, D., R. Perlman, A. R., Ghanwani, D. Dutt, A., Yang, H., and
V. Manral, "RBridges: "Transparent Interconnection of Lots of Links
(TRILL): Adjacency", RFC 6327, July 2011.

[TRILLChannel] - Eastlake, 7177, April 2014.

[RFC7178] Eastlake 3rd, D., V. Manral, Y. V., Li, S. Y., Aldrin, S., and D.
Ward,
"RBridges: RBridge "Transparent Interconnection of Lots of Links
(TRILL): Routing Bridge (RBridge) Channel Support in TRILL", draft-ietf-trill-
rbridge-channel, work in progress. Support", RFC
7178, April 2014.

10.2. Informative References

[802.1AX] - IEEE, "IEEE Standard for Local and metropolitan area
networks / -- Link Aggregation", IEEE Std 802.1AX-2008, 1
January 2008.

INTERNET-DRAFT BFD TRILL Encapsulation

[802.1Q] - IEEE 802.1, IEEE, "IEEE Standard for Local and metropolitan area
networks - -- Media Access Control (MAC) Bridges and Virtual
Bridged Local Area Networks", IEEE Std 802.1Q-2011, May August
2011.

[MultiBFD] - Katz, D. and D. Ward, "draft-ietf-bfd-multipoint", work "BFD for Multipoint Networks", Work
in progress. Progress, February 2014.

[RFC5082] - Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007.

[RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.

[RFC6291] - Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291, June 2011.

[RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent
Interconnection of Lots of Links (TRILL) Protocol Control
Protocol", RFC 6361, August 2011.

INTERNET-DRAFT BFD TRILL Encapsulation

Recent Changes Record

[RFC Editor Note: Please delete this section before publication.]

From -06 to -07:

1. Replace normative reference to RFC 20 with a refernce to [ASCII].

2. Update Author Address information.

3. In the default BFD authentication key derivation, change
"OriginatorMAC" to the concatenation of the Port ID and the
System ID. OriginatorMAC is simpler and shorter but only works
for Ethernet links. TRILL supports arbitrary technology links
between RBridges so you need to use the combination of Port ID

[RFC7173] Yong, L., Eastlake 3rd, D., Aldrin, S., and System ID to get a globally unique quantity. In addition, if
an IS-IS authentication method is in use the has a Key ID field
so that multiple shared secret keys may be in place, then by
default BFD authentication with such a Key ID field should also
be used with matching Key ID for matching derived key.

4. Clarify what it means that a single hop BFD control frame in
support of link connectivity is send at high priority for cases
other than Ethernet links.

5. Add reference in Section 5 to Section 2 J. Hudson,
"Transparent Interconnection of [RFC5881] in
conngection with congestion control.

6. Add mandatory to implement support for Demand Mode BFD.

7. Clarify that the BFD authentication algorithm and methods in
Section 6 MUST be implemented if TRILL IS-IS Authentication and
BFD are implemented.

8. Add some small pieces Lots of explanatory and motivational text that
make no technical changes, as suggested by the Operations
Directorate review.

9. Delete comparison between RBridge Channel and MPLS Generic
Associated Channel.

10. Update Author Info.

11. Various editorial changes.

INTERNET-DRAFT BFD TRILL Encapsulation Links (TRILL)
Transport Using Pseudowires", RFC 7173, April 2014.

Authors' Addresses

Vishwas Manral
Hewlett Packard Co.
19111 Pruneridge
Ionos Corp.
4100 Moorpark Ave.
Cupertino,
San Jose, CA 95089 95117
USA

Phone: +1-408-447-0000
Email: vishwas.manral@hp.com

EMail: vishwas@ionosnetworks.com

Donald Eastlake 3rd
Huawei R&D USA
155 Beaver Street
Milford, MA 01757
USA

Phone: +1-508-333-2270
Email:
EMail: d3e3e3@gmail.com

Dave Ward
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95138
USA

Email:

EMail: dward@cisco.com

Ayan Banerjee
Cumulus Networks
1089 West Evelyn Avenue
Sunnyvale, CA 94086
USA

EMail: ayabaner@gmail.com

INTERNET-DRAFT BFD TRILL Encapsulation

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
described in the Simplified BSD License. The definitive version of
an IETF Document is that published by, or under the auspices of, the
IETF. Versions of IETF Documents that are published by third parties,
including those that are translated into other languages, should not
be considered to be definitive versions of IETF Documents. The
definitive version of these Legal Provisions is that published by, or
under the auspices of, the IETF. Versions of these Legal Provisions
that are published by third parties, including those that are
translated into other languages, should not be considered to be
definitive versions of these Legal Provisions. For the avoidance of
doubt, each Contributor to the IETF Standards Process licenses each
Contribution that he or she makes as part of the IETF Standards
Process to the IETF Trust pursuant to the provisions of RFC 5378. No
language to the contrary, or terms, conditions or rights that differ
from or are inconsistent with the rights and licenses granted under
RFC 5378, shall have any effect and shall be null and void, whether
published or posted by such Contributor, or included with or in such
Contribution.