rfc8383v1.xml   rfc8383.xml 
skipping to change at line 60 skipping to change at line 60
<street>Bengaluru, Karnataka 560087</street> <street>Bengaluru, Karnataka 560087</street>
<street>India</street> <street>India</street>
</postal> </postal>
<email>mohammed.umair2@gmail.com</email> <email>mohammed.umair2@gmail.com</email>
</address> </address>
</author> </author>
<date month="May" year="2018"/> <date month="May" year="2018"/>
<workgroup>TRILL Working Group</workgroup> <workgroup>TRILL Working Group</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
<keyword>example</keyword>
<abstract> <abstract>
<t> The TRILL (Transparent Interconnection of Lots <t> The TRILL (Transparent Interconnection of Lots
of Links) protocol, by default, learns end station addresses of Links) protocol, by default, learns end station addresses
from observing the data plane. In particular, it learns local from observing the data plane. In particular, it learns local
Media Access Control (MAC) addresses and the edge switch port of Media Access Control (MAC) addresses and the edge switch port of
attachment from the receipt of local data frames and learns attachment from the receipt of local data frames and learns
remote MAC addresses and the edge switch port of attachment from the remote MAC addresses and the edge switch port of attachment from the
decapsulation of remotely sourced TRILL Data packets.</t> decapsulation of remotely sourced TRILL Data packets.</t>
<t> <t>
This document specifies a message by which a TRILL switch can This document specifies a message by which a TRILL switch can
explicitly request other TRILL switches to flush certain MAC explicitly request other TRILL switches to flush certain MAC
reachability learned through the decapsulation of TRILL Data packets. reachability learned through the decapsulation of TRILL Data packets.
This is a supplement to the TRILL automatic address forgetting (see Section 4.8.3 of <xref target="RFC6325"/>) and
<!--[rfced] To what does "the TRILL automatic address forgetting" refer? Will the reader understand this phrase?
Original:
This is a supplement to the TRILL automatic address forgetting and
can assist in achieving more rapid convergence in case of topology or
configuration change.
This is a supplement to the TRILL automatic address forgetting and
can assist in achieving more rapid convergence in case of topology or can assist in achieving more rapid convergence in case of topology or
configuration change.</t> configuration change.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction" anchor="section-1"><t> <section title="Introduction" anchor="section-1"><t>
By default, edge TRILL (Transparent Interconnection of Lots of Links) switches By default, edge TRILL (Transparent Interconnection of Lots of Links) switches
<xref target="RFC6325"/> <xref target="RFC7780"/>, also called edge Routing Bridges (RBridges), learn end <xref target="RFC6325"/> <xref target="RFC7780"/>, also called edge Routing Bridges (RBridges), learn end
skipping to change at line 120 skipping to change at line 105
changes; however, there are circumstances under which it would be changes; however, there are circumstances under which it would be
helpful for a TRILL switch to be able to explicitly flush (purge) helpful for a TRILL switch to be able to explicitly flush (purge)
certain learned end station reachability information in remote certain learned end station reachability information in remote
RBridges to achieve more-rapid convergence. Section 6.2 of <xref target="RFC4762"/> RBridges to achieve more-rapid convergence. Section 6.2 of <xref target="RFC4762"/>
is an example of the use of such a mechanism.</t> is an example of the use of such a mechanism.</t>
<t> <t>
Another example, based on Appendix A.3 of <xref target="RFC6325"/> ("Wiring Closet Topology"), presents a bridged LAN connected to a TRILL network via Another example, based on Appendix A.3 of <xref target="RFC6325"/> ("Wiring Closet Topology"), presents a bridged LAN connected to a TRILL network via
multiple RBridge ports. For optimum paths, Appendix A.3.3 suggests multiple RBridge ports. For optimum paths, Appendix A.3.3 suggests
configuring the RBridge ports to be like one Spanning Tree Protocol configuring the RBridge ports to be like one Spanning Tree Protocol
(STP) tree root in the bridged LAN. The address flush message in this (STP) tree root in the bridged LAN. The Address Flush message in this
document could also be triggered in this case when one of the edge document could also be triggered in this case when one of the edge
RBridges receives Topology Change (TC) information (e.g., TC RBridges receives Topology Change (TC) information (e.g., TC
in STP, Topology Change Notification (TCN) in Multiple in STP, Topology Change Notification (TCN) in Multiple
Spanning Tree Protocol (MSTP) in order to rapidly flush the MAC addresses Spanning Tree Protocol (MSTP) in order to rapidly flush the MAC addresses
for specific VLANs learned at the other edge RBridge ports.</t> for specific VLANs learned at the other edge RBridge ports.</t>
<t> <t>
A TRILL switch can easily flush any locally learned addresses it A TRILL switch can easily flush any locally learned addresses it
wants. This document specifies an RBridge Channel Support protocol <xref wants. This document specifies an RBridge Channel Support protocol <xref
target="RFC7178"/> message to request flushing address information target="RFC7178"/> message to request flushing address information
skipping to change at line 159 skipping to change at line 144
<t hangText="Edge TRILL Switch:">A TRILL switch attached to one or more links that provide end station service <t hangText="Edge TRILL Switch:">A TRILL switch attached to one or more links that provide end station service
</t> </t>
<t hangText="FCS:">Frame Check Sequence</t> <t hangText="FCS:">Frame Check Sequence</t>
<t hangText="FGL:">Fine-Grained Label <xref target="RFC7172"/></t> <t hangText="FGL:">Fine-Grained Label <xref target="RFC7172"/></t>
<t hangText="Management VLAN:"> A VLAN in which all TRILL switches in a campus <t hangText="Management VLAN:"> A VLAN in which all TRILL switches in a campus
indicate interest so that multi-destination TRILL Data packets, indicate interest so that multi-destination TRILL Data packets,
including RBridge Channel messages <xref target="RFC7978"/>, sent with that including RBridge Channel protocol messages <xref target="RFC7978"/>, sent with that
VLAN as the Inner.VLAN will be delivered to all TRILL switches VLAN as the Inner.VLAN will be delivered to all TRILL switches
in the campus. Usually, no end station service is offered in the in the campus. Usually, no end station service is offered in the
Management VLAN. Management VLAN.
</t> </t>
<t hangText="MAC:">Media Access Control</t> <t hangText="MAC:">Media Access Control</t>
<t hangText="RBridge:">An alternative name for a TRILL switch</t> <t hangText="RBridge:">An alternative name for a TRILL switch</t>
<t hangText="STP:">Spanning Tree Protocol</t> <t hangText="STP:">Spanning Tree Protocol</t>
skipping to change at line 194 skipping to change at line 179
</section> </section>
<section title="Address Flush Message Details" anchor="section-2"><t> <section title="Address Flush Message Details" anchor="section-2"><t>
The Address Flush message is an RBridge Channel protocol message The Address Flush message is an RBridge Channel protocol message
<xref target="RFC7178"/>.</t> <xref target="RFC7178"/>.</t>
<t> <t>
The general structure of an RBridge Channel packet on a link between The general structure of an RBridge Channel packet on a link between
TRILL switches is shown in <xref target="ref-rbridge-channel-protocol-message-structure"/>. The Protocol field in the TRILL switches is shown in <xref target="ref-rbridge-channel-protocol-message-structure"/>. The Protocol field in the
RBridge Channel Header gives the type of RBridge Channel packet and RBridge Channel Header gives the type of RBridge Channel packet and
indicates how to interpret the Channel Protocol Specific Payload indicates how to interpret the Channel-Protocol-Specific Payload
<!--[rfced] RFC 7178 does not use the specific term "Channel Protocol Specific Payload". We note that RFC-to-be 8381 updated to use "Channel-Protocol-Specific Payload". Please review the use of this term in this document and the other two and let us know if updates should be made.
<xref target="RFC7178"/>. <xref target="RFC7178"/>.
</t> </t>
<!--[rfced] We note that the content of Figure 1 is an exact replica
of Figure 1 in RFC-to-be 8381. Only the titles are different.
Please confirm that this is intentional and no updates should be
made.
RFC 8381:
RBridge Channel Packet Structure
This document:
RBridge Channel Protocol Message Structure
<figure title="RBridge Channel Protocol Message Structure" anchor="ref-rbridge-channel-protocol-message-structure"><artwork><![CDATA[ <figure title="RBridge Channel Protocol Message Structure" anchor="ref-rbridge-channel-protocol-message-structure"><artwork><![CDATA[
+-----------------------------------+ +-----------------------------------+
| Link Header | | Link Header |
+-----------------------------------+ +-----------------------------------+
| TRILL Header | | TRILL Header |
+-----------------------------------+ +-----------------------------------+
| Inner Ethernet Addresses | | Inner Ethernet Addresses |
+-----------------------------------+ +-----------------------------------+
| Data Label (VLAN or FGL) | | Data Label (VLAN or FGL) |
+-----------------------------------+ +-----------------------------------+
| RBridge Channel Header | | RBridge Channel Header |
+-----------------------------------+ +-----------------------------------+
| Channel Protocol Specific Payload | | Channel-Protocol-Specific Payload |
+-----------------------------------+ +-----------------------------------+
| Link Trailer (FCS if Ethernet) | | Link Trailer (FCS if Ethernet) |
+-----------------------------------+ +-----------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
By default, an Address Flush RBridge Channel message applies to By default, an Address Flush RBridge Channel protocol message applies to
addresses within the Data Label that appear right after the Inner addresses within the Data Label that appear right after the Inner
Ethernet Addresses. Address Flush protocol messages are usually sent Ethernet Addresses. Address Flush protocol messages are usually sent
as multi-destination packets (TRILL Header M bit equal to one) so as as multi-destination packets (TRILL Header M bit equal to one) so as
to reach all TRILL switches offering end station service in the VLAN to reach all TRILL switches offering end station service in the VLAN
or FGL specified by that Data Label. Both multi-destination and or FGL specified by that Data Label. Both multi-destination and
unicast Address Flush messages SHOULD be sent at priority 6 since unicast Address Flush messages SHOULD be sent at priority 6 since
they are important control messages but are lower priority than they are important control messages but are lower priority than
control messages that establish or maintain adjacency.</t> control messages that establish or maintain adjacency.</t>
<t> <t>
skipping to change at line 266 skipping to change at line 234
clear addresses at one TRILL switch only.</t> clear addresses at one TRILL switch only.</t>
<t>An Address Flush message can be sent selectively to the RBridges <t>An Address Flush message can be sent selectively to the RBridges
that have at least one access port configured as one of the VLANs or that have at least one access port configured as one of the VLANs or
FGLs specified in the Address Flush message payload.</t> FGLs specified in the Address Flush message payload.</t>
</list> </list>
</t> </t>
<t> <t>
Implementations should consider logging address flush messages Implementations should consider logging Address Flush messages
received with appropriate protections against packet storms.</t> received with appropriate protections against packet storms.</t>
<section title="VLAN Block Only Case" anchor="section-2.1"> <section title="VLAN Block Only Case" anchor="section-2.1">
<t> <t>
<xref target="ref-address-flush-message-vlan-block-case"/> expands <xref target="ref-address-flush-message-vlan-block-case"/> expands
the RBridge Channel Header and Channel Protocol Specific Payload the RBridge Channel Header and Channel-Protocol-Specific Payload
from <xref from <xref
target="ref-rbridge-channel-protocol-message-structure"/> for the target="ref-rbridge-channel-protocol-message-structure"/> for the
case of the VLAN-only-based Address Flush message. This form of the case of the VLAN-only-based Address Flush message. This form of the
Address Flush message is optimized for flushing MAC addresses based Address Flush message is optimized for flushing MAC addresses based
on nickname and blocks of VLANs. 0x8946 is the Ethertype assigned on nickname and blocks of VLANs. 0x8946 is the Ethertype assigned
by IEEE for the RBridge Channel protocol.</t> by IEEE for the RBridge Channel protocol.</t>
<!--[rfced] Would a pointer to an IEEE registry be needed/wanted by the reader or others? If so, please let us know how to update. <!--[rfced] Would a pointer to an IEEE registry be needed/wanted by the reader or others? If so, please let us know how to update.
Original: Original:
skipping to change at line 467 skipping to change at line 435
5 Bit Map of FGLs [RFC8383] 5 Bit Map of FGLs [RFC8383]
6 All Data Labels [RFC8383] 6 All Data Labels [RFC8383]
7 MAC Address List [RFC8383] 7 MAC Address List [RFC8383]
8 MAC Address Blocks [RFC8383] 8 MAC Address Blocks [RFC8383]
9-254 Unassigned 9-254 Unassigned
255 Reserved [RFC8383] 255 Reserved [RFC8383]
]]></artwork> ]]></artwork>
</figure> </figure>
<t><list style="hanging" hangIndent="3"><t hangText="Length:">The 8-bit unsigned integer length in bytes of the <t><list style="hanging" hangIndent="3"><t hangText="Length:">The 8-bit unsigned integer length in bytes of the
remaining information in the TLV after the length byte. The remaining information in the TLV after the Length byte. The
length MUST NOT imply that the value extends beyond the end of the Length MUST NOT imply that the value extends beyond the end of the
RBridge Channel Protocol Specific Payload area. If it does, the RBridge Channel-Protocol-Specific Payload area. If it does, the
Address Flush message is corrupt and MUST be ignored. Address Flush message is corrupt and MUST be ignored.
</t> </t>
</list> </list>
</t> </t>
<t><list hangIndent="3" style="hanging"><t hangText="Value:">Depends on the TLV type.</t> <t><list hangIndent="3" style="hanging"><t hangText="Value:">Depends on the TLV type.</t>
</list> </list>
</t> </t>
<t> <t>
In an extensible Address Flush message, when the TLVs are parsed, In an extensible Address Flush message, when the TLVs are parsed,
those TLVs having unknown types are ignored by the receiving RBridge. those TLVs having unknown types are ignored by the receiving RBridge.
There may be multiple instances of TLVs with the same Type in the There may be multiple instances of TLVs with the same Type in the
same address flush message, and TLVs are not required to be in any same Address Flush message, and TLVs are not required to be in any
particular order.</t> particular order.</t>
<t><list style="symbols"><t>All RBridges implementing the Address Flush RBridge Channel <t><list style="symbols"><t>All RBridges implementing the Address Flush RBridge Channel protocol
message MUST implement types 1 and 2, the VLAN types, and type 6, message MUST implement types 1 and 2, the VLAN types, and Type 6,
which indicates addresses are to be flushed for all Data Labels.</t> which indicates addresses are to be flushed for all Data Labels.</t>
<t>RBridges that implement the Address Flush message and implement <t>RBridges that implement the Address Flush message and implement
FGL ingress/egress MUST implement types 3, 4, and 5, the FGL FGL ingress/egress MUST implement types 3, 4, and 5, the FGL
types. (An RBridge that is merely FGL safe <xref target="RFC7172"/>, but cannot types. (An RBridge that is merely FGL safe <xref target="RFC7172"/>, but cannot
egress FGL TRILL Data packets, SHOULD ignore the FGL types, as it egress FGL TRILL Data packets, SHOULD ignore the FGL types, as it
will not learn any FGL-scoped MAC addresses from the data plane.)</t> will not learn any FGL-scoped MAC addresses from the data plane.)</t>
<t>RBridges that implement the Address Flush message SHOULD implement <t>RBridges that implement the Address Flush message SHOULD implement
types 7 and 8 so that specific MAC addresses can be flushed. If types 7 and 8 so that specific MAC addresses can be flushed. If
skipping to change at line 517 skipping to change at line 485
<t> <t>
The parsing of the TLVs by a receiving RBridge results in three pieces The parsing of the TLVs by a receiving RBridge results in three pieces
of information:</t> of information:</t>
<t><list style="empty" hangIndent="3"> <t><list style="empty" hangIndent="3">
<t><list style="numbers"><t>a flag indicating whether one or more Type 6 TLVs (All Data <t><list style="numbers"><t>a flag indicating whether one or more Type 6 TLVs (All Data
Labels) were encountered;</t> Labels) were encountered;</t>
<t>a set of Data Labels accumulated from VLAN and/or FGL <t>a set of Data Labels accumulated from VLAN and/or FGL
specifying TLVs in the message; and,</t> specifying TLVs in the message; and,</t>
<!--[rfced] This sentence does not seem to parse. Please rephrase.
Original:
if the MAC address TLV types are implemented, and a set of MAC
addresses accumulated from MAC address specifying TLVs in the message.
<t>if the MAC address TLV types are implemented, and a set of MAC <t>if the MAC address TLV types are implemented, a set of MAC
addresses accumulated from MAC address specifying TLVs in the addresses accumulated from MAC-address-specifying TLVs in the
message.</t> message.</t>
</list> </list>
</t> </t>
</list> </list>
</t> </t>
<t> <t>
VLANs/FGLs might be indicated more than once due to overlapping VLANs/FGLs might be indicated more than once due to overlapping
blocks or the like, and a VLAN/FGL is included in the above set of blocks or the like, and a VLAN/FGL is included in the above set of
VLANs/FGLs if it occurs in any TLV in the address flush message. A VLANs/FGLs if it occurs in any TLV in the Address Flush message. A
MAC address might be indicated more than once due to overlapping MAC address might be indicated more than once due to overlapping
blocks or the like, and a particular MAC address is included in the above set of blocks or the like, and a particular MAC address is included in the above set of
MAC addresses if it occurs in any TLV in the address flush message.</t> MAC addresses if it occurs in any TLV in the Address Flush message.</t>
<t> <t>
After the above information has been accumulated by parsing the TLVs, After the above information has been accumulated by parsing the TLVs,
three sets are derived as described below: a set of nicknames, a set three sets are derived as described below: a set of nicknames, a set
of Data Labels, and a set of MAC addresses. The address flush of Data Labels, and a set of MAC addresses. The address flush
operation at the receiver applies to the cross product of these operation at the receiver applies to the cross product of these
derived sets. That is, a { Data Label, MAC address, nickname } triple derived sets. That is, a { Data Label, MAC address, nickname } triple
is flushed if and only if the Data Label matches an element in the is flushed if and only if the Data Label matches an element in the
derived set of Data Labels, the MAC address matches an element in the derived set of Data Labels, the MAC address matches an element in the
derived set of MAC address, and the nickname matches an element in derived set of MAC address, and the nickname matches an element in
skipping to change at line 563 skipping to change at line 525
matches all values.</t> matches all values.</t>
<figure><artwork><![CDATA[ <figure><artwork><![CDATA[
The sets are derived as follows: The sets are derived as follows:
Data Labels set: Data Labels set:
If the Type 6 TLV has been encountered, the set is {ALL}, else, If the Type 6 TLV has been encountered, the set is {ALL}, else,
if any Data Labels have been accumulated by processing Data if any Data Labels have been accumulated by processing Data
Label TLVs (Types 1, 2, 3, 4, and 5), the set is those Label TLVs (Types 1, 2, 3, 4, and 5), the set is those
accumulated Data Labels, else, accumulated Data Labels, else,
the Data Labels set is null and the address flush message does the Data Labels set is null and the Address Flush message does
nothing. nothing.
MAC Addresses set: MAC Addresses set:
In the receiver does not implement the MAC address types (Types In the receiver does not implement the MAC address types (Types
7 and 8) or it does implement those types but no MAC 7 and 8) or it does implement those types but no MAC
addresses are accumulated in parsing the TLVs, then the MAC addresses are accumulated in parsing the TLVs, then the MAC
Address set is {ALL}, Address set is {ALL},
else, the MAC Addresses set is the set of MAC addresses else, the MAC Addresses set is the set of MAC addresses
accumulated in processing the TLVs. accumulated in processing the TLVs.
skipping to change at line 693 skipping to change at line 655
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL 2 | | FGL 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL ... | | FGL ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
The TLV value consists of FGL numbers each in 3 bytes. The Address The TLV value consists of FGL numbers each in 3 bytes. The Address
Flush message applies to those FGLs. For this Type, Length MUST be a Flush message applies to those FGLs. For this Type, Length MUST be a
multiple of 3; if it is not, the TLV is corrupt and the address flush multiple of 3; if it is not, the TLV is corrupt and the Address Flush
Message MUST be discarded if the receiving RBridge implements Type 4.</t> message MUST be discarded if the receiving RBridge implements Type 4.</t>
</section> </section>
<section title="Big Map of FGLs" anchor="section-2.2.5"><t>If the TLV Type is 5, the value is a bit map of FGLs as follows:</t> <section title="Big Map of FGLs" anchor="section-2.2.5"><t>If the TLV Type is 5, the value is a bit map of FGLs as follows:</t>
<figure><artwork><![CDATA[ <figure><artwork><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 | Length | | Type = 5 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start.FGL | | Start.FGL |
skipping to change at line 721 skipping to change at line 683
The TLV value consists of three bytes with the 24-bit starting FGL The TLV value consists of three bytes with the 24-bit starting FGL
value N. This is followed by bytes with one bit per FGL. The high value N. This is followed by bytes with one bit per FGL. The high
order bit of the first byte is for FGL N. The next-to-the-highest order bit of the first byte is for FGL N. The next-to-the-highest
order bit is for FGL N+1. The low order bit of the first byte is for order bit is for FGL N+1. The low order bit of the first byte is for
FGL N+7. The high order bit of the second byte, if there is a second FGL N+7. The high order bit of the second byte, if there is a second
byte, is for FGL N+8, and so on. If that bit is a one, the Address byte, is for FGL N+8, and so on. If that bit is a one, the Address
Flush message applies to that FGL. If that bit is a zero, then Flush message applies to that FGL. If that bit is a zero, then
addresses that have been learned in that FGL are not flushed. Note addresses that have been learned in that FGL are not flushed. Note
that Length MUST be at least 3. If Length is 0, 1, or 2 for a Type 5 that Length MUST be at least 3. If Length is 0, 1, or 2 for a Type 5
TLV, the TLV is corrupt and the Address Flush message MUST be TLV, the TLV is corrupt and the Address Flush message MUST be
discarded if type 5 is implemented. FGLs do not wrap around. If discarded if Type 5 is implemented. FGLs do not wrap around. If
there are enough bytes so that some bits correspond to an FGL higher there are enough bytes so that some bits correspond to an FGL higher
than 0xFFFFFF, those bits are ignored, but the message is still than 0xFFFFFF, those bits are ignored, but the message is still
processed for bits corresponding to valid FGLs.</t> processed for bits corresponding to valid FGLs.</t>
</section> </section>
<section title="All Data Labels" anchor="section-2.2.6"><t>If the TLV Type is 6, the value is null as follows:</t> <section title="All Data Labels" anchor="section-2.2.6"><t>If the TLV Type is 6, the value is null as follows:</t>
<figure><artwork><![CDATA[ <figure><artwork><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 847 skipping to change at line 809
-------- -------------- ------------------ -------- -------------- ------------------
0x009 Address Flush [RFC8383] 0x009 Address Flush [RFC8383]
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section title="TRILL Address Flush TLV Types" anchor="section-3.2"><t> <section title="TRILL Address Flush TLV Types" anchor="section-3.2"><t>
IANA has created the "TRILL Address Flush TLV Types" registry IANA has created the "TRILL Address Flush TLV Types" registry
at &lt;https://www.iana.org/assignments/trill-parameters/&gt; as a subregistry of the "RBridge Channel at &lt;https://www.iana.org/assignments/trill-parameters/&gt; as a subregistry of the "RBridge Channel
Protocols" registry. Protocols" registry.
<!--[rfced] Please review our update to the description of the relationship between the "RBridge Channel Protocols" registry and the "TRILL Address Flush TLV Types" registry (i.e., please confirm that the latter is a subregistry).
Registry headers are as below. The initial Registry headers are as below. The initial
entries are as in the table in <xref target="section-2.2"/>.</t> entries are as in the table in <xref target="section-2.2"/>.</t>
<figure><artwork><![CDATA[ <figure><artwork><![CDATA[
Registry: TRILL Address Flush TLV Types Registry: TRILL Address Flush TLV Types
Registration Procedures: IETF Review Registration Procedures: IETF Review
Reference: [RFC8383] Reference: [RFC8383]
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
</section> </section>
<section title="Security Considerations" anchor="section-4"><t> <section title="Security Considerations" anchor="section-4"><t>
The Address Flush RBridge Channel Protocol itself provides no The Address Flush RBridge Channel Protocol itself provides no
security assurances or features. However, Address Flush protocol security assurances or features. However, Address Flush protocol
messages can be secured by use of the RBridge Channel Header messages can be secured by use of the RBridge Channel Header
Extension <xref target="RFC7978"/>. It is RECOMMENDED that all RBridges that Extension <xref target="RFC7978"/>. It is RECOMMENDED that all RBridges that
implement the address flush message be configured to ignore such implement the Address Flush message be configured to ignore such
messages unless they have been secured with an RBridge Channel Header messages unless they have been secured with an RBridge Channel Header
Extension that meets local security policy.</t> Extension that meets local security policy.</t>
<t> <t>
If RBridges receiving Address Flush messages do not require them to If RBridges receiving Address Flush messages do not require them to
be at least authenticated, they are relatively easy to forge. In that be at least authenticated, they are relatively easy to forge. In that
case, such forged Address Flush messages can reduce network case, such forged Address Flush messages can reduce network
efficiency, by purging useful learned information that will have to efficiency, by purging useful learned information that will have to
be relearned. This provides a denial-of-service attack, but cannot be relearned. This provides a denial-of-service attack, but cannot
cause incorrect operation in the sense that it cannot cause a frame cause incorrect operation in the sense that it cannot cause a frame
skipping to change at line 920 skipping to change at line 878
</references> </references>
<section title="Acknowledgements" numbered="no" anchor="acknowledgements"><t><list style="hanging" hangIndent="3"><t hangText="The following are thanked for their contributions:"> <section title="Acknowledgements" numbered="no" anchor="acknowledgements"><t><list style="hanging" hangIndent="3"><t hangText="The following are thanked for their contributions:">
<vspace blankLines="1"/> <vspace blankLines="1"/>
Ramkumar Parameswaran, Henning Rogge Ramkumar Parameswaran, Henning Rogge
</t> </t>
</list> </list>
</t> </t>
<!--[rfced] Throughout the text, the following terminology appears to be used inconsistently.
Please review these occurrences and let us know if/how they may be made
consistent.
RBridge Channel messages vs. RBridge Channel protocol message
Address Flush message vs. address flush messages vs. address flush Message
type # vs. Type # (e.g., type 6 vs. Type 6)
length bypte vs. Length byte
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 24 change blocks. 
73 lines changed or deleted 23 lines changed or added

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