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

[Donald Eastlake <[e-mail]>]

Hi Howard,

On Tue, Feb 19, 2013 at 6:14 PM, Howard Yang (howardy)
<[e-mail]> wrote:
> 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)?

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
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

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