Subject: Re: [rbridge] trill-adj Section 4 comments

From: Donald Eastlake <[email-masked]>
Date: Tue, 8 Feb 2011 16:07:37 -0500

Hi Les,

On Mon, Jan 31, 2011 at 4:44 AM, Les Ginsberg (ginsberg)
<[email-masked]> wrote:
> Donald -
>...
>
>> -----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
...

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

OK.

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

There may or may not be a psuedo-node, which I think has nothing to do
with it. Adjacencies in the Report state are reported. They appear in
the topology so that TRILL Data through traffic, and traffic being
ingressed or egressed on other ports, can use the link.

Advertisement of end station MAC and VLAN connectivity is beyond the
scope of this document. However, I would note that single destination
TRILL Data traffic can only be "attracted" to an RBridge by frames
that RBridge itself has sent. As for multi-destination TRILL Data, it
is sent on one or more distribution trees that can be pruned on VLAN
but native frame VLAN connectivity is only reported at the RBridge
level, not the port level, and there is no pruning effect if there is
any downstream connectivity to that VLAN.

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

There is only one Designated VLAN Hello Holding timer for each
adjacency. The wording you suggest gives the impression that there
might be more than one Designated VLAN Hello Holding timer for the
adjacency associated with different VLANs, which is not what is
specified.

How about adding some text and rewording the two points on what to do
to each adjacency when the Designated VLAN changes to something like
this:

"o  If the Designated VLAN Hello Holding timer is expired, no special
    action need be taken.

o  If the Designated VLAN Hello Holding timer has time left to
   exiration, then: 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 time to expiration
   of the Designated VLAN Hello Holding timer will reflect the most
   recent Hello received on the old Designated VLAN.) Then the
   Designated VLAN Hello Holding timer is then set to the expired
   state and an event A5 occurs for the adjacency (see Section
   3.3). Afterwards the Designated VLAN Hello Holding timer will be
   updated based on Hellos received in the new Designated VLAN."

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

I really can't see duplicating over a page of detailed specifications
from the TRILL base protocol standard into this document. Those
specifications are already incorporated by reference. But I suppose a
reminder could be added such as "If the Designated VLAN for a link
changes or an RBridge changes in either direction between being the
Designated RBridge and not being the Designated RBridge at a port,
this will generally change the VLANs on which Hellos are sent by that
RBridge on that port as specified in Section 4.4.3 of [RFCtrill]."

>> > It is also 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)?

They go into Detect state only if the Designated VLAN changes, not if
the DRB changes but the Designated VLAN stays the same.

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

You're talking about native frames, not TRILL Data.

How about adding text something like:

   "Unnecessary DRB changes should be avoided, especially on links
   offering native frame service, as a DRB change will generally cause
   a transient interruption to native frame service. When practical,
   all RBridge ports on a link should be configured with the same
   designed Designated VLAN because a change in the Designated VLAN on
   the link can cause a transient interruption to TRILL Data
   forwarding on the link."

An omission in the current draft is the case where the DRB remains
unchanged but the Designated VLAN changes, perhaps because the DRB
configuration is changed to dictate a different Deisgnated VLAN. This
is fairly easy to fix and, unless there is some objection, I plan to
do so.

>   Les

...

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: Thu, 10 Feb 2011 23:43:01 -0800

Donald -

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Donald Eastlake
> Sent: Tuesday, February 08, 2011 1:08 PM
> To: isis mailing list; [email-masked]
> Subject: Re: [Isis-wg] trill-adj Section 4 comments
> 
> Hi Les,
> 

OK - it is likely my brain is still too L3 centric and I therefore likely made more of this issue than it really is. I think my major concern is discussed under DRB changes below.

>    updated based on Hellos received in the new Designated VLAN."

After this discussion and rereading your original text I think perhaps smaller changes to the original text would suffice and be less verbose. How about:

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

      o  The Designated VLAN Hello Holding timer is then set to expired (if necessary)
         and an adjacency event 5 occurs for the adjacency (see Section 3.3).

???

> RBridge on that port as specified in Section 4.4.3 of [RFCtrill]."

I would argue that it would be more useful to the implementor/reader to have all the relevant information in one document, but I also appreciate your reluctance to rework RFCtrill and the dangers of redundant specification - so I agree to your suggested reference. Thanx for the accommodation.

>    the link can cause a transient interruption to TRILL Data

Sounds good.

> is fairly easy to fix and, unless there is some objection, I plan to

Good point. I agree it would be desirable to cover this.

   Les

> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 17 Feb 2011 00:02:04 -0800

Hi Les,

...

>> >>    maximum of its time to expiration and the time to expiration of
> After this discussion and rereading your original text I think
> perhaps smaller changes to the original text would suffice and be
> less verbose. How about:
>
>      maximum of its time to expiration and the current time to expiration
>      of the Designated VLAN Hello Holding timer.
>
>   o  The Designated VLAN Hello Holding timer is then set to expired (if
>      necessary) and an adjacency event 5 occurs for the adjacency (see
>      Section 3.3).
>
> ???

OK, except "adjacency event 5" -> "event A5" for the current draft.

>> >> > the set of VLANS for which they send hellos, correct? This should
>> >> > be specified.
>> >>
> I would argue that it would be more useful to the implementor/reader
> to have all the relevant information in one document, but I also
> appreciate your reluctance to rework RFCtrill and the dangers of
> redundant specification - so I agree to your suggested reference.
> Thanx for the accommodation.

You're welcome.

OK.

OK.

Thanks,
Donald