Subject: [rbridge] trill-adj Section 4 comments

From: Donald Eastlake <[email-masked]>
Date: Thu, 27 Jan 2011 14:24:07 -0500

Response to some comments by Les Ginsberg:

> Section 4
> ----------

> There needs to be a description of the DRB election process -
> equivalent to what is in [IS-IS] Section 8.4.5. For example, the set
> of DRB candidates includes all RBs to which the local system has an
> adjacency in Detect, 2-way, or Report State ...correct?

I'm certainly willing to re-word it, but it seems to me that the
following existing paragraph says what is needed:

   Determination of events 3 and 4 occurs by comparing priorities (with
   neighbor MAC address (SNPA) as a tie breaker and Port ID as a
   secondary tie breaker) across all entries in the port's adjacency
   table including those in the Detect and 2-Way states as well as those
   in the Report state.

I could make this into a separate sub-section, add references to it,
and perhaps re-word as follows:

   Events 3 and 4 consistute losing and winning the DRB election at
   the port, respectivly.

   The candidates are the local RBridge and all RBridges with which
   there is an adjacency on the port in a state other than Down. The
   winner is the RBridge with highest priority to be DRB, as
   determined from the 7-bit priority field in the Hellos received and
   the local port's priority to be DRB field, with MAC address (SNPA)
   as a tie breaker and Port ID as a secondary tie breaker. These
   fields are compared as unsigned inteered with the larger magnitude
   being considered higher priority.

> You also need to specify in what DRB election states a DRB reports
> neighbors in pseudo-node LSPs. It would seem that if neighbors are
> advertised in pre-DRB state that we could attract traffic which we
> are not yet able to forward.

An RBridge in DRB or Pre-DRB state (unless it is asserting bypass
pseudonode) report all adjacencies in the Report state in pseudo-node
LSPs. Perhaps "Pre-DRB" should be renamed "Inh-DRB" for inhibited
DRB. An RBridge in either Pre-DRB or DRB states is the Designated
RBridge for the link. It is just that in "Pre-DRB" it can't ingress or
egress native frames. In any state other than Down, it can handle
TRILL Data frames just fine.

Note the existing description of "Pre-DRB":

         The port has become DRB but is in a pre-forwarding state with
         regard to native frames and is inhibited from ingressing or
         egressing them.

> Section 4.2
> -----------

> When a DRB change causes a change in D-VLAN, the draft says:

      o  The non-Designated VLAN Hello Holding timer is set to the
         maximum of its time to expiration and the time to expiration of
         the Designated VLAN Hello Holding timer.

> The "Designated VLAN Hello Holding timer" referred to is the OLD
> Designated VLAN Hello Holding timer, correct? If so adding that
> clarification would help.

I don't like "old". How about if I change "the Designated VLAN Hello
Holding timer" to "the pre-existing Designated VLAN Hello Holding
timer".

> Also, if we are NOT DRB and the new D-VLAN is NOT in the set of
> announcing VLANs then the non-DRBs have to include the new D-VLAN in
> the set of VLANS for which they send hellos, correct? This should be
> specified.

The specification of what VLANs you send Hellos on is seems quite
clear in the TRILL base protocol standard Section 4.4.3. An RBridge
port not configured as point-to-point always sends TRILL Hellos on the
Designated VLAN, except where that VLAN is actually disabled at the
port, and the Announcing VLANs set has no effect on that.

> It is alpso apparent that DRB changes are very disruptive - even more
> so than at Layer 3. In Layer 3 on a DIS change optimal behavior is
> to do a "make before break" to minimize disruption. However, that is
> not possible here as all adjacencies will go into "Detect" state
> following a DRB change. Should it be recommended then to avoid DRB
> changes whenever possible (e.g.  by setting LAN priority)?

I don't see how a DRB change is any more disruptive to TRILL Data than
a Layer 3 DIS change is to Layer 3 data forwarding. As above, perhaps
it needs to be clarified that the purpose of the Pre-DRB state is just
to temporarily inhibit ingress and egress of native frames.

A change in Designated VLAN is somewhat disruptive. Could add at the
end of Section 4.2 "Because of the temporary disruption caused by a
change in the Designated VLAN on a link that has multiple RBridges
attached, it is RECOMMENDED that all RBridges attached to a link have
the same desired Designated VLAN for their ports on that link."

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, 31 Jan 2011 01:44:44 -0800

Donald -

Thanx for the response.
Please include the IS-IS WG on all emails associated with trill-adj review comments.

Inline.

> -----Original Message-----
> From: Donald Eastlake [mailto:[email-masked]]
> Sent: Thursday, January 27, 2011 11:24 AM
> To: Les Ginsberg (ginsberg); [email-masked]
> Subject: trill-adj Section 4 comments
> 

Given that you have introduced new adjacency states, it would help if you had more explicit language. See ISO 10589 Section 8.4.5d.

>    being considered higher priority.

Yes - something like this would be good.

>          regard to native frames and is inhibited from ingressing or

This is exactly my point. If there is two way connectivity and the reachable VLAN/MAC addresses have been advertised by the respective appointed forwarders, then traffic will be attracted even though it cannot be delivered. Is this desirable? If the pseudo-node LSP did NOT advertise neighbors in pseudo-node LSPs then such packets could be dropped closer to the source until the pre-forwarding state had expired.

> Holding timer" to "the pre-existing Designated VLAN Hello Holding

What I want clarified is that the Designated VLAN Holding timer mentioned here is associated with the D-VLAN specified by the "old DRB" - not the new DRB. How about:

"the Designated VLAN Hello Holding Timer associated with the D-VLAN specified by the previous DRB"

??

> port, and the Announcing VLANs set has no effect on that.

Yes - but as this specification is attempting to fully describe the operation of the adjacency machinery it seems worth including explicit language here - rather than requiring people to go to another document. It may be commonplace for all Rbridges to be configured with the same D-VLAN, but for cases where that is NOT the case (which is of course necessary for a D-VLAN change to be possible at all) it is a requirement for all Rbridges on the LAN to send hellos on whatever D-VLAN is specified by the DRB - which means Rbridges have to take this action on a DRB change which involves a D-VLAN change. Discussing this seems very relevant to the scope of this document.

> a Layer 3 DIS change is to Layer 3 data forwarding.

A DRB change will cause a pre-forwarding timer to be started - which means that native frames will not be deliverable for some period of time. This delay/black-holing period does not occur at Layer 3 - which is why I say a DRB change in TRILL is more disruptive as you have deliberately designed in a black-holing period as a safety mechanism. This argues that we should avoid unnecessary DRB changes.

   Les

> As above, perhaps