[rbridge] [Isis-wg] trill-adj circuit scope

[Donald Eastlake]

Hi Les,

Sorry for the delay in response.

On Wed, Mar 9, 2011 at 7:37 PM, Les Ginsberg (ginsberg)
<ginsberg at cisco.com> wrote:

> Radia -
>
> It is very easy to demonstrate how what is currently defined can
> fail - all that has to happen is that a hello which is advertising
> some AF information is dropped by one of the RBs to whom the the AF
> information applies. As hello delivery is unreliable this can
> happen.

Any frame can be dropped...

> If your reply is that reliability can be achieved if the DRB always
> sends the AF information then I agree - but this solution has very
> poor scaling properties (and BTW is not clearly specified).

As part of the "inhibition" loop safety mechanism, RBridges are
required to indicate, in a flag bit in every TRILL Hello they send,
whether they are Appointed Forwarder for the VLAN on which the Hello
was sent. So the DRB knows if it needs to keep sending AF information
or not. If, for any reason (including the DRB failing to promptly
re-send AF information when it needs to) two RBridges on a link
persist as AF for the same VLAN, the result will normally just be a
lack of end station service for the VLAN for longer than necessary
since the RBridges will inhibit each other.

Although implementers don't seem to be having a problem, like any
non-trivial specification the Appointed Forwarder / inhibition
mechanism could be more clearly documented. A separate document is now
at www.pothole.com/~dee3/drafts/draft-perlman-trill-rbridge-af-00.txt.

Details of the Appointed Forwarder / inhibition mechanism are out of
scope for the adjancency document. In particular, that mechanism is
not part of the adjacency state mechanism, not part of MTU matching,
not part of pseudonode detemination, and is not a necessary part of
the DRB election process, the four topics the trill-adj draft is
limited to. The inclusion of the "Pre-DRB" DRB election state in
draft-ietf-trill-adj was unnecessary and out of scope. A candidate
next version of trill-adj with this removed is at
www.pothole.com/~dee3/drafts/draft-ietf-trill-adj-05.txt.

Because we are in the refractory period before the Prague meeting
neither of the above drafts can be posted right now but they are
available where indicated and I plan to post then when I can.

> There are multiple ways reliability might be achieved with better
> scaling properties - I have alluded to some in an earlier post and
> Donald has presented some ideas below. But as the TRILL
> specification stands at the moment this issue is not addressed.

The documentation of the Appointed Forwarder / inhibition mechamism
could benefit from clarification. But I think the requirement that
RBridges indicate their Appointed Forwarder status in a flag bit in
Hellos they send and inhibit themselves on receiveing a conflicting
indication is clear. In any case, with a new document clarifying this,
I don't see that it matters much if we disagree about this aspect of
the existing base protocol standard.

(see more below)

>   Les
>
>>...
>>
>> On Mon, Mar 7, 2011 at 7:08 AM, Les Ginsberg (ginsberg)
>> <ginsberg at cisco.com> wrote:
>> > Donald -
>> >
>> >> -----Original Message-----
>> >> From: Donald Eastlake [mailto:d3e3e3 at gmail.com]
>> >> Sent: Friday, March 04, 2011 6:12 AM
>> >> To: Les Ginsberg (ginsberg); rbridge at postel.org
>> >> Cc: isis mailing list
>> >> Subject: trill-adj circuit scope
>> >>
>> >> > Reliable Circuit Scope Flooding
>> >> > --------------------------------
>> >>
>> >> > [RFCTrill] defines a requirement for reliable circuit scoped
>> >> > flooding of Appointed Forwarder Information (Section 4.4.2) but it
>> >> > is not specified how this is to be achieved. I had hoped this
>> >> > document would provide that specification.
>> >>
>> >> It sound like you are alluding to a link scoped flooding mechanism
>> >> which I believed you also referred to in an earlier ISIS WG
>> >> post. Presumably something involving some new PDUs like LLSP (link
>> >> local state PDU) and LCSNP (local complete sequence number PDU),
>> >> perhaps both in L1 and L2 versions and possibly with the primary
>> index
>> >> being the SNPA rather than the System ID. It is quite an intriging
>> >> idea. Is there a draft yet? I don't recall seeing one.
>> >
>> > The first issue is getting consensus that this is indeed an issue
>> > which needs to be addressed - which thus far has not been
>> > achieved. I believe it does need to be addressed. Whether what
>> > you suggest below is a workable solution can only be evaluated if
>> > you provide normative language so we understand the solution. At
>> > present, RFCTrill says that the DRB sends AF information - but
>> > the manner in which reliability is achieved is unspecified.
>> >
>> > If you update whatever spec you feel is most appropriate for this I
>> > will review it.

I don't think we agree on process but I don't think it matters since
we have produce a draft clarifying the Appointed Forwarder /
inhibiiton mechanism as mentioned above.

>> > I understand you feel this is out of scope for the review of
>> > draft-ietf-trill-adj. But as AF information is sent in IIHs and
>> > the reliability is a new circuit-scoped requirement it seemed
>> > appropriate for me to mention here.

AF/inhibiiton just doesn't, as far as I can see, fit into any of the
four enumerated topics that are the pre-established scope for the
trill-adj draft. But as long as it is clarified in another document, I
don't know that that makes much difference.

>> >   Les
>> >
>> >
>> >>
>> >> In any case, I don't see any need for it in connection with
>> appointed
>> >> forwarders. In particular I'd like to point out the following:
>> >>
>> >> - Whether an RBridge believes it is the appointed forwarder for a
>> VLAN
>> >>   is indicated in TRILL Hellos that it sends on that VLAN. Thus the
>> >>   DRB normally has feedback on what other RBridges on the link think
>> >>   their Appointed Forwarder status is.
>> >>
>> >> - An RBridge that believes it is appointed forwader for a particular
>> >>   VLAN, when it receives a TRILL Hello on that VLAN from another
>> >>   RBridge in which that other RBridge asserts that it is appointed
>> >>   forwarder for that VLAN, is temporarily inhibited for that VLAN
>> >>   only. This can result in transient loss of end station data but
>> that
>> >>   is preferable to a loop. (Such inhibition has no effect on TRILL
>> >>   Data frames, only on native frame receipt and transmission.)
>> >>
>> >> - When an RBridge sees the DRB change and it does not become DRB, it
>> >>   clears any fowarder appointments that RBridge thinks it has.
>> >>
>> >> - The spec states that appointing an RBridge appointed forwarde hss
>> no
>> >>   effect except for VLAN(s) that are enabled on a port that RBridge
>> >>   has on the link. Since the network manager will normally have
>> >>   control over VLAN enablement, this means that you can appoint an
>> >>   RBridge forwarder for, say, all even numbered VLAN by only having
>> >>   those VLANs enabled and then sending out a forwader appointment
>> >>   appointing it for all VLAMs.
>> >>
>> >> > The lack of reliable flooding means that either:
>> >>
>> >> > a)Appointed forwarder information MUST be included by the DRB
>> always
>> >> > - which does not scale well
>> >>
>> >> Since the DRB can normally sense, from their Hellos, what other
>> >> RBridges on the link think their appointed forwarder status is, it
>> >> knows when it needs to refresh the existing appointed forwarder
>> >> information or send a new set of appointed forwarder information.
>> But,
>> >> no doubt, it would be a good practice to send it occasionally
>> >> regardless.
>> >>
>> >> > OR
>> >>
>> >> > b)Loops and/or loss of traffic for a given VLAN MAY occur
>> >>
>> >> The inhibition from receiving a Hello indicating an appointed
>> >> forwarder conflict and other safety features should stop loops. It
>> is
>> >> certainly possible, with perverse configurations, to have loss of
>> >> native traffic.
>> >>
>> >> In any case, the appointed forwarder mechanism is out of scope for
>> >> draft-ietf-trill-adj.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3 at gmail.com