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



On 2/19/13 1:14 PM, "Donald Eastlake" <[e-mail]> wrote:

>Hi Howard,
>
>See below.
>
>On Tue, Feb 19, 2013 at 3:24 PM, Howard Yang (howardy)
><[e-mail]> wrote:
>> 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.)
>
>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.
>
>> 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.
>
>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.
>
>> 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.
>
>Yes, that is true until the nicknames are resolved, which should
>happen quickly (see below).
>
>> 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.
>
>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.
>
>> 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) |
>>       +--------------------------------+
>
>I do not think that is necessary.
>
>Thanks,
>Donald
>=============================
> Donald E. Eastlake 3rd   [phone] (cell)
> 155 Beaver Street, Milford, MA 01757 USA
> [e-mail]
>
>> 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
>>