< draft-ietf-trill-smart-endnodes-10.txt   draft-ietf-trill-smart-endnodes-11.txt >
TRILL WG Radia Perlman TRILL WG Radia Perlman
Internet-Draft Dell EMC Internet-Draft Dell EMC
Intended status: Standards Track Fangwei Hu Intended status: Standards Track Fangwei Hu
Expires: September 2, 2018 ZTE Corporation Expires: September 12, 2018 ZTE Corporation
Donald Eastlake Donald Eastlake
Ting Liao Ting Liao
Huawei Technologies Huawei Technologies
Mar 1, 2018 Mar 11, 2018
TRILL Smart Endnodes TRILL Smart Endnodes
draft-ietf-trill-smart-endnodes-10.txt draft-ietf-trill-smart-endnodes-11.txt
Abstract Abstract
This draft addresses the problem of the size and freshness of the This draft addresses the problem of the size and freshness of the
endnode learning table in edge RBridges, by allowing endnodes to endnode learning table in edge RBridges, by allowing endnodes to
volunteer for endnode learning and encapsulation/decapsulation. Such volunteer for endnode learning and encapsulation/decapsulation. Such
an endnode is known as a "Smart Endnode". Only the attached edge an endnode is known as a "Smart Endnode". Only the attached edge
RBridge can distinguish a "Smart Endnode" from a "normal endnode". RBridge can distinguish a "Smart Endnode" from a "normal endnode".
The smart endnode uses the nickname of the attached edge RBridge, so The Smart Endnode uses the nickname of the attached edge RBridge, so
this solution does not consume extra nicknames. The solution also this solution does not consume extra nicknames. The solution also
enables Fine Grained Label aware endnodes. enables Fine Grained Label aware endnodes.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 September 2, 2018. This Internet-Draft will expire on September 12, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Smart-Hello Mechanism between Smart Endnode and RBridge . . . 5 4. Smart-Hello Mechanism between Smart Endnode and RBridge . . . 5
4.1. Smart-Hello Encapsulation . . . . . . . . . . . . . . . . 6 4.1. Smart-Hello Encapsulation . . . . . . . . . . . . . . . . 6
4.2. Edge RBridge's Smart-Hello . . . . . . . . . . . . . . . 7 4.2. Edge RBridge's Smart-Hello . . . . . . . . . . . . . . . 7
4.3. Smart Endnode's Smart-Hello . . . . . . . . . . . . . . . 7 4.3. Smart Endnode's Smart-Hello . . . . . . . . . . . . . . . 7
5. Data Packet Processing . . . . . . . . . . . . . . . . . . . 9 5. Data Packet Processing . . . . . . . . . . . . . . . . . . . 9
5.1. Data Packet Processing for Smart Endnode . . . . . . . . 9 5.1. Data Packet Processing for Smart Endnode . . . . . . . . 9
5.2. Data Packet Processing for Edge RBridge . . . . . . . . . 10 5.2. Data Packet Processing for Edge RBridge . . . . . . . . . 10
6. Multi-homing Scenario . . . . . . . . . . . . . . . . . . . . 11 6. Multi-homing Scenario . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Informative References . . . . . . . . . . . . . . . . . 13 10.1. Informative References . . . . . . . . . . . . . . . . . 13
10.2. Normative References . . . . . . . . . . . . . . . . . . 13 10.2. Normative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
The IETF TRILL (Transparent Interconnection of Lots of Links) The IETF TRILL (Transparent Interconnection of Lots of Links)
protocol [RFC6325] [RFC7780] provides optimal pair-wise data frame protocol [RFC6325] [RFC7780] provides optimal pair-wise data frame
forwarding without configuration, safe forwarding even during periods forwarding without configuration, safe forwarding even during periods
of temporary loops, and support for multipathing of both unicast and of temporary loops, and support for multipathing of both unicast and
multicast traffic. TRILL accomplishes this by using IS-IS [IS-IS] multicast traffic. TRILL accomplishes this by using IS-IS [IS-IS]
[RFC7176] link state routing and encapsulating traffic using a header [RFC7176] link state routing and encapsulating traffic using a header
that includes a hop count. Devices that implement TRILL are called that includes a hop count. Devices that implement TRILL are called
skipping to change at page 5, line 10 skipping to change at page 5, line 10
endnode entries. However, SE1 and SE2 might also determine, through endnode entries. However, SE1 and SE2 might also determine, through
ICMP messages or other techniques that an endnode entry is not ICMP messages or other techniques that an endnode entry is not
successfully reaching the destination endnode, and can be deleted, successfully reaching the destination endnode, and can be deleted,
even if the entry has not timed out. even if the entry has not timed out.
If SE1 wishes to correspond with destination MAC D, and no endnode If SE1 wishes to correspond with destination MAC D, and no endnode
entry exists, SE1 will encapsulate the packet as an unknown entry exists, SE1 will encapsulate the packet as an unknown
destination, or consulting a directory [RFC7067] (just as an RBridge destination, or consulting a directory [RFC7067] (just as an RBridge
would do if there was no endnode entry). would do if there was no endnode entry).
+----------+ +----------+
|SE1(Smart | |SE1(Smart |
|Endnode1) | \ +------------------------------+ |Endnode1) | \ +------------------------------+
+----------+ \ / \ +----------+ \ / \
\ /+------+ +------+ +-----+ \ +----------+ \ /+------+ +------+ +-----+ \ +-----------+
/-+-| RB 1 |---| RB2 |----| RB3 |-----+--| Endnode1 | /-+-| RB 1 |---| RB2 |----| RB3 |-----+--|Endnode3 |
/ | +------+ +------+ +-----+ | +----------+ / | +------+ +------+ +-----+ | |MAC=D |
+----------+ / \ / +----------+ / \ / +-----------+
|SE2(Smart | \ / |SE2(Smart | \ /
| Endnode2)| +------------------------------+ | Endnode2)| +------------------------------+
+----------+ +----------+
Figure 1 Smart Endnode Scenario Figure 1 Smart Endnode Scenario
The mechanism in this draft is that the Smart Endnode SE1 issues a The mechanism in this draft is that the Smart Endnode SE1 issues a
Smart-Hello, indicating SE1's desire to act as a Smart Endnode, Smart-Hello, indicating SE1's desire to act as a Smart Endnode,
together with the set of MAC addresses and Data Labels that SE1 owns. together with the set of MAC addresses and Data Labels that SE1 owns.
The Smart-Hello is used to announce the Smart Endnode capability and The Smart-Hello is used to announce the Smart Endnode capability and
parameters (such as MAC address, Data Label etc.). The Smart-Hello parameters (such as MAC address, Data Label etc.). The Smart-Hello
is a type of TRILL ES-IS PDU, which is specified in section 5 of is a type of TRILL ES-IS PDU, which is specified in section 5 of
[RFC8171]. The detailed content for a Smart Endnode's Smart-Hello is [RFC8171]. The detailed content for a Smart Endnode's Smart-Hello is
defined in section 4. defined in section 4.
skipping to change at page 6, line 16 skipping to change at page 6, line 16
Although a Smart Endnode is not an RBridge, does not send LSPs or Although a Smart Endnode is not an RBridge, does not send LSPs or
maintain a copy of the link state database, and does not perform maintain a copy of the link state database, and does not perform
routing calculations, it is required to have a "Hello" mechanism (1) routing calculations, it is required to have a "Hello" mechanism (1)
to announce to edge RBridges that it is a Smart Endnode and (2) to to announce to edge RBridges that it is a Smart Endnode and (2) to
tell them what MAC addresses it is handling in what Data Labels. tell them what MAC addresses it is handling in what Data Labels.
Similarly, an edge RBridge that supports Smart Endnodes needs a Similarly, an edge RBridge that supports Smart Endnodes needs a
message (1) to announce that support, (2) to inform Smart Endnodes message (1) to announce that support, (2) to inform Smart Endnodes
what nickname to use for ingress and what nickname(s) can be used as what nickname to use for ingress and what nickname(s) can be used as
egress nickname in a multi-destination TRILL Data packet, and (3) the egress nickname in a multi-destination TRILL Data packet, and (3) the
list of smart end nodes it knows about on that link. list of Smart Endnodes it knows about on that link.
The messages sent by Smart Endnodes and by edge RBridges that support The messages sent by Smart Endnodes and by edge RBridges that support
Smart Endnodes are called "Smart-Hellos". The Smart-Hello is a type Smart Endnodes are called "Smart-Hellos". The Smart-Hello is a type
of TRILL ES-IS PDU, which is specified in [RFC8171]. of TRILL ES-IS PDU, which is specified in [RFC8171].
The Smart-Hello Payload, both for Smart-Hellos sent by Smart Endnodes The Smart-Hello Payload, both for Smart-Hellos sent by Smart Endnodes
and for Smart-Hellos sent by Edge RBridges, consists of TRILL IS-IS and for Smart-Hellos sent by Edge RBridges, consists of TRILL IS-IS
TLVs as described in the following two sub-sections. The non- TLVs as described in the following two sub-sections. The non-
extended format is used so TLVs, sub-TLVs, and APPsub-TLVs have an extended format is used so TLVs, sub-TLVs, and APPsub-TLVs have an
8-bit size and type field. Both types of Smart-Hellos MUST include a 8-bit size and type field. Both types of Smart-Hellos MUST include a
skipping to change at page 6, line 41 skipping to change at page 6, line 41
+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Holding Time | (2 bytes) | Holding Time | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (2 bytes) | Flags | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Smart Parameters APPsub-TLV Figure 2 Smart Parameters APPsub-TLV
Type: APPsub-TLV type Smart-Parameters, value is TBD1. o Type: APPsub-TLV type Smart-Parameters, value is TBD1.
Length: 4. o Length: 4.
Holding Time: A time in seconds as an unsigned integer. It has o Holding Time: A time in seconds as an unsigned integer. It has the
the same meaning as the Holding Time field in IS-IS Hellos [IS-IS] same meaning as the Holding Time field in IS-IS Hellos [IS-IS]. A
. A Smart Endnode and an Edge RBridge supporting Smart Endnodes Smart Endnode and an Edge RBridge supporting Smart Endnodes MUST send
MUST send a Smart-Hello at least three times during their Holding a Smart-Hello at least three times during their Holding Time. If no
Time. If no Smart-Hellos is received from a Smart Endnode or Edge Smart-Hellos is received from a Smart Endnode or Edge RBridge within
RBridge within the most recent Holding Time it sent, it is assumed the most recent Holding Time it sent, it is assumed that it is no
that it is no longer available. longer available.
Flags: At this time all of the Flags are reserved and MUST be send o Flags: At this time all of the Flags are reserved and MUST be send
as zero and ignored on receipt. as zero and ignored on receipt.
If more than one Smart Parameters APPsub-TLV appears in a Smart- If more than one Smart Parameters APPsub-TLV appears in a Smart-
Hello, the first one is used and any following ones are ignored. If Hello, the first one is used and any following ones are ignored. If
no Smart Parameters APPsub-TLV appears in a Smart-Hello, that Smart- no Smart Parameters APPsub-TLV appears in a Smart-Hello, that Smart-
Hello is ignored. Hello is ignored.
4.2. Edge RBridge's Smart-Hello 4.2. Edge RBridge's Smart-Hello
The edge RBridge's Smart-Hello contains the following information in The edge RBridge's Smart-Hello contains the following information in
addition to the Smart-Parameters APPsub-TLV: addition to the Smart-Parameters APPsub-TLV:
o RBridge's nickname. The nickname sub-TLV, specified in section o RBridge's nickname. The nickname sub-TLV, specified in section
2.3.2 in [RFC7176], is reused here carried inside a TLV 242 (IS-IS 2.3.2 in [RFC7176], is reused here carried inside a TLV 242 (IS-IS
router capability) in a Smart-Hello frame. If more than one router capability) in a Smart-Hello frame. If more than one nickname
nickname appears in the Smart-Hello, the first one is used and the appears in the Smart-Hello, the first one is used and the following
following ones are ignored. ones are ignored.
o Trees that RB1 can use when ingressing multi-destination frames. o Trees that RB1 can use when ingressing multi-destination frames.
The Tree Identifiers Sub-TLV, specified in section 2.3.4 in The Tree Identifiers Sub-TLV, specified in section 2.3.4 in
[RFC7176], is reused here. [RFC7176], is reused here.
o Smart Endnode neighbor list. The TRILL Neighbor TLV, specified in o Smart Endnode neighbor list. The TRILL Neighbor TLV, specified in
section 2.5 in [RFC7176], is reused for this purpose. section 2.5 in [RFC7176], is reused for this purpose.
o An Authentication TLV MAY also be included. An Authentication TLV MAY also be included.
4.3. Smart Endnode's Smart-Hello 4.3. Smart Endnode's Smart-Hello
A new APPsub-TLV (Smart-MAC TLV) is defined for use by Smart Endnodes A new APPsub-TLV (Smart-MAC TLV) is defined for use by Smart Endnodes
as defined below. In addition, there will be a Smart-Parameters as defined below. In addition, there will be a Smart-Parameters
APPsub-TLV and there MAY be an Authentication TLV in a Smart Endnode APPsub-TLV and there MAY be an Authentication TLV in a Smart Endnode
Smart-Hello. Smart-Hello.
If there are several VLANs/FGL Data Labels for that Smart Endnode, If there are several VLANs/FGL Data Labels for that Smart Endnode,
the Smart-MAC APPsub-TLV is included several times in Smart Endnode's the Smart-MAC APPsub-TLV is included several times in Smart Endnode's
Smart-Hello. This APPsub-TLV appears inside a TRILL GENINFO TLV. Smart-Hello. This APPsub-TLV appears inside a TRILL GENINFO TLV.
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type=Smart-MAC | (1 byte) |Type=Smart-MAC | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|M|RSV| VLAN/FGL Data Label | (4 bytes) |F|M| RSV | VLAN/FGL Data Label | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (1) (6 bytes) | | MAC (1) (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. | | ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (N) (6 bytes) | | MAC (N) (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Smart-MAC APPsub-TLV Figure 3 Smart-MAC APPsub-TLV
o Type: TRILL APPsub-TLV Type Smart-MAC, value is TBD2. o Type: TRILL APPsub-TLV Type Smart-MAC, value is TBD2.
o Length: Total number of bytes contained in the value field of the o Length: Total number of bytes contained in the value field of the
TLV, that is, the sum of the length of the F/RSV/Data Label fields TLV, that is, the sum of the length of the F/M/RSV/FGL Data Label
and 6 times the number of MAC addresses present. So, if there are fields and 6 times the number of MAC addresses present. So, if there
n MAC addresses, this is 4+6*n. are n MAC addresses, this is 4+6*n.
o F: 1 bit. If it is set to 1, it indicates that the endnode o F: 1 bit. If it is set to 1, it indicates that the endnode
supports FGL data labels [RFC7172], and that this Smart-MAC supports FGL data labels [RFC7172], and that this Smart-MAC APPsub-
APPsub-TLV has an FGL in the following VLAN/FGL field. Otherwise, TLV has an FGL in the following VLAN/FGL field. Otherwise, the VLAN/
the VLAN/FGL Data Label field is a VLAN ID.(See below for the FGL Data Label field is a VLAN ID.(See below for the format of the
format of the VLAN/FGL Data Label field). VLAN/FGL Data Label field).
o M: 1 bit. If it is set to 1, it indicates multi-homing(See o M: 1 bit. If it is set to 1, it indicates multi-homing(See
Section 6). If it is set to 0, it indicates that the smart- Section 6). If it is set to 0, it indicates that the Smart Endnodes
endnodes are not using multi-homing. are not using multi-homing.
o RSV: 6 bits, is reserved for the future use. o RSV: 6 bits, is reserved for the future use.
o VLAN/FGL Data Label: 24bits. If F is 1, this field is a 24-bit o VLAN/FGL Data Label: 24bits. If F is 1, this field is a 24-bit FGL
FGL Data Label for all subsequent MAC addresses in this APPsub- Data Label for all subsequent MAC addresses in this APPsub-TLV.
TLV. Otherwise, if F is 0, the lower 12 bits is the VLAN of all Otherwise, if F is 0, the lower 12 bits is the VLAN of all subsequent
subsequent MAC addresses in this APPsub-TLV, and the upper 12 bits MAC addresses in this APPsub-TLV, and the upper 12 bits is not
is not used(sent as zero and ignored on receipt). If there is no used(sent as zero and ignored on receipt). If there is no VLAN/FGL
VLAN/FGL data label specified, the VLAN/FGL Data Label is zero. data label specified, the VLAN/FGL Data Label is zero.
o MAC(i): This is a 48-bit MAC address reachable in the Data Label o MAC(i): This is a 48-bit MAC address reachable in the Data Label
given from the Smart Endnode that is announcing this APPsub-TLV. sent by the Smart Endnode that is announcing this APPsub-TLV.
5. Data Packet Processing 5. Data Packet Processing
The subsections below specify Smart Endnode data packet processing. The subsections below specify Smart Endnode data packet processing.
All TRILL Data packets sent to or from Smart Endnodes are sent in the All TRILL Data packets sent to or from Smart Endnodes are sent in the
Designated VLAN [RFC6325] of the local link but do not necessarily Designated VLAN [RFC6325] of the local link but do not necessarily
have to be VLAN tagged. have to be VLAN tagged.
5.1. Data Packet Processing for Smart Endnode 5.1. Data Packet Processing for Smart Endnode
A Smart Endnode does not issue or receive LSPs or E-L1FS FS-LSPs or A Smart Endnode does not issue or receive LSPs or E-L1FS FS-LSPs or
calculate topology. It does the following: calculate topology. It does the following:
o Smart Endnode maintains an endnode table of (the MAC address of o A Smart Endnode maintains an endnode table of (the MAC address of
remote endnode, Data Label, the nickname of the edge RBridge's remote endnode, Data Label, the nickname of the edge RBridge's
attached) entries of end nodes with which the Smart Endnode is attached) entries of end nodes with which the Smart Endnode is
communicating. Entries in this table are populated the same way communicating. Entries in this table are populated the same way
that an edge RBridge populates the entries in its table: that an edge RBridge populates the entries in its table:
* learning from (source MAC address ingress nickname) on packets * learning from (source MAC address ingress nickname) on packets
it decapsulates. it decapsulates.
* by querying a directory [RFC7067]. * by querying a directory [RFC7067].
skipping to change at page 9, line 40 skipping to change at page 9, line 40
o When Smart Endnode SE1 wishes to send unicast frame to remote node o When Smart Endnode SE1 wishes to send unicast frame to remote node
D, if (MAC address of remote endnode D, Data Label, nickname) D, if (MAC address of remote endnode D, Data Label, nickname)
entry is in SE1's endnode table, SE1 encapsulates the ingress entry is in SE1's endnode table, SE1 encapsulates the ingress
nickname as the nickname of the RBridge(RB1), egress nickname as nickname as the nickname of the RBridge(RB1), egress nickname as
indicated in D's table entry. If D is unknown, SE1 either queries indicated in D's table entry. If D is unknown, SE1 either queries
a directory or encapsulates the packet as a multi-destination a directory or encapsulates the packet as a multi-destination
frame, using one of the trees that RB1 has specified in RB1's frame, using one of the trees that RB1 has specified in RB1's
Smart-Hello. The mechanism for querying a directory is given in Smart-Hello. The mechanism for querying a directory is given in
[RFC8171]. [RFC8171].
o When SE1 wishes to send a multi-destination (multicast, unknown o When SE1 wishes to send a BUM packet to the TRILL campus, SE1
unicast, or broadcast) to the TRILL campus, SE1 encapsulates the encapsulates the packet using one of the trees that RB1 has
packet using one of the trees that RB1 has specified. specified.
If the Smart Endnode SE1 sends a multi-destination TRILL Data packet, If the Smart Endnode SE1 sends a multi-destination TRILL Data packet,
the destination MAC of the outer Ethernet is the All-RBridges the destination MAC of the outer Ethernet is the All-RBridges
multicast address. multicast address.
The Smart Endnode SE1 need not send Smart-Hellos as frequently as The Smart Endnode SE1 need not send Smart-Hellos as frequently as
normal RBridges. These Smart-Hellos could be periodically unicast to normal RBridges. These Smart-Hellos could be periodically unicast to
the Appointed Forwarder RB1. In case RB1 crashes and restarts, or the Appointed Forwarder RB1. In case RB1 crashes and restarts, or
the DRB changes and SE1 receives the Smart-Hello without mentioning the DRB changes and SE1 receives the Smart-Hello without mentioning
SE1, SE1 SHOULD send a Smart-Hello immediately. If RB1 is Appointed SE1, SE1 SHOULD send a Smart-Hello immediately. If RB1 is Appointed
skipping to change at page 10, line 15 skipping to change at page 10, line 15
its Smart-Hellos as a Smart Endnode neighbor. its Smart-Hellos as a Smart Endnode neighbor.
5.2. Data Packet Processing for Edge RBridge 5.2. Data Packet Processing for Edge RBridge
The attached edge RBridge processes and forwards TRILL Data packets The attached edge RBridge processes and forwards TRILL Data packets
based on the endnode property rather than for encapsulation and based on the endnode property rather than for encapsulation and
forwarding the native frames the same way as the traditional forwarding the native frames the same way as the traditional
RBridges. There are several situations for the edge RBridges as RBridges. There are several situations for the edge RBridges as
follows: follows:
o If receiving an encapsulated unicast TRILL Data packet from a port o If receiving an encapsulated unicast TRILL Data packet from a port
with a Smart Endnode, with RB1's nickname as ingress, the edge with a Smart Endnode, with RB1's nickname as ingress, the edge
RBridge RB1 forwards the frame to the specified egress nickname, RBridge RB1 forwards the frame to the specified egress nickname, as
as with any encapsulated frame. However, RB1 MAY filter the with any encapsulated frame. However, RB1 SHOULD filter the
encapsulation frame based on the inner source MAC and Data Label encapsulation frame based on the inner source MAC and Data Label as
as specified for the Smart Endnode. If the MAC (or Data Label) specified for the Smart Endnode. If the MAC (or Data Label) are not
are not among the expected entries of the Smart Endnode, the frame among the expected entries of the Smart Endnode, the frame would be
would be dropped by the edge RBridge. dropped by the edge RBridge. If the edge RBridge does not perform
this check, it makes it easier for a rogue end station to inject
bogus TRILL Data packets into the TRILL campus.
o If receiving a unicast TRILL Data packet with RB1's nickname as o If receiving a unicast TRILL Data packet with RB1's nickname as
egress from the TRILL campus, and the destination MAC address in egress from the TRILL campus, and the destination MAC address in the
the enclosed packet is a MAC address that has been listed by a enclosed packet is a MAC address that has been listed by a "Smart
"Smart Endnode", RB1 leaves the packet encapsulated to that Smart Endnode", RB1 leaves the packet encapsulated to that Smart Endnode.
Endnode. The outer Ethernet destination MAC is the destination The outer Ethernet destination MAC is the destination Smart Endnode's
Smart Endnode's MAC address, the inner destination MAC address is MAC address, the inner destination MAC address is either the Smart
either the Smart Endnode's MAC address or some other MAC address Endnode's MAC address or some other MAC address that the Smart
that the Smart Endnode advertised in its Smart Hello, and the Endnode advertised in its Smart Hello, and the outer Ethernet source
outer Ethernet source MAC address is the RB1's port MAC address. MAC address is the RB1's port MAC address. The edge RBridge still
The edge RBridge still decreases the Hop count value by 1, for decreases the Hop count value by 1, for there is one hop between the
there is one hop between the RB1 and Smart Endnode. RB1 and Smart Endnode.
o If receiving a multi-destination TRILL Data packet from a port o If receiving a multi-destination TRILL Data packet from a port with
with a Smart Endnode, RBridge RB1 forwards the TRILL encapsulation a Smart Endnode, RBridge RB1 forwards the TRILL encapsulation to the
to the TRILL campus based on the distribution tree indicated by TRILL campus based on the distribution tree indicated by the egress
the egress nickname. If the egress nickname does not correspond nickname. If the egress nickname does not correspond to a
to a distribution tree, the packet is discarded. If there are any distribution tree, the packet is discarded. If there are any normal
normal endnodes (i.e, non-Smart Endnodes) attached to the edge endnodes (i.e, non-Smart Endnodes) attached to the edge RBridge RB1,
RBridge RB1, RB1 decapsulates the frame and sends the native frame RB1 decapsulates the frame and sends the native frame to these ports
to these ports possibly pruned based on multicast listeners, in possibly pruned based on multicast listeners, in addition to
addition to forwarding the multi-destination TRILL frame to the forwarding the multi-destination TRILL frame to the rest of the
rest of the campus. campus.
o If RB1 receives a native multi-destination data frame, which is o If RB1 receives a native multi-destination data frame, which is
sent by a non-smart endnode, from a port, including hybrid sent by a non-Smart Endnode, from a port, including hybrid endnodes
endnodes (Smart Endnodes and non-Smart Endnodes), RB1 will (Smart Endnodes and non-Smart Endnodes), RB1 will encapsulate it as
encapsulate it as multi-destination TRILL Data packet , and send multi-destination TRILL Data packet , and send the encapsulated
the encapsulated multi-destination TRILL Data Packet out that same multi-destination TRILL Data Packet out that same port to the Smart
port to the smart endnodes attached to the port, and also send the Endnodes attached to the port, and also send the encapsulated multi-
encapsulated multi-destination TRILL Data Packet to the TRILL destination TRILL Data Packet to the TRILL campus through other
campus through other ports . ports.
o If RB1 receives a multi-destination TRILL Data packet from a o If RB1 receives a multi-destination TRILL Data packet from a remote
remote RBridge, and the exit port includes hybrid endnodes(Smart RBridge, and the exit port includes hybrid endnodes(Smart Endnodes
Endnodes and non-Smart Endnodes), it sends two copies of multicast and non-Smart Endnodes), it sends two copies of multicast frames out
frames out the port, one as native and the other as TRILL the port, one as native and the other as TRILL encapsulated frame.
encapsulated frame. When Smart Endnode receives multi-destination When Smart Endnode receives multi-destination TRILL Data packet, it
TRILL Data packet, it learns the remote (MAC address, Data Label, learns the remote (MAC address, Data Label, Nickname) entry. A Smart
Nickname) entry. A Smart Endnodes ignores native data frames. A Endnodes ignores native data frames. A normal (non-Smart) Endnode
normal (non-smart) endnode receives the native frame and learns receives the native frame and learns the remote MAC address and
the remote MAC address and ignores the TRILL data packet. This ignores the TRILL data packet. This transit solution may bring some
transit solution may bring some complexity for the edge RBridge complexity for the edge RBridge and waste network bandwidth resource,
and waste network bandwidth resource, so avoiding the hybrid so avoiding the hybrid endnodes scenario by attaching the Smart
endnodes scenario by attaching the Smart Endnodes and non-Smart Endnodes and non-Smart Endnodes to different ports is RECOMMENDED.
Endnodes to different ports is RECOMMENDED.
6. Multi-homing Scenario 6. Multi-homing Scenario
Multi-homing is a common scenario for the Smart Endnode. The Smart Multi-homing is a common scenario for the Smart Endnode. The Smart
Endnode is on a link attached to the TRILL domain in two places: to Endnode is on a link attached to the TRILL domain in two places: to
edge RBridge RB1 and RB2. Take the figure below as example. The edge RBridge RB1 and RB2. Take the figure below as example. The
Smart Endnode SE1 is attached to the TRILL domain by RB1 and RB2 Smart Endnode SE1 is attached to the TRILL domain by RB1 and RB2
separately. Both RB1 and RB2 could announce their nicknames to SE1. separately. Both RB1 and RB2 could announce their nicknames to SE1.
. ..................... . .....................
skipping to change at page 12, line 19 skipping to change at page 12, line 20
set, the endnode entries (SE1's MAC address, label, RB1's nickname) set, the endnode entries (SE1's MAC address, label, RB1's nickname)
and (SE1's MAC address, label, RB2's nickname) will coexist as and (SE1's MAC address, label, RB2's nickname) will coexist as
endnode entries in the remote RBridge. (An alternative solution endnode entries in the remote RBridge. (An alternative solution
would be to use the ESADI protocol to distribute multiple attachments would be to use the ESADI protocol to distribute multiple attachments
of a MAC address of a multi-homing group, The ESADI is deployed among of a MAC address of a multi-homing group, The ESADI is deployed among
the edge RBridges (See section 5.3 of [RFC7357])). the edge RBridges (See section 5.3 of [RFC7357])).
7. Security Considerations 7. Security Considerations
Smart-Hellos can be secured by using Authentication TLVs based on Smart-Hellos can be secured by using Authentication TLVs based on
[RFC5310]. [RFC5310]. If they are not secured, then it is easier for a rogue
end station that does not posses the required keying material to be
falsely recognized as a valid Smart Endnode.
For general TRILL Security Considerations, see [RFC6325]. For general TRILL Security Considerations, see [RFC6325]. As stated
there, since end stations are connected to edge RBridge ports by
Ethernet, those ports MAY require end stations to authenticate
themselves using [IEEE802.1X] and authenticate and encrypt traffic
to/from the RBridge port with [IEEE802.1AE].
If they misbehave, Smart Endnodes can forge arbitrary ingress and
egress nicknames in the TRILL Headers of the TRILL Data packets they
construct. Decapsulating at egress RBridges or remote Smart Endnodes
that believe such a forged ingress nickname would send future traffic
destined for the inner source MAC address of the TRILL Data frame to
the wrong edge RBridge if data plane learning is in use. Because of
this, an RBridge port should not be configured to support Smart
Endnodes unless the end stations on that link are trusted or can be
adequately authenticated.
As with any end station, Smart Endnodes can forge the outer MAC
addresses of packets they send (See Section 6 of [RFC6325].) Because
they encapsulate TRILL Data packets, they can also forge inner MAC
addresses. The encapsulation performed by Smart Endnodes also means
they can send data in any Data Label which means they must be trusted
in order to enforce a security policy based on Data Labels.
The TRILL-Hello is a type of TRILL ES-IS, and is defined in The TRILL-Hello is a type of TRILL ES-IS, and is defined in
[RFC8171]. Receiving and processing TRILL-Hello for RBridges and [RFC8171]. Receiving and processing TRILL-Hello for RBridges and
Smart Endnodes would not bring more security and vulnerability issues Smart Endnodes would not bring more security and vulnerability issues
than the TRILL ES-IS security defined in [RFC8171]. than the TRILL ES-IS security defined in [RFC8171].
For added security against the compromise of data due to its mis-
delivery for any reason, including the above, end-to-end encryption
and authentication should be considered; that is, encryption and
authentication from source end station to destination end station.
The mechanism described in this document requires Smart Endnodes to
be aware of the MAC address(es) of the TRILL edge RBridge(s) to which
they are attached and the egress RBridge nickname from which the
destination of the packets is reachable. With that information,
Smart Endnodes can learn a substantial amount about the topology of
the TRILL domain. Therefore, there could be a potential security
risk when the Smart Endnodes are not trusted or are compromised.
8. IANA Considerations 8. IANA Considerations
IANA is requested to allocate APPsub-TLV type numbers for the Smart- IANA is requested to allocate APPsub-TLV type numbers for the Smart-
MAC and Smart-Parameters APPsub-TLVs from the range below 256 and MAC and Smart-Parameters APPsub-TLVs from the range below 256 and
update the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application update the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application
Identifier 1" registry as follows. Identifier 1" registry as follows.
+-----------+-------------------+------------------+ +-----------+-------------------+------------------+
| Protocol | Description | Reference | | Protocol | Description | Reference |
+-----------+-------------------+------------------+ +-----------+-------------------+------------------+
skipping to change at page 13, line 9 skipping to change at page 13, line 44
9. Acknowledgements 9. Acknowledgements
The contributions of the following persons are gratefully The contributions of the following persons are gratefully
acknowledged: Mingui Zhang, Weiguo Hao, Linda Dunbar, Kesava Vijaya acknowledged: Mingui Zhang, Weiguo Hao, Linda Dunbar, Kesava Vijaya
Krupakaran and Andrew Qu. Krupakaran and Andrew Qu.
10. References 10. References
10.1. Informative References 10.1. Informative References
[IEEE802.1AE]
"IEEE Standard for Local and metropolitan area networks--
Media Access Control (MAC) Security.", 2006.
[IEEE802.1X]
"IEEE Standard for Local and metropolitan area networks--
Port-Based Network Access Control", 2010.
[RFC7067] Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. [RFC7067] Dunbar, L., Eastlake 3rd, D., Perlman, R., and I.
Gashinsky, "Directory Assistance Problem and High-Level Gashinsky, "Directory Assistance Problem and High-Level
Design Proposal", RFC 7067, DOI 10.17487/RFC7067, November Design Proposal", RFC 7067, DOI 10.17487/RFC7067, November
2013, <https://www.rfc-editor.org/info/rfc7067>. 2013, <https://www.rfc-editor.org/info/rfc7067>.
[RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, [RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai,
"Problem Statement and Goals for Active-Active Connection "Problem Statement and Goals for Active-Active Connection
at the Transparent Interconnection of Lots of Links at the Transparent Interconnection of Lots of Links
(TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379, October (TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379, October
2014, <https://www.rfc-editor.org/info/rfc7379>. 2014, <https://www.rfc-editor.org/info/rfc7379>.
 End of changes. 37 change blocks. 
126 lines changed or deleted 171 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/