[trill] Comments on TRILL BFD draft and TRILL use of ISIS draft

["Howard Yang (howardy)" <[e-mail]>]

Hi,

I have a couple of comments on TRILL BFD draft <draft-ietf-trill-rbridge-bfd-07.txt> and TRILL use of ISIS draft <draft-ietf-isis-rfc6326bis-00.txt>.


(1) To support TRILL BFD, it is required to include nickname TLV or sub-TLV in the ISIS hello packets.

The reason is that when the neighbor receives the BFD packets, if the nickname of the peer is not known, BFD cannot associate such BFD packets with the BFD session.

By the way, let's look at, in specific, the "One-Hop TRILL BFD Control" here. Looking at Layer 3 (IP or IPv6) BFD, we have IP address TLV included in the ISIS hellos, so that when BFD session is created by ISIS, ISIS can pass both local and peer's IP addresses to BFD for BFD to associate a BFD packet to a session. Corresponding to IP address, in TRILL, we have the nickname. When a BFD session is created with an unknown nickname for the peer, and when a BFD packet from this peer is received, BFD has no way to associate this BFD packet with the BFD session previously created. Notice BFD packets are defined to have the TRILL channel encapsulation (draft-ietf-trill-rbridge-channel-08.txt).

So we need to add the requirement of including the local nickname in ISIS hellos, in addition to the "ISIS BFD enabled TLV" (RFC 6213).

The nickname is currently defined as nickname sub-tlv (<draft-ietf-isis-rfc6326bis-00.txt>) and it is defined only in Router or MT Capability TLV. We need to extend it and allow the nickname sub-tlv to be in the Multi-Topology-Aware Port Capability TLV.



(2) In Section 3.1 of the TRILL BFD draft, we have

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 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, that is, the adjacency is in the Two-Way or
   Report state [RFC6327] and both RBridges indicate support of TRILL
   BFD is enabled.  The BFD Enabled TLV is used to indicate this as
   specified in [RFC6213].



The "Two-Way" or "Report" is specific to TRILL LAN interface. It does not apply to the point-to-point interface. So, it should be modified to:

"that is, the adjacency is in the Two-Way or Report state [RFC6327] on the LAN or INIT on the point-to-point when neighbor is known and both Rbridges indicate support of TRILL BFD is enabled."


Thanks,

-Howard Yang