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

From: "Howard Yang (howardy)" <[email-masked]>
Date: Tue, 12 Feb 2013 19:47:55 +0000

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

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 12 Feb 2013 22:45:14 -0500

Hi Howard,

On Tue, Feb 12, 2013 at 2:47 PM, Howard Yang (howardy)
<[email-masked]> wrote:
> 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>.
>

Every TRILL IS-IS Hello PDU is required to include a Special VLANs and
Flags Sub-TLV which includes the Sender Nickname. Perhaps the
explanatory text for that the Sub-TLV should be expanded to mention
BFD bootstrap.

> 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).

As above, Sender Nickname is already included in every TRILL IS-IS Hello.

> 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.

As above, I do not believe that is necessary.

> 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."

Work has started on an rfc6327bis draft to extend the proper TRILL
adjacency state machine to point-to-point links and also include MTU
testing on such links, to make them consistent with broadcast links. I
believe that this is the best course. Would you be interested in
helping with rfc6327bis?

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: "Howard Yang (howardy)" <[email-masked]>
Date: Wed, 13 Feb 2013 05:27:26 +0000

Hi Donald,

Thanks very much for the answers and explanation.

Yes, I would be very interested in the rfc6327bis extension work.

Thanks,
-Howard

On 2/12/13 7:45 PM, "Donald Eastlake" <[email-masked]> wrote:

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

---

From: "Howard Yang (howardy)" <[email-masked]>
Date: Tue, 19 Feb 2013 20:24:20 +0000

Hi Donald,

I have more questions about the TRILL BFD.

Suppose 3 Rbridges are to be connected on the LAN, and all 3 RBs (A, B and
C) are having the same nickname before they are to be connected (So it's a
3-node nickname collision case, which is not likely to happen in the real
world, but just to demonstrate the points.)

Since TRILL BFD Control frames are TRILL Rbridge Channel frames, we need
both local and peer's nicknames, which happens to be the same in this case.

Therefore, if A receives a TRILL BFD packet, it cannot tell if the packet
is from B or C. This would prevent an RB from establish any TRILL BFD
sessions.

Notice we support RFC6213 (ISIS BFD enabled TLV), which requires to have
BFD session to be in UP state before bringing up ISIS adjacency, and
notice the nickname collision resolution is done after exchange of LSPs.
And notice we need to bring up ISIS adjacency first before LSP can be
exchanged. Therefore, we are stuck.

To solve this problem, I am suggesting to modify the TRILL BFD
encapsulation by adding the source system_ID and destination system_ID.

So the packet could look like the following:

      +--------------------------------+
      |          Link Header           |
      +--------------------------------+
      |          TRILL Header          |
      +--------------------------------+
      |     Inner Ethernet Header      |
      +--------------------------------+
      |     RBridge Channel Header     |
      +--------------------------------+
      | dest system_id | src system_id |
+--------------------------------+
| Protocol Specific Payload (BFD) |
+--------------------------------+

      | Link Trailer (FCS if Ethernet) |
      +--------------------------------+

Thanks,
-Howard

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 19 Feb 2013 16:14:48 -0500

Hi Howard,

See below.

> world, but just to demonstrate the points.)

Sure. It is good to consider all the corner cases. You are also
assuming that there are no other paths through the topology by which
link state could flood and the nickname collision already have been
resolved, which is OK to assume for this unusual case.

> both local and peer's nicknames, which happens to be the same in this case.

Well, actually you can use "Any-RBridge" as the egress nickname. TRILL
switches supporting the RBridge Channel facility are required to
recognize the "Any-RBridge" nickname.

> is from B or C. This would prevent an RB from establish any TRILL BFD

Yes, that is true until the nicknames are resolved, which should
happen quickly (see below).

> exchanged. Therefore, we are stuck.

Actually I don't think so. There are Down, Detect, Two-Way, and Report
states for a TRILL Adjacency on a LAN link [RFC6327]. A question is,
when does LSP synchronization start? This was not addressed in
[RFC6325] but that oversight is fixed in the approved
draft-ietf-trill-clear-correct-06.txt, Section 9. In particular, LSP
synchronization starts when the adjacency reaches the Two-Way state.
So, of A, B, and C, as soon as any pair's adjacency reaches Two-Way,
the nicknames should be quickly resolved.

> So the packet could look like the following:

I do not think that is necessary.

Thanks,
Donald

---

From: "Howard Yang (howardy)" <[email-masked]>
Date: Tue, 19 Feb 2013 23:14:36 +0000

Hi Donald,

Thanks very much for the explanation. That works for LAN.

By the way, on the point-to-point interface, we don't have the mechanism
to resolve the nickname collision (as we don't have TWO-WAY state). So we
use the Any-Rbridge as destination nickname in TRILL BFD packets. And
since there could be only up to one BFD neighbor for one-hope BFD control,
we are fine with the BFD bootstrapping. However, this would be an issue if
we allow multiple-hop BFD, isn't it (as there could be multiple BFD
sessions coming off an interface)?

Thanks,
-Howard

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 19 Feb 2013 18:57:18 -0500

Hi Howard,

> sessions coming off an interface)?

Yes, you can't use Any-RBridge for more than one hop. And, after the
first hop, subsequent hops can only be taken if they are fully up and
part of the topology.

Thanks,
Donald