Subject: [rbridge] trill-adj circuit scope

From: Donald Eastlake <[email-masked]>
Date: Fri, 4 Mar 2011 09:12:01 -0500

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

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
 [email-masked]

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 7 Mar 2011 07:08:22 -0800

Donald -

> -----Original Message-----
> From: Donald Eastlake [mailto:[email-masked]]
> Sent: Friday, March 04, 2011 6:12 AM
> To: Les Ginsberg (ginsberg); [email-masked]
> Cc: isis mailing list
> Subject: trill-adj circuit scope
> 

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

   Les

---

From: Radia Perlman <[email-masked]>
Date: Mon, 7 Mar 2011 15:44:08 -0800

Re: Appointed forwarder mechanism.

Actually, what is there works fine.  Whether doing a link-specific
CSNP mechanism to convey this information might be better in some way
than what is there, given that there are already implementations, it
might be interesting to figure out in what way it might be better, but
to change something that works, after there are already
implementations...either what is there would have to be broken (which
it is not), or the proposed mechanism would have to be a lot better
(which I'm not convinced it is.)

Radia

On Mon, Mar 7, 2011 at 7:08 AM, Les Ginsberg (ginsberg)
<[email-masked]> wrote:
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 9 Mar 2011 16:37:26 -0800

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.

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

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.

   Les

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Radia Perlman
> Sent: Monday, March 07, 2011 3:44 PM
> To: Les Ginsberg (ginsberg)
> Cc: [email-masked]; isis mailing list
> Subject: Re: [Isis-wg] trill-adj circuit scope
> 
> > 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.
> >
> > 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.
> >
> >   Les
> >
> >
> >>

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 25 Mar 2011 15:19:00 -0400

Hi Les,

Sorry for the delay in response.

On Wed, Mar 9, 2011 at 7:37 PM, Les Ginsberg (ginsberg)
<[email-masked]> 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)

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

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.

Thanks,
Donald