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

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

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" <[e-mail]> wrote:

>Hi Howard,
>
>On Tue, Feb 12, 2013 at 2:47 PM, Howard Yang (howardy)
><[e-mail]> 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>.
>>
>> (1) To support TRILL BFD, it is required to include nickname TLV or
>>sub-TLV
>> in the ISIS hello packets.
>
>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.
>
>> (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."
>
>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   [phone] (cell)
> 155 Beaver Street, Milford, MA 01757 USA
> [e-mail]
>
>> Thanks,
>> -Howard Yang