Subject: Re: [Isis-wg] trill-adj Section 4 comments

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

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

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

Yes - something like this would be good.

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

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.

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

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"

??

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

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.

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

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