[rbridge] Agenda items for Dublin?

Wed Jun 25 10:57:01 PDT 2008

Hi Eric,

See below at @@@

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Eric Gray
Sent: Tuesday, June 24, 2008 8:06 AM
To: Erik Nordmark; Developing a hybrid router/bridge.
Subject: Re: [rbridge] Agenda items for Dublin?

Erik,

	We have had relative quiet on the mailing list, but I'm unsure
that means there are not some issues with the protocol specification
that need focus.  However, if key contributors will not be there, it
is questionable what value there is to be derived from trying to do 
this at the IETF meeting in Dublin.

@@@ Yes, at this point Erik and I are planning to cancel the Dublin
TRILL WG meeting.

	Just for clarity, what are the presumed resolutions for these
issues:

AF Change Handling (the list went quiet after several slightly 
different proposals were made)?

@@@ It seems to me that the proposal to have a per Rbridge per VLAN
"appointed forwarder status lost" counter met with the most approval so
that will be in the next protocol draft for people to comment on. When
Rbridge RB1 observes this counter change in the link state for RB2 for
VLAN-x then RB1 would shorten the time-out for any VLAN-x MAC addresses
it had learned from decapsulating frames from RB2.

Have there been any off-list comments on Donald's post with the
subject "Rbridge assumptions about bridged LANs"?

@@@ If there were, they didn't get to me :-) So currently the plan is
for something very similar to that text to be in the next protocol
draft.

Rbridge setting of BPDU Topology Change Flag (this looks to have
been resolved based on a comment from Donald and a response from
Radia)?

@@@ It seems to have been resolved to put this in but I think my comment
may have been slightly confused or at least not specific enough. I think
it is more like the topology change flag in a spanning tree BPDU is for
the root to flood the fact that there has been topology change through
the bridged LAN. What an Rbridge should do when it looses appointer
forwarder status for a VLAN on a port is send topology change BPDUs out
that port until it gets an acknowledging spanning tree BPDU with the
topology change flag set...

David Melman's questions (requiring changes to the protocol draft
- based on Donald's responses):

	Modifications to text to make the text Normative (while also
	presumably aligning the pseudo-code and text)?

@@@ Yes, a working group consensus has been declared that the text is
normative and in case of conflict the text dominates the pseudo code.

	What does a transit RBridge does with a known unicast TRILL 
	data frame if the egress RBridge nickname is unknown?

@@@ I guess there hasn't been any discussion on this but the suggestion
I posted was that it discard the frame. This seems like the simplest
thing. Converting to unknown unicast frame seems too likely to cause
broadcast storms. I suppose that, in principle, a "MAY" behavior for the
transit Rbridge could be to see if it knows the Inner.MacDA unicast
address and if so change the TRILL header. But: (1) Transit Rbridges and
unlikely to know that many end station MAC addresses. Shielding transit
Rbridges from having to learn or use lots of end station MAC addresses
is part of the point of TRILL. (2) Lots of places where the draft
prohibits any monkeying with TRILL header fields after encapsulation
would have to change.

Proposed details for announcing endnodes (this discussion petered 
out in a tangential discussion about WG goals and objectives - as
a result, it's not obvious what, if any, resolution was achieved)?

@@@ A major complaint had been that there would be too many Hellos but
it appears to be simple to eliminate Hellos on the end station address
distribution instances of TRILL IS-IS by the inclusion of enough
information in the core instance link state to determine the DRB for any
end station address distribution instance virtual link. The only thing
that would be special about such a virtual link DRB would be that it
would issue CSNPs.

Radia's question -  How many "priorities" are there (there was a
small consensus - two responders - that all of the priorities she
mentioned should be separately configurable, but what changes did
this require)?

@@@ Radia listed four possible priorities and indeed, both comments said
they should all be separate. Two of them are already provided for: the
priority for becoming DRB for the core instance of IS-IS is already
provided by IS-IS and the priority for getting a nickname is already
spelled out in detail in the current protocol draft. A third was the
priority for becoming a distribution tree root. The whole mechanism for
having this priority (with System ID for tie breaker) to select the
highest priority Rbridge which can then specify how many trees are to be
calculated, etc., is being added. So adding this priority can be easily
done at the same time. The last additional priority was for being DRB on
an end station address distribution instance virtual link. And, if there
is a separate priority for this, should it be per Rbridge or per Rbridge
per VLAN. To me, this seems like the least important of all the
priorities. I don't see any harm in having a separate priority for this
per Rbridge but it doesn't seem worth it to have one per Rbridge per
VLAN. I don't think people will be setting up vast numbers of such
instances...

Donald's question - What to do about VLAN mapping (asked but not
answered by anyone)?

@@@ Yes, it was hard to tell which way the WG was leaning on this. The
simplest and most drastic thing to do is, if Rbridge RBi gets a Hello
showing mapping from VLAN-x to VLAN-y, then Rbi disables the port on
which the Hellos was received for both VLANs. This would at least lead
to hard failures and hopefully get the network administrator's
attention. Other possibilities would be disabling only one of these
and/or reporting the matter to the DRB...

--
Eric Gray
Principal Engineer
Ericsson  

@@@ Thanks for gathering these questions together and posting them.

@@@ Comments welcome but it might be a good idea, for detailed comments,
to cut and paste so as to separate the various issues into different
emails.

@@@ Donald

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Erik Nordmark
> Sent: Wednesday, June 18, 2008 1:28 PM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Agenda items for Dublin?
> 
> We don't have much if anything to put on the agenda, and some key WG 
> contributors will not be in Dublin, thus we are considering 
> canceling 
> the WG meeting in Dublin.
> 
> Comments?
>     Erik and Donald
> 
> Erik Nordmark wrote:
> > What are the items that we to discuss face-to-face in 
> Dublin? We don't 
> > seem to have many open issues left in the protocol spec.
> > 
> >    Erik and Donald
_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge