Subject: [rbridge] TRILL Monday morning in Philadelphia

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Tue, 26 Feb 2008 18:46:31 -0500

The TRILL WG meeting at the Philadelphia IETF meeting next month has
been scheduled for 9am Monday morning. 

See https://datatracker.ietf.org/meeting/71/agenda.html.

While such things are not guaranteed, I believe that, at this point, it
is very unlikely to change.

Thanks,
Donald
====================================================
 Donald E. Eastlake 3rd      +1-508-786-7554 (work)
 Motorola Laboratories
 111 Locke Drive
 Marlborough, MA 01752 USA
 [email-masked]

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

Content-class: urn:content-classes:message
Date: Tue, 26 Feb 2008 18:46:31 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] TRILL Monday morning in Philadelphia
Status: RO
Content-Length: 487

The TRILL WG meeting at the Philadelphia IETF meeting next month has
been scheduled for 9am Monday morning. 

See https://datatracker.ietf.org/meeting/71/agenda.html.

While such things are not guaranteed, I believe that, at this point, it
is very unlikely to change.

Thanks,
Donald
====================================================
 Donald E. Eastlake 3rd      +1-508-786-7554 (work)
 Motorola Laboratories
 111 Locke Drive
 Marlborough, MA 01752 USA
 [email-masked]

Content-class: urn:content-classes:message
Date: Tue, 26 Feb 2008 13:26:21 -0500
From: "Caitlin Bestler" <[email-masked]>
To: "James Carlson" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] ECN RE:  TRILL Options
Status: RO
Content-Length: 1384

> -----Original Message-----
> From: James Carlson [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2008 9:44 AM
> To: Caitlin Bestler
> Cc: Eastlake III Donald-LDE008; [email-masked]
> Subject: RE: ECN RE: [rbridge] TRILL Options
> 
> Caitlin Bestler writes:
> > > That's it exactly.  I think ECN is pretty much worthless
otherwise;
> > > it's an end-to-end exercise involving the transport layer, or it
> may
> > > as well not be implemented at all.  ECN that's consumed by
RBridges
> > > alone doesn't make any sense to me.
> > >
> >
> > A TRILL option with ECN semantics could be used directly by an
> RBridge
> > that had other traffic control options on its local ports than just
> > PAUSE, Priority-based Flow Control or Drop. If such methods were
> > available, they would be preferable to modifying the L3 header.
> 
> If that's the intent, then I'm just neutral on the proposal.  I can
> see value in ECN behavior that interoperates with existing network
> layer ECN semantics, but if it's its own independent beast, it's no
> longer interesting ... at least to me.
> 

There probably are  mechanisms where ECN-semantics could supplement
the congestion control mechanisms defined by 802.1Qau. But that type
of extension would not naturally be developed until the 802.1Qau work
was complete. When that happens, it would be a good use of a TRILL
option.

Date: Tue, 26 Feb 2008 12:43:37 -0500
From: James Carlson <[email-masked]>
To: Caitlin Bestler <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] ECN RE:  TRILL Options
Status: RO
Content-Length: 1033

Caitlin Bestler writes:
> > That's it exactly.  I think ECN is pretty much worthless otherwise;
> > it's an end-to-end exercise involving the transport layer, or it may
> > as well not be implemented at all.  ECN that's consumed by RBridges
> > alone doesn't make any sense to me.
> > 
> 
> A TRILL option with ECN semantics could be used directly by an RBridge
> that had other traffic control options on its local ports than just
> PAUSE, Priority-based Flow Control or Drop. If such methods were 
> available, they would be preferable to modifying the L3 header.

If that's the intent, then I'm just neutral on the proposal.  I can
see value in ECN behavior that interoperates with existing network
layer ECN semantics, but if it's its own independent beast, it's no
longer interesting ... at least to me.

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Content-class: urn:content-classes:message
Date: Tue, 26 Feb 2008 12:29:35 -0500
From: "Caitlin Bestler" <[email-masked]>
To: "James Carlson" <[email-masked]>, "Eastlake III Donald-LDE008" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] ECN RE:  TRILL Options
Status: RO
Content-Length: 2200

James Carlson wrote:

> In any event, I'd expect the encapsulating TRILL node to copy the ECN
> bits (likely similar to RFC 3168, but perhaps requiring mapping for
> non-IP protocols) into the TRILL header, and the decapsulating TRILL
> node to apply those ECN bits to the encapsulated packet before
> disgorging it onto the destination network.  You then have a record of
> congestion encountered in the middle of the bridged network.
> 
> Systems that don't do ECN will generally ignore the bits (and will set
> 00 on transmit), and those that do it will do the Right Thing.  If the
> TRILL network doesn't support ECN at all, then the bits get copied
> from input to output unmolested -- meaning that congestion through the
> larger network is still detected, but that congestion within the TRILL
> network is invisible.
> 
> If the TRILL encapsulator doesn't do ECN, then the bits will be zero
> on input, and the egress can ignore them on output.  If the egress
> doesn't do ECN, then the inner packet will be left unchanged, again
> meaning that ECN works but that the TRILL network is not visible.
> 
> Finally, if the carried protocol doesn't support ECN, or the ingress
> RBridge doesn't know how the next level protocol deals with ECN, then
> set the bits to zero on entry and thus do nothing on egress.
> 
> No "intent" needs to be communicated, as best I can tell.  It's a
> best-effort signaling mechanism.
> 
> > If it uses bits either in the TRILL Header or
> > in a TRILL Option, these are lost at the egress Rbridge. -- Although
> > perhaps affecting Rbridge behavior could also be beneficial. And for
> > IP frames, we could set bits in the IP header...
> 
> That's it exactly.  I think ECN is pretty much worthless otherwise;
> it's an end-to-end exercise involving the transport layer, or it may
> as well not be implemented at all.  ECN that's consumed by RBridges
> alone doesn't make any sense to me.
> 

A TRILL option with ECN semantics could be used directly by an RBridge
that had other traffic control options on its local ports than just
PAUSE, Priority-based Flow Control or Drop. If such methods were 
available, they would be preferable to modifying the L3 header.

Content-class: urn:content-classes:message
Date: Tue, 26 Feb 2008 12:22:56 -0500
From: "Caitlin Bestler" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, "James Carlson" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] ECN RE:  TRILL Options
Status: RO
Content-Length: 1849

Donald Eastlake wrote:
> A few things:
> 
> Currently there are only two free bits in the TRILL Header.
> 
> If the intent of the ECN feature is to affect host behavior, how is
> this communicated to the host?

Very cleverly.

Which is to say, that the RBridge and the hosts it services would have
to have some form of local collaboration on traffic flow for this
information
to be fully useful. Since it would not be universally applicable I had
assumed
that this usage would have a very poor chance of grabbing the last few
bits
in the TRILL Header or in getting it to expand by 32 bits.

> If it uses bits either in the TRILL Header or
> in a TRILL Option, these are lost at the egress Rbridge. -- Although
> perhaps affecting Rbridge behavior could also be beneficial. And for
IP
> frames, we could set bits in the IP header...
> 

My assumption is that having an L2 entity modify L3 headers is something
best avoided. Of course, if the group thought this was the best strategy
it could add a "MAY modify the IP header for the following reasons"
clause.

But while an RBridge is more like a Router than a traditional Bridge, I 
still think that we're better off thinking of it as an L2 device and NOT
encouraging it to play with L3 headers. That's a slippery slope that
leads
all too quickly to trying to standardize PNAT behavior and a dozen other
forms of middlebox mischief.

> There is also the 802.1 Congestion Management effort perking along...
> 

I'm viewing this more as a supplement to 802.1 Congestion Management.
The 802.1Qau effort is more focused on short congestion storms, while
IETF efforts have been exploring topics such as admission control.
It would be a shame if by enabling larger L2 clouds, RBridges diminished
the value of these IETF congestion controls that work over a longer time
period than 802.1Qau's methods.

Date: Tue, 26 Feb 2008 11:09:38 -0500
From: James Carlson <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: [email-masked], Caitlin Bestler <[email-masked]>
Subject: Re: [rbridge] ECN RE:  TRILL Options
Status: RO
Content-Length: 2551

Eastlake III Donald-LDE008 writes:
> A few things:
> 
> Currently there are only two free bits in the TRILL Header.

That's a pretty good reason to be hesitant.  ;-}

> If the intent of the ECN feature is to affect host behavior, how is this
> communicated to the host?

Note that "hosts" in TRILL terminology are quite likely to be
"routers" in the network layer world.

In any event, I'd expect the encapsulating TRILL node to copy the ECN
bits (likely similar to RFC 3168, but perhaps requiring mapping for
non-IP protocols) into the TRILL header, and the decapsulating TRILL
node to apply those ECN bits to the encapsulated packet before
disgorging it onto the destination network.  You then have a record of
congestion encountered in the middle of the bridged network.

Systems that don't do ECN will generally ignore the bits (and will set
00 on transmit), and those that do it will do the Right Thing.  If the
TRILL network doesn't support ECN at all, then the bits get copied
from input to output unmolested -- meaning that congestion through the
larger network is still detected, but that congestion within the TRILL
network is invisible.

If the TRILL encapsulator doesn't do ECN, then the bits will be zero
on input, and the egress can ignore them on output.  If the egress
doesn't do ECN, then the inner packet will be left unchanged, again
meaning that ECN works but that the TRILL network is not visible.

Finally, if the carried protocol doesn't support ECN, or the ingress
RBridge doesn't know how the next level protocol deals with ECN, then
set the bits to zero on entry and thus do nothing on egress.

No "intent" needs to be communicated, as best I can tell.  It's a
best-effort signaling mechanism.

> If it uses bits either in the TRILL Header or
> in a TRILL Option, these are lost at the egress Rbridge. -- Although
> perhaps affecting Rbridge behavior could also be beneficial. And for IP
> frames, we could set bits in the IP header...

That's it exactly.  I think ECN is pretty much worthless otherwise;
it's an end-to-end exercise involving the transport layer, or it may
as well not be implemented at all.  ECN that's consumed by RBridges
alone doesn't make any sense to me.

> There is also the 802.1 Congestion Management effort perking along...

I'm afraid I don't know what they're doing.  :-<

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Content-class: urn:content-classes:message
Date: Tue, 26 Feb 2008 11:21:28 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: Re: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-07.txt
Status: RO
Content-Length: 3388

Hi, just some quick comments on this draft.

I believe the list of changes from -06 to -07 in the Appendix is
reasonably complete.

Section 5, the pseudo-code, has not been fully updated.

On Options, there was discussion on the mailing list which didn't seem,
to me, to produce a particularly clear consensus. The protocol draft has
the critical option summary bits but the separate non-WG options draft
which has been posted is written so that, with relatively minor effort,
part of it could replace Section 3.5 of the protocol draft without
critical option summary bits. This makes little difference for transit
Rbridges; they would just have to check that the top two bits of the
first byte of the options area are not zero as opposed to checking that
the top bit is not one. However, the separate non-WG draft would, under
some circumstances, require an egress Rbridge to scan the options
present.

Thanks,
Donald
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Monday, February 25, 2008 7:30 PM
To: [email-masked]
Cc: [email-masked]
Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Transparent Interconnection of Lots of
Links Working Group of the IETF.

	Title		: Rbridges: Base Protocol Specification
	Author(s)	: R. Perlman
	Filename	: draft-ietf-trill-rbridge-protocol-07.txt
	Pages		: 84
	Date		: 2008-2-25
	
RBridges allow for optimal pair-wise forwarding with zero
   configuration, safe forwarding even during periods of temporary
   loops, and multipathing for both unicast and multicast traffic. They
   achieve these goals using IS-IS routing and encapsulation of traffic
   with a header that includes a hop count.

   RBridges are compatible with previous IEEE 802.1 bridges as well as
   current IPv4 and IPv6 routers and end nodes. They are as invisible to
   current IP routers as bridges are and, like routers, they terminate
   the bridge spanning tree protocol.

   The design supports VLANs and optimization of the distribution of
   multi-destination frames based on VLAN and IP derived multicast
   groups.  It also allows forwarding tables to be based on RBridge
   destinations (rather than end node destinations), which allows
   internal forwarding tables to be substantially smaller than in
   conventional bridge systems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-07
.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-trill-rbridge-protocol-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Content-class: urn:content-classes:message
Date: Tue, 26 Feb 2008 11:10:43 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Radia Perlman" <[email-masked]>
Cc: [email-masked]
Subject: [rbridge] Options...
Status: RO
Content-Length: 2092

Hi Radia,

See below at @@@

-----Original Message-----
From: Radia Perlman [mailto:[email-masked]] 
Sent: Monday, February 25, 2008 6:48 PM
To: Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: Re: [rbridge] TRILL Use of IS-IS

I like this draft, which I'm just saying explicitly because in the past 
I've not been all that enthusiastic about options.

@@@ Thanks.

However, I'm still unconvinced about the need for critical options, but 
it doesn't seem that onerous to provide for them.

And as for the integrity protection option in the draft, (section 3.4), 
why not just protect the inner packet, which does not
get modified hop by hop? And furthermore, it seems like security ought 
to be end-to-end and not ingress-to-egress RBridge,
so I'm not sure how useful it is to provide it, especially if computing 
it is nontrivial.

@@@ Sure end-to-end security is best but it is a fallacy to believe that
security should be ignored unless it can be the best. That would imply,
for example, that 802.11 (Wi-Fi) security is useless because it is just
hop by hop. But people at public hot spots really don't want everyone in
the vicinity to be able to tell what insecure web sites they are
browsing and the like.

@@@ The computations for authentication and/or encryption will be
nontrivial but how much of a burden that is depends on what hardware
assist you have. People in the wireless world generally think of
authentication and encryption as being free because there is usually
hardware built in that can do it at your maximum transmission rate. That
hardware will just be sitting idle if you choose not to use security.

As for congestion indication, or anything else (like flow ID), in theory

we could provide for it in the main TRILL header, but
there would have to be room for it. Maybe eventually we could do a new 
version of the header that had some of the
options upgraded to be in the main header, and possibly shuffle the 
header along the lines Don proposed awhile ago (moving
the VLAN bits into the TRILL header, for instance.

Radia

@@@ Thanks,
@@@ Donald

Content-class: urn:content-classes:message
Date: Tue, 26 Feb 2008 10:22:56 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Caitlin Bestler" <[email-masked]>, "James Carlson" <[email-masked]>
Cc: [email-masked]
Subject: [rbridge] ECN RE:  TRILL Options
Status: RO
Content-Length: 3045

A few things:

Currently there are only two free bits in the TRILL Header.

If the intent of the ECN feature is to affect host behavior, how is this
communicated to the host? If it uses bits either in the TRILL Header or
in a TRILL Option, these are lost at the egress Rbridge. -- Although
perhaps affecting Rbridge behavior could also be beneficial. And for IP
frames, we could set bits in the IP header...

There is also the 802.1 Congestion Management effort perking along...

Thanks,
Donald

-----Original Message-----
From: Caitlin Bestler [mailto:[email-masked]] 
Sent: Monday, February 25, 2008 2:12 PM
To: James Carlson
Cc: Eastlake III Donald-LDE008; [email-masked]
Subject: RE: [rbridge] TRILL Options

ECN-like bits *could* be defined in the RBridge header, but they
would not be necessary for *RBridge* functionality, but rather for
RBridges to provide this bonus info to the host stacks.

I would be perfectly happy with ECN-like bits being encoded in the
RBridge header, but I can't really make a case as to why the information
needs to be there rather than in options. Encoding it in the options
will work. If there is enough of a consensus that almost everyone
would find ECN-like reporting useful for RBridges then they could
be promoted, but like most of the other speculative options that
Donald listed, this is just an idea about something that seems likely
to be advantageous. It is not a concrete proposal that has been
prototype tested or anything like that.

> -----Original Message-----
> From: James Carlson [mailto:[email-masked]]
> Sent: Monday, February 25, 2008 10:36 AM
> To: Caitlin Bestler
> Cc: Eastlake III Donald-LDE008; [email-masked]
> Subject: Re: [rbridge] TRILL Options
> 
> Caitlin Bestler writes:
> > Not that the list of options described in this document needs to
> > be all inclusive, but I think there is one class of option at least
> > as probable as those cited here: a "pseudo-router" option.
> >
> > This option would allow an RBridge to report congestion as though
> > it were a router, by encoding what a ECN capable router would have
> > encoded -- but without requiring the RBridge to actually modify
> > L3 headers.
> 
> Why would it need to be an option?
> 
> Since we know about ECN now, why not just reserve a couple of bits for
> it, and allow the bridges that know how to mark properly do so?
> (Those that don't know how will just blindly forward the existing bits
> along, which is what you want for ECN anyway.  An ECN-incapable egress
> would just lose the bits.)
> 
> Perhaps I'm missing the point, but I think the only reason to have
> options is that there's something that requires inter-bridge
> cooperation.  If it doesn't require cooperation in order to achieve
> interoperability, then it doesn't need an option.
> 
> --
> James Carlson, Solaris Networking
> <[email-masked]>
> Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442
> 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442
> 1677

To: [email-masked]
From: [email-masked]
Date: Mon, 25 Feb 2008 17:30:01 -0800 (PST)
Cc: [email-masked]
Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-arch-05.txt
Status: RO
Content-Length: 2214

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.

	Title		: The Architecture of an RBridge Solution to TRILL
	Author(s)	: E. Gray, J. Touch, R. Perlman
	Filename	: draft-ietf-trill-rbridge-arch-05.txt,.pdf
	Pages		: 36
	Date		: 2008-2-25
	
RBridges are link layer (L2) devices that use a routing protocol 
as a control plane. This combines several of the benefits of the 
link layer with those of the network layer. For example RBridges 
use existing link state routing, without necessarily requiring 
configuration, to improve aggregate throughput, for RBridge to 
RBridge traffic. RBridges also may support IP multicast and IP 
address resolution optimizations. They are intended to be 
applicable to L2 network sizes similar to those of conventional 
bridges and are intended to be backward compatible with those 
bridges as both ingress/egress and transit. They also support 
VLANs (although this generally requires configuration) while 
otherwise attempting to retain as much 'plug and play' as is 
already available in existing bridges. This document proposes an 
architecture for RBridge systems as a solution to the TRILL 
problem, defines terminology, and describes basic components and 
desired behavior. One (or more) separate documents will specify 
protocols and mechanisms that satisfy the architecture presented 
herein.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-arch-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-trill-rbridge-arch-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

To: [email-masked]
From: [email-masked]
Date: Mon, 25 Feb 2008 16:30:01 -0800 (PST)
Cc: [email-masked]
Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-protocol-07.txt
Status: RO
Content-Length: 2031

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.

	Title		: Rbridges: Base Protocol Specification
	Author(s)	: R. Perlman
	Filename	: draft-ietf-trill-rbridge-protocol-07.txt
	Pages		: 84
	Date		: 2008-2-25
	
RBridges allow for optimal pair-wise forwarding with zero
   configuration, safe forwarding even during periods of temporary
   loops, and multipathing for both unicast and multicast traffic. They
   achieve these goals using IS-IS routing and encapsulation of traffic
   with a header that includes a hop count.

   RBridges are compatible with previous IEEE 802.1 bridges as well as
   current IPv4 and IPv6 routers and end nodes. They are as invisible to
   current IP routers as bridges are and, like routers, they terminate
   the bridge spanning tree protocol.

   The design supports VLANs and optimization of the distribution of
   multi-destination frames based on VLAN and IP derived multicast
   groups.  It also allows forwarding tables to be based on RBridge
   destinations (rather than end node destinations), which allows
   internal forwarding tables to be substantially smaller than in
   conventional bridge systems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-07.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-trill-rbridge-protocol-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Date: Mon, 25 Feb 2008 15:48:22 -0800
From: Radia Perlman <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] TRILL Use of IS-IS
Status: RO
Content-Length: 2197

I like this draft, which I'm just saying explicitly because in the past 
I've not been all that enthusiastic about options.

However, I'm still unconvinced about the need for critical options, but 
it doesn't seem that onerous to provide for them.

And as for the integrity protection option in the draft, (section 3.4), 
why not just protect the inner packet, which does not
get modified hop by hop? And furthermore, it seems like security ought 
to be end-to-end and not ingress-to-egress RBridge,
so I'm not sure how useful it is to provide it, especially if computing 
it is nontrivial.

As for congestion indication, or anything else (like flow ID), in theory 
we could provide for it in the main TRILL header, but
there would have to be room for it. Maybe eventually we could do a new 
version of the header that had some of the
options upgraded to be in the main header, and possibly shuffle the 
header along the lines Don proposed awhile ago (moving
the VLAN bits into the TRILL header, for instance.

Radia

Eastlake III Donald-LDE008 wrote:
> Hi,
>
> There is an individual submission draft posted at
> ftp://ftp.ietf.org/internet-drafts/draft-eastlake-trill-rbridge-isis-00.
> txt.
>
> This is essentially an intermediate draft between the TRILL base
> protocol draft and the expired Dave Ward draft on generic use of IS-IS
> for Layer 2 forwarding. An archived copy of the Ward draft is at
> http://www.watersprings.org/pub/id/draft-ward-l2isis-02.txt.
>
> The trill-rbridge-isis draft is intended to go with a -07 version of the
> base protocol specification which I hope will be posted by the deadline
> tomorrow however, the isis-00 and -07 protocol drafts may turn out to be
> slightly out of synch with each other. In any case, this isis draft is a
> -00 draft and probably needs work.
>
> Thanks,
> Donald
>
> ====================================================
>  Donald E. Eastlake 3rd      +1-508-786-7554 (work)
>  Motorola Laboratories
>  111 Locke Drive
>  Marlborough, MA 01752 USA
>  [email-masked]
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   

Content-class: urn:content-classes:message
Date: Mon, 25 Feb 2008 14:11:33 -0500
From: "Caitlin Bestler" <[email-masked]>
To: "James Carlson" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] TRILL Options
Status: RO
Content-Length: 2314

ECN-like bits *could* be defined in the RBridge header, but they
would not be necessary for *RBridge* functionality, but rather for
RBridges to provide this bonus info to the host stacks.

I would be perfectly happy with ECN-like bits being encoded in the
RBridge header, but I can't really make a case as to why the information
needs to be there rather than in options. Encoding it in the options
will work. If there is enough of a consensus that almost everyone
would find ECN-like reporting useful for RBridges then they could
be promoted, but like most of the other speculative options that
Donald listed, this is just an idea about something that seems likely
to be advantageous. It is not a concrete proposal that has been
prototype tested or anything like that.

> -----Original Message-----
> From: James Carlson [mailto:[email-masked]]
> Sent: Monday, February 25, 2008 10:36 AM
> To: Caitlin Bestler
> Cc: Eastlake III Donald-LDE008; [email-masked]
> Subject: Re: [rbridge] TRILL Options
> 
> Caitlin Bestler writes:
> > Not that the list of options described in this document needs to
> > be all inclusive, but I think there is one class of option at least
> > as probable as those cited here: a "pseudo-router" option.
> >
> > This option would allow an RBridge to report congestion as though
> > it were a router, by encoding what a ECN capable router would have
> > encoded -- but without requiring the RBridge to actually modify
> > L3 headers.
> 
> Why would it need to be an option?
> 
> Since we know about ECN now, why not just reserve a couple of bits for
> it, and allow the bridges that know how to mark properly do so?
> (Those that don't know how will just blindly forward the existing bits
> along, which is what you want for ECN anyway.  An ECN-incapable egress
> would just lose the bits.)
> 
> Perhaps I'm missing the point, but I think the only reason to have
> options is that there's something that requires inter-bridge
> cooperation.  If it doesn't require cooperation in order to achieve
> interoperability, then it doesn't need an option.
> 
> --
> James Carlson, Solaris Networking
> <[email-masked]>
> Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442
> 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442
> 1677

Date: Mon, 25 Feb 2008 13:35:33 -0500
From: James Carlson <[email-masked]>
To: Caitlin Bestler <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] TRILL Options
Status: RO
Content-Length: 1255

Caitlin Bestler writes:
> Not that the list of options described in this document needs to
> be all inclusive, but I think there is one class of option at least
> as probable as those cited here: a "pseudo-router" option.
> 
> This option would allow an RBridge to report congestion as though
> it were a router, by encoding what a ECN capable router would have
> encoded -- but without requiring the RBridge to actually modify 
> L3 headers.

Why would it need to be an option?

Since we know about ECN now, why not just reserve a couple of bits for
it, and allow the bridges that know how to mark properly do so?
(Those that don't know how will just blindly forward the existing bits
along, which is what you want for ECN anyway.  An ECN-incapable egress
would just lose the bits.)

Perhaps I'm missing the point, but I think the only reason to have
options is that there's something that requires inter-bridge
cooperation.  If it doesn't require cooperation in order to achieve
interoperability, then it doesn't need an option.

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Content-class: urn:content-classes:message
Date: Mon, 25 Feb 2008 13:04:28 -0500
From: "Caitlin Bestler" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] TRILL Options
Status: RO
Content-Length: 404

Not that the list of options described in this document needs to
be all inclusive, but I think there is one class of option at least
as probable as those cited here: a "pseudo-router" option.

This option would allow an RBridge to report congestion as though
it were a router, by encoding what a ECN capable router would have
encoded -- but without requiring the RBridge to actually modify 
L3 headers.

To: [email-masked]
From: [email-masked]
Date: Sun, 24 Feb 2008 10:45:01 -0800 (PST)
Cc: [email-masked]
Subject: [rbridge] I-D Action:draft-ietf-trill-prob-02.txt
Status: RO
Content-Length: 3664

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.

	Title           : Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement
	Author(s)       : J. Touch, R. Perlman
	Filename        : draft-ietf-trill-prob-02.txt
	Pages           : 16
	Date            : 2008-02-24

Current Ethernet (802.1) link layers use custom routing protocols 
that have a number of challenges. The routing protocols need to 
strictly avoid loops, even temporary loops during route propagation, 

 because of the lack of header loop detection support. Routing tends 
not to take full advantage of alternate paths, or even non-
overlapping pairwise paths (in the case of spanning trees). The 
convergence of these routing protocols and stability under link 
changes and failures is also of concern. This document addresses 
these concerns and suggests that they are related to the need to be 
able to apply modern network layer routing protocols at the link 
layer. This document assumes that solutions would not address issues 
of scalability beyond that of existing bridged (802.1D) links, but 
that a solution would be backward compatible with 802.1D, including 
hubs, bridges, and their existing plug-and-play capabilities. 

This document is a work in progress; we invite you to participate on 
the mailing list at http://www.postel.org/rbridge

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trill-prob-02.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-trill-prob-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-trill-prob-02.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trill-prob-02.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-trill-prob-02.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2008-02-24103837.I-D\@ietf.org>

--OtherAccess--

--NextPart--

Date: Sun, 24 Feb 2008 10:39:35 -0800
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] TRILL PAS update - 02 posted
Status: RO
Content-Length: 2719

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3D87D807078ECF3C58112EB1
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi, all,

The following addresses changes to the TRILL PAS. Note that there are=20
two current issues, neither of which is critical but both would be=20
useful to confirm (see notes below).

An updated ID has been posted and should appear shortly.

Joe

----------------------------------

1 Intro
   remove caveat about use of terminology; it was needed only while
   the doc was in process

2.2 convergence under reconfiguration
     remove question about timescales; this doc does not
     introduce the issue of convergence timescale in a new context

2.4 other ethernet extensions
     removed clarification question about 802.1v

     added note as to which extensions subsume others
     (D includes w, Q includes v and s)

3.1 no change to link capablities
     removed question about 802.1v (as per above)
     changed to lower-case v

3.3 forwarding loop mitigation
     remove question about serialized / unioned traces, noted
     that these terms not created by this doc

3.4 spanning tree management
     the need for pictures here is omitted; the point appears to
     have been sufficiently made without such pictures

3.5 multiple attachments
     removed the caveat that this section might be omitted

     CONSENSUS QUESTION: since no argument to the contrary has been made,=

     I would like to request a consensus check that this section
     should be retained

3.8 optimizations
     removed the assertion that more needs to be said here

     CONSENSUS QUESTION: since no argument to the contrary has been
     made, I would like to request a consensus check that this
     section should be used in its current form

3.9 internet architecture issues
     completed citation for router-router IGMP

5 security considerations
   completed citation for ipv6 secure nd

7 conclusions
   this section has been removed as it was vacuous and is not needed

ref 6
     removed ref to 802.1w, since it is in 802.1D;
     added note on 802.1D ref

     replaced rfc 2461 with rfc 4861

--------------enig3D87D807078ECF3C58112EB1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig3D87D807078ECF3C58112EB1--

Content-class: urn:content-classes:message
Date: Sun, 24 Feb 2008 10:06:39 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] TRILL Options
Status: RO
Content-Length: 451

An individual draft has been posted at
ftp://ftp.ietf.org/internet-drafts/draft-eastlake-trill-rbridge-options-
00.txt
for discussion. It gives an example of a more complete options
specification with some example specific options.

Thanks,
Donald
====================================================
 Donald E. Eastlake 3rd      +1-508-786-7554 (work)
 Motorola Laboratories
 111 Locke Drive
 Marlborough, MA 01752 USA
 [email-masked]

Content-class: urn:content-classes:message
Date: Sun, 24 Feb 2008 10:05:48 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] TRILL Use of IS-IS
Status: RO
Content-Length: 943

Hi,

There is an individual submission draft posted at
ftp://ftp.ietf.org/internet-drafts/draft-eastlake-trill-rbridge-isis-00.
txt.

This is essentially an intermediate draft between the TRILL base
protocol draft and the expired Dave Ward draft on generic use of IS-IS
for Layer 2 forwarding. An archived copy of the Ward draft is at
http://www.watersprings.org/pub/id/draft-ward-l2isis-02.txt.

The trill-rbridge-isis draft is intended to go with a -07 version of the
base protocol specification which I hope will be posted by the deadline
tomorrow however, the isis-00 and -07 protocol drafts may turn out to be
slightly out of synch with each other. In any case, this isis draft is a
-00 draft and probably needs work.

Thanks,
Donald

====================================================
 Donald E. Eastlake 3rd      +1-508-786-7554 (work)
 Motorola Laboratories
 111 Locke Drive
 Marlborough, MA 01752 USA
 [email-masked]

Content-class: urn:content-classes:message
Date: Fri, 22 Feb 2008 11:23:36 -0600
From: "Eric Gray" <[email-masked]>
To: "Eric Gray" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Proposed changes to the architecture based onIETF-70...
Status: RO
Content-Length: 4694

Folks,

	There was one other change I was asked to make at the last 
meeting.  There were comments about the fact that the Architecture
draft assumes IS-IS. Since this was the result of direction from
the working group chairs and ADs - as a consequence of removing the
"routing requirements" draft from the chartered goals - this was 
what I was supposed to do.  However, there was an action item I
did not realize I had picked up out of that discussion until just
now re-reading the minutes from the last meeting.

	The note was as follows:

"General opinion seemed to be that the architecture document should
 pull in some condensed routing requirements information and then
 have text saying 'looks like we are using IS-IS' or the like. 
 Should be such as to permit other protocols than IS-IS in the
 future."
_____________________________________________________________________

In addressing this note, I propose to add new text - after the 
following two paragraphs (in the the Introduction section):

"Peer information may be acquired via the routing protocol, or may be
 discovered as a result of RBridge-specific peer discovery mechanisms. 
 Details of specific peer information requirements - as well as how
 this information will be acquired is specified in protocol
 specifications (e.g. - [3]).  

"Topology information is expected to be acquired via the link-state
 routing protocol."

After the above paragraphs, I propose to add the following text:

"In addition to the requirement that the routing protocol should be 
 an existing link-state routing protocol, which possibly provides a 
 mechanism for (or re-use of an existing) neighbor/peer discovery, 
 the routing protocol should be able to work with minimal (or no) 
 configuration - using algorithmically derived addressing, for 
 example, assuming the use of addresses is required.

"Given the potential choices, IS-IS routing has been chosen at this
 time, and is assumed in this Architecture.  The fact that this is
 assumed in this architecture is - in no way - intended to preclude
 use of another link state routing protocol, or any other routing
 protocol, in any solution not described in this Architecture."

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eric Gray
> Sent: Friday, February 22, 2008 10:51 AM
> To: James Carlson
> Cc: [email-masked]
> Subject: Re: [rbridge] Proposed changes to the architecture 
> based onIETF-70...
> 
> James,
> 
> 	Also, from the minutes of the last meeting:
> 
> "Designated RBridge (DRB) text in architecture document doesn't follow
>  the protocol document in providing for DRB to assign encaps/decaps
>  role. It should describe the constraint - that the protocol must have
>  a mechanism so that a native frame is not encaps by more than one RB.
> 
> "Eric Gray: I'll change that."
> 
> Note that - while this part of the minutes provides an "encapsulated"
> (like the pun?) form of the actual discussion, and is sufficient to
> justify the need for the changes I proposed - it does not really do
> justice to the entire discussion.  Hopefully it is not actually going
> to be necessary to repeat the entire discussion at the next meeting.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: James Carlson [mailto:[email-masked]] 
> > Sent: Friday, February 22, 2008 9:48 AM
> > To: Eric Gray
> > Cc: [email-masked]
> > Subject: Re: [rbridge] Proposed changes to the architecture 
> > based on IETF-70...
> > Importance: High
> > 
> > Eric Gray writes:
> > > Several people pointed out that the architecture should 
> not assume a
> > > DRB election process will be used.  This is technically 
> correct, and
> > > - for that reason - not directly something that needs consensus to
> > > change, at least in theory.
> > 
> > Could someone please post the problem statement?  Besides 
> just making
> > the DRB election "optional," I think it'd be good to have a summary
> > statement of what problem is solved by making it possible to run
> > without DRB election.
> > 
> > (I'm guessing this was discussed somewhere ... but I wasn't able to
> > locate it in the archives.)
> > 
> > -- 
> > James Carlson, Solaris Networking              
> > <[email-masked]>
> > Sun Microsystems / 35 Network Drive        71.232W   Vox +1 
> > 781 442 2084
> > MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 
> > 781 442 1677
> > 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

Content-class: urn:content-classes:message
Date: Fri, 22 Feb 2008 09:51:12 -0600
From: "Eric Gray" <[email-masked]>
To: "James Carlson" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Proposed changes to the architecture based on IETF-70...
Status: RO
Content-Length: 1888

James,

	Also, from the minutes of the last meeting:

"Designated RBridge (DRB) text in architecture document doesn't follow
 the protocol document in providing for DRB to assign encaps/decaps
 role. It should describe the constraint - that the protocol must have
 a mechanism so that a native frame is not encaps by more than one RB.

"Eric Gray: I'll change that."

Note that - while this part of the minutes provides an "encapsulated"
(like the pun?) form of the actual discussion, and is sufficient to
justify the need for the changes I proposed - it does not really do
justice to the entire discussion.  Hopefully it is not actually going
to be necessary to repeat the entire discussion at the next meeting.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: James Carlson [mailto:[email-masked]] 
> Sent: Friday, February 22, 2008 9:48 AM
> To: Eric Gray
> Cc: [email-masked]
> Subject: Re: [rbridge] Proposed changes to the architecture 
> based on IETF-70...
> Importance: High
> 
> Eric Gray writes:
> > Several people pointed out that the architecture should not assume a
> > DRB election process will be used.  This is technically correct, and
> > - for that reason - not directly something that needs consensus to
> > change, at least in theory.
> 
> Could someone please post the problem statement?  Besides just making
> the DRB election "optional," I think it'd be good to have a summary
> statement of what problem is solved by making it possible to run
> without DRB election.
> 
> (I'm guessing this was discussed somewhere ... but I wasn't able to
> locate it in the archives.)
> 
> -- 
> James Carlson, Solaris Networking              
> <[email-masked]>
> Sun Microsystems / 35 Network Drive        71.232W   Vox +1 
> 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 
> 781 442 1677
> 

Content-class: urn:content-classes:message
Date: Fri, 22 Feb 2008 09:44:27 -0600
From: "Eric Gray" <[email-masked]>
To: "James Carlson" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Proposed changes to the architecture based on IETF-70...
Status: RO
Content-Length: 3460

James,

	I don't think "problem statement" is the real requirement
relating to this issue.  Speaking strictly from what shoud be 
included in an architectural overview, it is a FACT that there
is no architectural requirement that a DRB election process is
required (emphasis on "election") - or that there necessarily
must be a "designated RBridge" in any (unscoped) general sense.

	In a way, I might have been guilty of laziness because I
felt 1) it is obvious we are going to use some sort of election
process (why re-invent the wheel?) and 2) it seemed obvious -
based on continuing cycles of discussion - that we would most
likely end up using existing technical approaches to elect a
DRB for some reasonable VLAN-based, or interface-based, basis.

	The point was made that this is not necessarily a valid
assumption to make at the architectural level and that, at that
level, what is really needed is to spell out what is required.

	Having been called on my laziness, I agreed to spell out
what the architectural requirements - with respect to what is 
actually needed when more than one RBridge might act as the 
ingress and/or egress.

	They break down into two categories: 

1) why there should be - at least in some cases - a designated
   ingress and/or egress RBridge, under what general conditions
   this might be required and what are the limitations that we
   may expect to apply otherwise.
2) what the advantages and disadvantages are for using some 
   form of automated process for handling the scenarios where
   such a function is required - such as an election process -
   as opposed to some form of hardwired or configured approach.

	I believe the changes I've proposed effectively replace
the earlier assumption of a DRB election process with the more
complicated architectural requirements that - in the end - are
very likely going to justify using a DRB election process.

	I guess - as nearly as I can define such a thing - the
"problem statement" is this:  in a general sense, there is no
particular reason why a DRB election process would be needed
in every possible solution to the TRILL problem space.  As I
have since learned, this breaks down into the 2 specific areas
listed above - i.e. - why "election", and why "DRB"?

	Hopefully this helps...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: James Carlson [mailto:[email-masked]] 
> Sent: Friday, February 22, 2008 9:48 AM
> To: Eric Gray
> Cc: [email-masked]
> Subject: Re: [rbridge] Proposed changes to the architecture 
> based on IETF-70...
> Importance: High
> 
> Eric Gray writes:
> > Several people pointed out that the architecture should not assume a
> > DRB election process will be used.  This is technically correct, and
> > - for that reason - not directly something that needs consensus to
> > change, at least in theory.
> 
> Could someone please post the problem statement?  Besides just making
> the DRB election "optional," I think it'd be good to have a summary
> statement of what problem is solved by making it possible to run
> without DRB election.
> 
> (I'm guessing this was discussed somewhere ... but I wasn't able to
> locate it in the archives.)
> 
> -- 
> James Carlson, Solaris Networking              
> <[email-masked]>
> Sun Microsystems / 35 Network Drive        71.232W   Vox +1 
> 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 
> 781 442 1677
> 

Date: Fri, 22 Feb 2008 09:48:12 -0500
From: James Carlson <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Proposed changes to the architecture based on IETF-70...
Status: RO
Content-Length: 806

Eric Gray writes:
> Several people pointed out that the architecture should not assume a
> DRB election process will be used.  This is technically correct, and
> - for that reason - not directly something that needs consensus to
> change, at least in theory.

Could someone please post the problem statement?  Besides just making
the DRB election "optional," I think it'd be good to have a summary
statement of what problem is solved by making it possible to run
without DRB election.

(I'm guessing this was discussed somewhere ... but I wasn't able to
locate it in the archives.)

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Content-class: urn:content-classes:message
Date: Thu, 21 Feb 2008 10:44:49 -0600
From: "Eric Gray" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Proposed changes to the architecture based on IETF-70...
Status: RO
Content-Length: 18900

Folks,

Several people pointed out that the architecture should not assume a
DRB election process will be used.  This is technically correct, and
- for that reason - not directly something that needs consensus to
change, at least in theory.

Before going into specific proposed changes, I would like to mention
(in passing) why this is not a trivial change - as I explicitly said
during the meeting.  In fact, the reason why use of DRB election is
assumed in the protocol specification are manifold and - by not making 
the same assumption in the architecture - we task the architecture 
with the onus of expressly stating the reasons why any protocol 
specification will almost certainly need to use a DRB election.  This
is quite arguably an appropriate task for the architecture document,
which does nothing to make it easy.

Interestingly enough, most people did not see this as all that hard
to do.  One or two people even offered to help.  Below is what we've 
come up with.  Given the shortage of time, my default assumption is
that these changes should be incorporated in a version to be posted
by the dead-line next Monday.
______________________________________________________________________

At a high level, any solution needs not only to deal with ingress and
egress of frames traversing the RBridge Campus in the normal case, it
must aslo deal with the folowing exception cases:

o	receiving a frame from an end station previousy not heard from,
o	flooding frames for unknown destinations,
o	broadcast of frames to reach all possible end stations - known
	or unknown.

In short it is not simply a matter of determining which RBridge it is
that forwards frames in each specific case, it is also a matter of
determining which RBridge learns and floods in each specific case -
where one has to recognize that it is not always going to be the case
that RBridges have a priori knowledge required to make a determination
in some arbitrary and as yet undefined determination process.

Also, the method of selecting which RBridge is responsible for all of
the above cannot be completely arbitrary.  As it turns out, in order 
to maintain compatibility with 802.1Q (or 802.1D) bridges, RBridges
must handle ingress onto and egress off of the RBridge Campus in a
way that is consistent within a consistent forwarding context used by
any local bridges that may be present.

And - of course - there is always the consideration of which RBridge
sends routing
advertisements._________________________________________________________
_____________

Anyway, on to the specific issues and proposed changes...
----------------------------------------------------------------------
So, here are the issues, and my proposed changes to account for them.
______________________________________________________________________

First, there is the definition of Designated RBridge.  The definition 
needs to remain, but it must be changed to reflect the fact that this 
is merely one way to handle the issue(s) addressed using a DRB.

I propose a replacement definition as follows:

"Designated RBridge (DRB): one approach to resolving several issues 
 associated with having multiple RBridges as candidate ingress and
 egress points from a single LAN is to designate an RBridge to act 
 as the ingress and egress in that case.  The RBridge designated
 to handle ingress and egress traffic to a specific Ethernet link 
 (or VLAN associated with that link), having shared access and 
 multiple RBridges is such a link's "Designated RBridge", or DRB. A 
 Designated RBridge may (for example) be determined by an election 
 process among those RBridges having shared access via a single LAN,
 or may be selected by some other means."
______________________________________________________________________

Also, the definition of Encapsulation Database contains a (what is - 
in retrospect - probably innappropriate) use of Designated RBridge. 

I propose a litteral replacement of - 

	"Designated RBridge (ingress)" 

- with - 

	"Ingress RBridge"
______________________________________________________________________

Section 4.1 has two problem areas.  In the second paragraph, the use
of DRB as the the primary point of attachment for an end station is
assumed.  I propose modification as follows:

"At an architectural level, it is sufficient to note that every end 
 station attached to a TRILL Campus should have a primary point of
 attachment to the TRILL Campus, as might be defined (for example)
 by a Designated RBridge. Furthermore, if it is possible that there
 are 802.1Q (or 802.1D) bridges in a local LAN, the association of 
 specific RBridges and the end stations to which they act as primary
 point of attachment must be determined in a way that is consistent
 with forwarding in an 802.1Q (or 802.1D) network.  If a DRB election 
 process were used, each TRILL Link (or VLAN group within a TRILL 
 Link) attached to a TRILL Campus would have a single Designated 
 RBridge (either for the link, or for a subset of the VLANs on the 
 link); using DRBs as an example, the DRB would be where all traffic 
 intended to transit a TRILL Campus enters and exits.

"Other approaches might be used as well.  For example, the primary 
 point of attachment for each end-station might be configured, or 
 determined in some other way, on a per end station basis.  Any
 such approach must either allow for the possibility of LAN bridges
 or not be used when such a possibility exists."

The last paragraph in section 4.1 ("TRILL Campus Auto-configuration")
specifically includes DRB election.  I propose a small modification 
to read as follows:

"High-level steps that may be included in auto-configuration are: 
 RBridge peer discovery, topology discovery, determination of end 
 station primary points of attachment (DRB election, for example), 
 learning and forwarding (tunneling) TRILL encapsulated frames."
______________________________________________________________________

Section 4.4 needs to be re-written (and re-titled). I propose:

"4.4. Determination of End Station Primary Points of Attachment

"The mechanisms and details of how end stations are associated with
 a specific Rbridge - when multiple RBridges are available - for the
 purpose of providing ingress to and egress from the RBridge Campus,
 will be provided by protocol specification(s). A potential approach
 to be considered is the use of a 'Designated RBridge Election', on
 either a per link, or per VLAN (set) basis.

"Architecturally, it is important to note that this determination 
 must be based on an accurate view of the topology, including the
 availability of certain links in a given topology for traffic 
 associated with any given VLAN.  Otherwise, it is possible to 
 partition a TRILL Link-local LAN (assuming that RBridge may be 
 deployed and configured to replace existing 802.1Q bridges) as a 
 result of a failure - under circumstance in which such a partition 
 would not have occurred with previously deployed 802.1Q bridges.

"Protocol specification(s) need to define how accurate VLAN topology 
 is to be determined and applied in determination of end station 
 primary points of attachment. Protocol specification(s) also need 
 to state the limitations that any chosen mechanisms may impose on 
 the solution (in terms of scalability and ease of deployment, for 
 example). Finally protocol specification(s) need to describe how
 determination is made with respect to which RBridge is responsible
 for learning new end station information, and for the flooding and 
 broadcast frames for reaching known and unknown end stations on any
 link or VLAN."
______________________________________________________________________

Section 5.1 use the expression "Designated RBridge Election" in the
first paragraph.  I propose to replace the first paragraph with:

"As described in sections above, operations that apply to all 
 RBridges include peer and topology discovery (including hello 
 messaging, negotiation of RBridge identifiers and link-state 
 routing), determination of RBridge primary point of attachment
 (for local end stations - possibly via DRB election), shortest 
 path (SPF) computation and either learning or advertising L2 
 MAC Ethernet destination reach-ability for addresses within a 
 broadcast domain."
______________________________________________________________________

Section 5.2 is intended to describe architectural considerations
that apply to ingress and egress operations.  These include how
learning is expected to occur, and how forwarding onto and off of
the RBridge Campus occurs.  As such, the section is closely tied
in with the presumption of using a DRB (as elected or otherwise
determined).  One solution to this issue would have been to make
the term DRB - in this document - apply effectively on a per end
station basis (however complicated this might seem, it is what we
must consider to be the minimalist architectural requirement). 

In order to avoid confusing use of the term DRB, however, I would 
rather not use that approach (and have not done so in my proposed 
changes thus far).  Instead, I propose changing several of the
paragraphs of section 5.2 to read as follows:
______________________________________________________________________

"5.2.Ingress/Egress Operations

"Operation specific to edge RBridges involves RBridge learning, 
 advertisement, encapsulation and decapsulation (at ingress and
 egress RBridges, respectively).

"As described previously, RBridge learning is similar to typical 
 bridge learning - i.e. - RBridges listen promiscuously to L2 
 Frames on each local LAN and acquire end station location 
 information associated with source MAC addresses in L2 frames 
 they observe.

"If multiple RBridges are available, a determination must be made
 as to which RBridge is the primary point of attachment for each
 end station (or end stations by groups - using, for example, the
 VLAN associations of VLAN aware end stations) requiring ingress 
 and egress services from an RBridge campus.  This is a minimal 
 requirement, and there is no reason why this same determination 
 might not be made in all cases, even including a degenerate case 
 in which only one RBridge may be used.  This would be the case, 
 for instance, if DRB election is done in all case, including when 
 the DRB can only be the one and only RBridge to which local end 
 stations might be attached.  

"In the degenerate case - where only one RBridge is connected to a 
 specific Ethernet LAN - obviously that RBridge will be (or become)
 the primary point of attachment for local end stations requiring
 ingress/egress services from the RBridge Campus.

"Minimally, only the RBridge determined as the primary point of 
 attachment for a given (set of) end station(s) is required to
 performs RBridge learning for that (set of) end station(s) while 
 they remain associated with interface(s) connected to the local 
 LAN or VLAN.

"Note that - in some cases - the determination of primary points
 of attachment and learning may be tightly bound operations.  This 
 might be the case if - for example - the determination is based 
 on litteral configuration of end station and RBridge attachments.
 In other cases, learning would occur in a more conventional - and
 flexible way - if (for example) an automated process of selecting 
 a DRB (such as DRB election) is used on  a per link or per VLAN 
 (set) basis.

"Assuming learning is required by a specific solution described in
 any protocol specification(s), as RBridges learn segment-local MAC 
 source addresses, ..."

 - and further on -

"... to limit the scope of advertisement flooding.

"If it is desired - in any specific solution - to support discovery
 of new end station attachments, RBridges may also discover that a
 new end station has become locally attached (for which they may be
 or become an edge RBridge) as a result of receiving un-encapsulated 
 frames that require forwarding.  Any such solution must specify how
 a primary end station point of attachment is determined when this
 occurs.  Several possible approaches exist.  

"If an automated DRB selection process (such as DRB election) is the 
 approach in use for a specific solution (on a per link or per VLAN 
 basis), this determination is automatic for any specific link or 
 VLAN on a local link. If an RBridge is the Designated RBridge for a 
 local link or VLAN, and has not previously learned that the MAC 
 destination for a frame is local (this could be the case for the 
 very first frame an RBridge observes), then the RBridge could be 
 required to forward (or flood) the frame  via the TRILL Campus to 
 all other RBridges (potentially within a VLAN scope). 

"Protocol specifications intended to support recognition of new end
 station attachments must specify how the determination of a primary 
 point of attachment is to be accomplished for newly discovered end
 stations.

"When a frame is received which must be forwarded across the RBridge
 Campus, the responsible RBridge would flood the frame unless it has 
 already created a Unicast TRILL Forwarding Database entry for the 
 frame's MAC destination address.  If it has a corresponding Unicast 
 TRILL Forwarding Database entry, then it would use that.  The 
 RBridge in this instance would be an ingress RBridge for the frame 
 being forwarded across the RBridge Campus.

"The encapsulation used by this ingress RBridge would be determined 
 by the Unicast TRILL Forwarding Database - if one exists - or the 
 Unicast TRILL Forwarding Database-equivalent entry for the RBridge 
 Distribution Tree.

"When the encapsulated frame arrives at egress RBridge(s), it is 
 decapsulated and forwarded via the egress interface(s) onto the 
 local link (or VLAN on the local link).

"In using the approach of learning from the data plane, the egress 
 RBridge stores information related to content of the frame's TRILL
 encapsulation for use in subsequent reverse traffic in a manner
 directly analogous to bridge learning.

"Note that an egress RBridge will - in most cases - be the RBridge 
 determined to be the primary point of attachment for a destination 
 end station on the local LAN or VLAN accessed via its egress 
 interface(s).  Exceptions to this might exist under circumstances
 in which use of distinct RBridges for ingress and egress for a
 common (set of) end station(s) does not produce local forwarding
 ambiguity.  Any protocol specification that allows this must also
 unambiuously describe the precise circumstances under which it is
 allowed - as well as the limitations and issues this introduces
 in the solution specified.

"Also note that any specific solution in protocol specification(s) 
 will need to document how determination of an end station primary 
 point of attachment (RBridge) occurs for the case where a specific 
 end station has not yet been discovered at any egress or egress 
 interface - except under circumstances where support of discovery 
 of new end stations is not supported, or explicitly disallowed.  
 In the example in which a DRB election is used, this determination 
 should be both trivial and automatic. In an approach where an end 
 station and RBridge attachment/association is configured, this
 should also be relatively obvious - if inflexible.

"For the DRB example, if the destination MAC of a received frame 
 does not correspond to a learned MAC destination address at a
 specific egress interface, the DRB will forward the frame on all 
 interfaces for which it is the designated RBridge.  If a received 
 frame does correspond to a learned MAC destination address at some 
 specific egress interface, the DRB will forward the frame via that 
 interface only.

"Any specific solution's protocol specification should also allow 
 for the fact that flooded frames may arrive at a single local LAN
 (or VLAN) where local end stations may be attached via multiple
 RBridges, and properly account for how the determination of which
 RBridge is exclusively responsible for forwarding such frames is 
 to be made.  This is essential to avoid having the same frame being 
 delivered at local bridge interfaces multiple times and potentially 
 from widely disparate directions (i.e. - on different interfaces of
 individual bridges)."
______________________________________________________________________

Section 5.3.2.1 ("Broadcast" - under 5.3.2 "Broadcast, Multicast and 
Flooding", under 5.3 "Transit Forwarding Operations"), since all 
broadcast traffic is explicitly intended to reach every attached end
station (known or unknown), contains a few peripheral ties to the
use of DRB.  In a way that is very similar to proposed replacement
text in section 5.2, using any approach other than DRB has some very
extreme complications associated with it for the broadcast case (the
unkown case is already identified and addressed explicitly in the
proposed replacement text above). I propose the following change:

Replace the fourth, fifth and sixth paragraphs with the following 4 
paragraphs -

"Note that an interface over which an RBridge may egress frames is 
 any interface for which the RBridge is the primary point of end
 station attachment for one or more end stations, or the RBridge
 determined to be responsible for broadcast delivery. 
 
"RBridges must not wait to determine that one (or more) Ethernet 
 end stations are present on an interface before deciding to forward
 decapsulated broadcast frames on that interface.  An exception case
 would exist if RBridges have been configured to treat a local link
 as a point to point connection between two RBridges, or otherwise
 configured to ignore the possible presence of end stations in this 
 case.

"Forwarding information is selected for each broadcast frame received
 by any RBridge (based - for example - on identifying the ingress 
 RBridge for the frame) for all corresponding Multi-destination TRILL
 Forwarding Database entries. Each RBridge may thus be required to
 replicate one RBridge encapsulated broadcast frame for each interface
 that is determined from Multi-destination TRILL Forwarding Database
 entries corresponding to the frame's ingress RBridge. This includes
 decapsulated broadcast frames for each interface for which the 
 RBridge is responsible for egressing broadcast frames (as might have
 been determined previously by DRB election, for example).

"Note that frame replication and forwarding should be scoped by VLAN
 if VLAN support is provided. Also note that an egress RBridge may 
 be required to transmit a decapsulated frame on the same interface
 on which it received the RBridge encapsulated frame."
______________________________________________________________________

And, of course, after making these changes, update the TOC...

--
Eric Gray
Principal Engineer
Ericsson 

Date: Wed, 20 Feb 2008 21:28:09 -0800
From: Radia Perlman <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Last Consensus Confirmations from Vancouver Meeting
Status: RO
Content-Length: 2733

That was my understanding on both points.

Radia

Eastlake III Donald-LDE008 wrote:
> There were two consensuses in the TRILL meeting in Vancouver that were
> posted (perhaps not too articulately) to this list for verification and
> are pasted at the end of this message. There has been discussion of
> these topics on the list and the overall consensus of the working group
> is that (1) there should be a way in TRILL to configure an Rbridge port
> such that end-station/native frames are not sent on that port and any
> received are discarded and (2) there should not be a way in TRILL to
> configure an Rbridge port such that it uses a global fixed source and
> destination MAC address as being a port to a point-to-point link to
> another Rbridge.
>
> Donald & Erik
>
>
>
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Monday, January 07, 2008 1:34 PM
> To: [email-masked]
> Subject: [rbridge] Consensus Check: Configure ports to disable end
> station traffic
>
> This is a check via the mailing list to confirm or refute an apparent
> consensus at the Vancouver meeting taken from the minutes of that
> meeting:
>
>            Currently broadcast, unknown unicast, and
>       non-IP-derived multicast frames are output to all links. This is
>       wasteful if there are no end stations on the link. Provide that
>       a port can be configured so as to be disabled for end station
>       traffic.
>
> If no particular controversy arises over this in the next three weeks,
> We will declare it to be the working group consensus.
>
> Thanks,
> Donald & Erik
>
>
>
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Wednesday, January 09, 2008 11:27 PM
> To: [email-masked]
> Subject: [rbridge] Consensus Check: Against P2P Fixed Addresses Proposal
>
> This is a check via the mailing list to confirm or refute an apparent
> consensus at the Vancouver meeting taken from the minutes of that
> meeting:
>
> 		Against the proposal presented at IETF-70
>       for p2p link configuration permitting a fixed source and
>       destination address.
>
> If no particular controversy arises over this in the next three weeks,
> We will declare it to be the working group consensus.
>
> Thanks,
> Donald & Erik
>
> ====================================================
>  Donald E. Eastlake 3rd      +1-508-786-7554 (work)
>  Motorola Laboratories
>  111 Locke Drive
>  Marlborough, MA 01752 USA
>  [email-masked]
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   

Content-class: urn:content-classes:message
Date: Wed, 20 Feb 2008 20:40:03 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] On 802.1 Registration Protocols
Status: RO
Content-Length: 4328

IEEE 802.1D defines a general attribute registration protocol (GARP). A
block of 16 multicast addresses is reserved for different applications
of this protocol but only two applications have been defined:
registration of multicast addresses (GARP Multicast Registration
Protocol, GMRP) and registration of VLANs (GARP VLAN Registration
Protocol, GVRP (specified in 802.1Q)). These protocols, speaking very
generally, allow a bridge or end station to send a frame which indicates
that it wishes to received traffic for a particular multicast group or
VLAN or no longer wishes to receive such traffic. The initial version of
this allowed only one attribute per request frame but 802.1Q has been
amended to require a different format for these messages which can
encoding multiple attributes per frame. The amended version is called
multiple registration protocol, MRP, and the two applications, when
using MRP frames, are called MMRP and MVRP.

802.1 bridges which don't understand GARP/MRP frames are required to
forward them like other multicast frames.

One could imagine various extremely complex interactions between
Rbridges and such GARP/MRP messages. But I think we want to make Rbridge
interactions with GARP/MRP that are specified in TRILL as simple as
reasonably possible given the constraint that bridges should be
incrementally replaceable with Rbridges in realistic scenarios.

The current base protocol draft says that such registration frames are
treated like any other non-IP-derived multicast. I think this works well
enough for multicast registration frames (multicast address
01-80-C2-00-00-20), which are rarely used in practice, and for the 14
reserved registration protocol multicast addresses (01-80-C2-00-00-22
through 01-80-C2-00-00-2F). Frames treated this way are VLAN constrained
and no worse than a broadcast frame.

However, just treating a VLAN registration frame like other
non-IP-derived multicast seems, to me, to have serious problems.
	The 802.1 standard prohibits VLAN tags on native VLAN
registration frames and, since the purpose of such frames is frequently
to turn on connectivity for a VLAN, it would make no sense to consider
their distribution to be VLAN constrained. However, if VLAN registration
frames are just flooded without VLAN constraint, they become, in effect,
super-broadcast frames that could easily be used for denial of service.
In fact, since VLAN connectivity information for Rbridges is flooded via
IS-IS, it is not clear there is any need to forward VLAN registration
frames between them at all.
	VLAN registration is not useful for Rbridge-to-Rbridge links but
could be useful if sent to bridges and useful at an ingress Rbridge port
if that port is configured to allow dynamic VLAN registration, which is
the recommended default configuration for 802.1Q ports (except for VLAN
1 which is fixed enabled in the default).
	In principal, VLAN registration frames could be recognized by
end stations; but use of them in that way is fairly rare. My opinion is
that it would be OK to require configuration at an Rbridge to get it to
send such frames on a port where it does not see a bridge.

So my current thought is that Rbridges which receive a VLAN registration
frame and which are configured to pay attention to such frames (which
would be the recommended default, as it is with 802.1Q bridges) should,
for VLANs which are set to dynamic registration (which should be the
recommended default, as it is with 802.1Q bridges), run the registration
state machine and appropriately enable/disable VLAN output on that port.
	This VLAN enablement status will be flooded to all other
Rbridges in the link state database so there is no need to encapsulate
or forward or generate VLAN registration frames between RBridges.
	Rbridges that see a bridge out a port should send MVRP messages
to that bridge. Of course, it should be possible to configure them per
port to not send such messages or to send them on ports where they do
not see a bridge (presumably end station ports). Perhaps they should
also be configurable to alternatively send the older GVRP messages.

Donald
====================================================
 Donald E. Eastlake 3rd      +1-508-786-7554 (work)
 Motorola Laboratories
 111 Locke Drive
 Marlborough, MA 01752 USA
 [email-masked]

Content-class: urn:content-classes:message
Date: Wed, 20 Feb 2008 20:32:53 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Last Consensus Confirmations from Vancouver Meeting
Status: RO
Content-Length: 2379

There were two consensuses in the TRILL meeting in Vancouver that were
posted (perhaps not too articulately) to this list for verification and
are pasted at the end of this message. There has been discussion of
these topics on the list and the overall consensus of the working group
is that (1) there should be a way in TRILL to configure an Rbridge port
such that end-station/native frames are not sent on that port and any
received are discarded and (2) there should not be a way in TRILL to
configure an Rbridge port such that it uses a global fixed source and
destination MAC address as being a port to a point-to-point link to
another Rbridge.

Donald & Erik

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Monday, January 07, 2008 1:34 PM
To: [email-masked]
Subject: [rbridge] Consensus Check: Configure ports to disable end
station traffic

This is a check via the mailing list to confirm or refute an apparent
consensus at the Vancouver meeting taken from the minutes of that
meeting:

           Currently broadcast, unknown unicast, and
      non-IP-derived multicast frames are output to all links. This is
      wasteful if there are no end stations on the link. Provide that
      a port can be configured so as to be disabled for end station
      traffic.

If no particular controversy arises over this in the next three weeks,
We will declare it to be the working group consensus.

Thanks,
Donald & Erik

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Wednesday, January 09, 2008 11:27 PM
To: [email-masked]
Subject: [rbridge] Consensus Check: Against P2P Fixed Addresses Proposal

This is a check via the mailing list to confirm or refute an apparent
consensus at the Vancouver meeting taken from the minutes of that
meeting:

		Against the proposal presented at IETF-70
      for p2p link configuration permitting a fixed source and
      destination address.

If no particular controversy arises over this in the next three weeks,
We will declare it to be the working group consensus.

Thanks,
Donald & Erik

====================================================
 Donald E. Eastlake 3rd      +1-508-786-7554 (work)
 Motorola Laboratories
 111 Locke Drive
 Marlborough, MA 01752 USA
 [email-masked]

Content-class: urn:content-classes:message
Date: Thu, 14 Feb 2008 00:17:07 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Consensus Confirmed: Pseudonode suppression
Status: RO
Content-Length: 1055

The following consensus from the Vancouver meeting has been confirmed.

Donald & Erik

PS: There has been a lot of discussion of this but it doesn't affect
whether to move it out of the base protocol specification or not.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Thursday, January 03, 2008 2:14 PM
To: [email-masked]
Subject: [rbridge] Consensus Check: Pseudonode suppression

This is a check via the mailing list to confirm or refute an apparent
consensus at the Vancouver meeting taken from the minutes of that
meeting:

   Move the Pseudonode suppression provisions
      out of the TRILL base protocol specification into a document
      closer to IS-IS.

If no particular controversy arises over this in the next three weeks,
We will declare it to be the working group consensus.

Thanks,
Donald & Erik

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

Content-class: urn:content-classes:message
Date: Wed, 13 Feb 2008 23:51:29 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Consensus Confirmed: Milestone Move
Status: RO
Content-Length: 864

The following consensus from the Vancouver meeting has been confirmed.

Donald & Erik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Wednesday, January 09, 2008 11:46 PM
To: [email-masked]
Subject: [rbridge] Consensus Check: Milestone Move

This is a check via the mailing list to confirm or refute an apparent
consensus at the Vancouver meeting taken from the minutes of that
meeting:

		Move milestones to March 2008 for Problem
      Statement and Architecture document.

If no particular controversy arises over this in the next three weeks,
We will declare it to be the working group consensus.

Thanks,
Donald & Erik

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

Content-class: urn:content-classes:message
Date: Wed, 13 Feb 2008 23:50:07 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Consensus Confirmed: Allow GVRP/MVRP
Status: RO
Content-Length: 848

The consensus below from the Vancouver meeting is confirmed.

Donald & Erik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eastlake III Donald-LDE008
Sent: Monday, January 07, 2008 1:36 PM
To: [email-masked]
Subject: [rbridge] Consensus Check: Allow GVRP/MVRP

This is a check via the mailing list to confirm or refute an apparent
consensus at the Vancouver meeting taken from the minutes of that
meeting:

      Remove any text prohibiting implementation
      of GVRP or MVRP on RBridges.

If no particular controversy arises over this in the next three weeks,
We will declare it to be the working group consensus.

Thanks,
Donald & Erik

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

Date: Mon, 11 Feb 2008 19:29:16 -0800
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Revisiting the TRILL header
Status: RO
Content-Length: 1255

Now that people are getting into implementing TRILL...

An implementor said that he found looking beyond the options for things 
like VLAN and destination address
in the inner header annoying.

Don Eastlake had proposed a format moving the VLAN and destination 
address into the TRILL header (and removing
them from the inner packet). I liked it at the
time and still do, and thought I'd give it one more chance on the 
mailing list.

The format that the implementor proposed was that without options, all 
that would change is that the
Ethertype would be removed from the 802.1q tag, so the format would be

current header + Ethernet DA + Ethernet SA + 16 bits of VLAN info 
(priority, drop eligibility, VLAN tag) + options (if any) +
rest of packet.

The arguments, I think, were that then core RBridges don't have to look 
beyond the TRILL header, and also,
that the core RBridges don't have to understand both Ethertypes (IEEE 
changed the Ethertype on the VLAN tag when
changing the meaning of the "format indicator" bit to "drop eligibility".

Can other people who are implementing this comment on:
a) whether changing the header at this point is really a problem, even 
if it were a good idea, and
b) whether this is a good idea.

Thanks,

Radia

Content-class: urn:content-classes:message
Date: Sat, 2 Feb 2008 01:39:14 -0000
From: "Thomas, Matthew R" <[email-masked]>
To: "Thomas, Matthew R" <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] FW:  Pseudonode minimization thoughts...
Status: RO
Content-Length: 11027

In terms of threshold,

For OSPF a variable would be most useful. The ability to set it to say 5
as standard and then reduce to 3 as described from time to time would be
most useful. One of the advantages of this proposal is that the values
can be set differently from LAN to LAN without a problem, and there is
no requirement to upgrade all of your routers /Rbridges at the same
time.

MT

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Thomas, Matthew R
Sent: 02 February 2008 01:02
To: [email-masked]
Cc: [email-masked]
Subject: [rbridge] FW: Pseudonode minimization thoughts...

Hi Radia,

Adding v quick tutorial as suggested... 

I have been involved in looking at this for a bit, but your original
solution is significantly more elegant, backwardly compatible, only 2
flags to add etc etc, than ospf-lite and more elegant.

Here is a summary as requested of the general discussion / explanation
from people so far. I hope I do them justice.. please forgive any errors

OSPF language (appologies if anyone not interested)
***************************************************************

Ospf works in a very similar way to ISIS. Two types of LSA are
generated. OSPF type 1 (router) you would refer to as a normal ISIS LSP.
Our type 2 (Network-LSA) is as your pseudonode LSP.

Our type 1 (router LSA) is very similar to your standard LSP. There are
a few oddities. Here is the main one I think: a point-to-point line has
two entries:

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 2.2.2.2
     (Link Data) Router Interface address: 172.16.1.1
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 172.16.1.0
     (Link Data) Network Mask: 255.255.255.252
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

This is a point-to-point line from this router (ID 1.1.1.1) to the
neighbour 2.2.2.2 The point-to-point line has local IP address
172.16.1.1. It is reported TWICE in the packet. Once as a point-to-point
line and then a second time to attach the IP network. This is all to
allow an IP unnumbered interface if required. If unnumbered then the
interface in the first block of text is represented by an MIB value.

Radia et al plan, configured for OSPF:
**************************************

1.) Use ospf LLS datablock Extended options to locate 2 flags.
2.) One flag (called NS-Bit) signifies to the other neighbors, the
compatability with the reduction draft.
3.) DR gets elected and Pseudonode LSP (Network-LSA) is not generated by
DR yet.
4.) DR signals to neighbors to move to pseudonode reduction using second
flag (SS-Bit).
5.) Neighbors set SS-Bit flag in accordance to signify acceptance.
6.) Router LSA (ISIS normal LSP) shows to the OUTSIDE world a network
type of "point-to-multipoint." Represented as lots of Point-to-point
lines (see below for example
7.) Routers actually operate on the LAN using DR as normal.

However! we already have a special network type called
point-to-multipoint that actually reduces the Network LSA anyway. So is
the problem solved already? Well partly...

Here are the problems not currently solved by P2MP (Point-to-multipoint)
alone (as I see it):
*****************************************************************

Problem 1: P2MP cant be configured as default, (to avoid configuration
issues). This is because a further router might be added to the network
that isn't configured to support point-to-multipoint. The hellos would
not match and the neighbour would not be established. This is the
current state.

Problem 2. We cant add flags to dynamically change the network to
point-to-multipoint, (on its own without your proposal) because if we
did then the  DR is removed (as P2MP doesn't use one), so cant change
BACK if another router is added that doesn't support
point-to-multipoint. (same problem as above).

Both of these problems are solved by continuing to use DR as normal, but
advertising in the router LSA's the "point-to-multipoint" option, which
looks like this below: This LSA is generated by router IS 1.1.1.1 and
the neighbors listed are 2.2.2.2, 3.3.3.3, and the network in question
is 192.168.1.0 255.255.255.0

  LS Type: Router Links
  Link State ID: 1.1.1.1
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000002
  Checksum: 0xB5ED
  Length: 60
   Number of Links: 3

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 2.2.2.2
     (Link Data) Router Interface address: 192.168.1.1
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 3.3.3.3
     (Link Data) Router Interface address: 192.168.1.1
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 192.168.1.1
     (Link Data) Network Mask: 255.255.255.255 << note mask is 32
      Number of TOS metrics: 0
       TOS 0 Metrics: 0

Matthew Thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: 01 February 2008 18:48
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Pseudonode minimization thoughts...

Here's a compromise proposal.

My goals:
a) no configuration required
b) no pseudonode if you have no router neighbors on the link (whether or

not there are endnodes).
c) avoid pseudonodes if easy to do so (explain in a minute) when there 
are just 2 routers (with perhaps endnodes)

Before Mike's arithmetic, I was thinking that pseudonodes weren't 
valuable until maybe 10 neighbors, and just was
embarrassed about the whole pseudonode thing in this brave new world 
where "Ethernets" are usually pt-to-pt links, but
now I think it's fine to simply *always* get rid of pseudonodes in the 
case of one router, and *almost always* in the case of
just two routers.

So, here's the proposal:
a) do not report a pseudonode unless there is at least one *IS* 
adjacency. This eliminates my nightmare of an unconfigured
RBridge with 1000 ports, each with one endnode on it, reporting 1000 
pseudonodes. (Les confirmed my nightmare, that
all it takes is a single ES adjacency on a port and IS-IS today would 
create a pseudonode for that port. We *really* have to
fix that case, and without requiring configuration)
b) if there is just one IS adjacency, and you are the DR, and your other

IS is cool with this feature (as signalled in its Hello), don't use a 
pseudonode.
Just have each of the two IS's report a link to the other.
If your neighbor IS isn't cool with it, go ahead and make an adjacency. 
(Note: for TRILL, I'd hope we'd put this feature in from the
start, so that all RBridges would be cool with this, so that is simple)
c) if there are ever 2 IS adjacencies on the port, create a pseudonode 
*and remember, as long as you are up,
that this link should have a pseudonode as long as there is at least one

IS adjacency*. In other words,
this is not really a pt-to-pt link, and it won't be wasteful to keep the

link with a pseudonode because there might be other
IS's that will come up in the future. I would drop the pseudonode (in 
the case of TRILL especially, maybe not for CLNP),
if there is ever no other IS adjacencies.

This is kind of like the original proposal but with the threshold of "1"

and "3" rather than "2" and "5", except once you hit 3, the
threshold becomes "1" and "2". So in this case R1 would do the following
a) no IS neighbors: no pseudonode. R1 reports nothing about that port in

its LSP, and does not report a pseudonode.
b) neighbor R2 comes up: no pseudonode: R1 just reports a link to R2 in 
its LSP. R2 reports a link to R1 in its LSP.
c) R3 comes up (two IS nbrs): R1 says "use pseudonode". R1, R2, and R3 
claim neighbor R1.25. R1.25 (the pseudonode name)
reports an LSP with neighbors R1, R2, R3.
d) R3 dies, leaving just R1 and R2: still pseudonode. R1.25 reissued, 
with just R1 and R2 reported. R3's LSP dies of old age.
e) R2 dies (so there is just R1): no pseudonode. R1 does not report any 
adjacencies for that port. R1 reissues its LSP
without R1.25 in it. R1.25's LSP dies of old age (or is given a 
premature death by R1)
f) R2 comes up: R1 says "use pseudonode". R2 issues its first LSP saying

it is connected to R1.25. R1 adds R1.25 to its LSP,
and issues R1.25's LSP with neighbors R1 and R2.

Note I think pseudonode minimization might not work for OSPF, since if I

remember correctly, OSPF reports some things in
the pseudonode LSA (type 2?) like the IP prefix for that link, that I 
think cannot go in
a non-pseudonode LSA (type 1?). So I think OSPF needs a pseudonode for
every link. (is this true?). But TRILL IS-IS has *no* information in the

pseudonode LSP other than reporting router neighbors.

Radia

mike shand wrote:
> On 31/01/2008 mike shand wrote:
>   
>> I'm not even convinced it simplifies the SPF, but since an SPF for a 
>> several hundred node network takes < 1mS, I don't see this as a big 
>> issue either way. However for a 15 node LAN, WITH pseudonode you
explore 
>> 1 hop to the PN then 14 hops to the other nodes, then check on back
link 
>> from each of the 14 to the PN (i.e 29 links). In the non PN case you 
>> explore 14 hops, then another 14 hops back from each of those 14
(i.e. 
>> 210 links). It would need a better analysis to determine exactly what

>> the relative merits are, but at best I would say it is a wash, and it

>>
>> might even be a pessimisation not to have a PN.
>>   
>>     
> I couldn't resist conducting the experiment:-) For what its worth, my 
> simulation seems to indicate that the SPF is faster WITH the
pseudonodes 
> than without, at least for 4 node LANs and above.
>
> I constructed a network consisting of 4 LANs each containing 4
routers. 
> The groups of routers were randomly interconnected with point to point

> links.
>
> The average time to run an SPF WITH pseudonodes was 52 uS, and without

> pseudonodes (i.e. each "LAN" of 4 routers was replaced by a fully
meshed 
> set of pt-pt links... each router connected to the 3 other routers on 
> the "LAN", was 64uS.
>
> The absolute values are irrelevant, but it does seem to indicate that,

> for 4 node LANs, the SPF is faster with pseudonodes.
>
>
> As I said, I don't think this matters at all; it is lost in the noise,

> but it certainly can't be said that it is BETTER not to have the 
> pseudonodes from the SPF point of view.
>
>     Mike
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   

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

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

Content-class: urn:content-classes:message
Date: Sat, 2 Feb 2008 01:01:51 -0000
From: "Thomas, Matthew R" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: [rbridge] FW:  Pseudonode minimization thoughts...
Status: RO
Content-Length: 10231

Hi Radia,

Adding v quick tutorial as suggested... 

I have been involved in looking at this for a bit, but your original
solution is significantly more elegant, backwardly compatible, only 2
flags to add etc etc, than ospf-lite and more elegant.

Here is a summary as requested of the general discussion / explanation
from people so far. I hope I do them justice.. please forgive any errors

OSPF language (appologies if anyone not interested)
***************************************************************

Ospf works in a very similar way to ISIS. Two types of LSA are
generated. OSPF type 1 (router) you would refer to as a normal ISIS LSP.
Our type 2 (Network-LSA) is as your pseudonode LSP.

Our type 1 (router LSA) is very similar to your standard LSP. There are
a few oddities. Here is the main one I think: a point-to-point line has
two entries:

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 2.2.2.2
     (Link Data) Router Interface address: 172.16.1.1
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 172.16.1.0
     (Link Data) Network Mask: 255.255.255.252
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

This is a point-to-point line from this router (ID 1.1.1.1) to the
neighbour 2.2.2.2 The point-to-point line has local IP address
172.16.1.1. It is reported TWICE in the packet. Once as a point-to-point
line and then a second time to attach the IP network. This is all to
allow an IP unnumbered interface if required. If unnumbered then the
interface in the first block of text is represented by an MIB value.

Radia et al plan, configured for OSPF:
**************************************

1.) Use ospf LLS datablock Extended options to locate 2 flags.
2.) One flag (called NS-Bit) signifies to the other neighbors, the
compatability with the reduction draft.
3.) DR gets elected and Pseudonode LSP (Network-LSA) is not generated by
DR yet.
4.) DR signals to neighbors to move to pseudonode reduction using second
flag (SS-Bit).
5.) Neighbors set SS-Bit flag in accordance to signify acceptance.
6.) Router LSA (ISIS normal LSP) shows to the OUTSIDE world a network
type of "point-to-multipoint." Represented as lots of Point-to-point
lines (see below for example
7.) Routers actually operate on the LAN using DR as normal.

However! we already have a special network type called
point-to-multipoint that actually reduces the Network LSA anyway. So is
the problem solved already? Well partly...

Here are the problems not currently solved by P2MP (Point-to-multipoint)
alone (as I see it):
*****************************************************************

Problem 1: P2MP cant be configured as default, (to avoid configuration
issues). This is because a further router might be added to the network
that isn't configured to support point-to-multipoint. The hellos would
not match and the neighbour would not be established. This is the
current state.

Problem 2. We cant add flags to dynamically change the network to
point-to-multipoint, (on its own without your proposal) because if we
did then the  DR is removed (as P2MP doesn't use one), so cant change
BACK if another router is added that doesn't support
point-to-multipoint. (same problem as above).

Both of these problems are solved by continuing to use DR as normal, but
advertising in the router LSA's the "point-to-multipoint" option, which
looks like this below: This LSA is generated by router IS 1.1.1.1 and
the neighbors listed are 2.2.2.2, 3.3.3.3, and the network in question
is 192.168.1.0 255.255.255.0

  LS Type: Router Links
  Link State ID: 1.1.1.1
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000002
  Checksum: 0xB5ED
  Length: 60
   Number of Links: 3

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 2.2.2.2
     (Link Data) Router Interface address: 192.168.1.1
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 3.3.3.3
     (Link Data) Router Interface address: 192.168.1.1
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 192.168.1.1
     (Link Data) Network Mask: 255.255.255.255 << note mask is 32
      Number of TOS metrics: 0
       TOS 0 Metrics: 0

Matthew Thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: 01 February 2008 18:48
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Pseudonode minimization thoughts...

Here's a compromise proposal.

My goals:
a) no configuration required
b) no pseudonode if you have no router neighbors on the link (whether or

not there are endnodes).
c) avoid pseudonodes if easy to do so (explain in a minute) when there 
are just 2 routers (with perhaps endnodes)

Before Mike's arithmetic, I was thinking that pseudonodes weren't 
valuable until maybe 10 neighbors, and just was
embarrassed about the whole pseudonode thing in this brave new world 
where "Ethernets" are usually pt-to-pt links, but
now I think it's fine to simply *always* get rid of pseudonodes in the 
case of one router, and *almost always* in the case of
just two routers.

So, here's the proposal:
a) do not report a pseudonode unless there is at least one *IS* 
adjacency. This eliminates my nightmare of an unconfigured
RBridge with 1000 ports, each with one endnode on it, reporting 1000 
pseudonodes. (Les confirmed my nightmare, that
all it takes is a single ES adjacency on a port and IS-IS today would 
create a pseudonode for that port. We *really* have to
fix that case, and without requiring configuration)
b) if there is just one IS adjacency, and you are the DR, and your other

IS is cool with this feature (as signalled in its Hello), don't use a 
pseudonode.
Just have each of the two IS's report a link to the other.
If your neighbor IS isn't cool with it, go ahead and make an adjacency. 
(Note: for TRILL, I'd hope we'd put this feature in from the
start, so that all RBridges would be cool with this, so that is simple)
c) if there are ever 2 IS adjacencies on the port, create a pseudonode 
*and remember, as long as you are up,
that this link should have a pseudonode as long as there is at least one

IS adjacency*. In other words,
this is not really a pt-to-pt link, and it won't be wasteful to keep the

link with a pseudonode because there might be other
IS's that will come up in the future. I would drop the pseudonode (in 
the case of TRILL especially, maybe not for CLNP),
if there is ever no other IS adjacencies.

This is kind of like the original proposal but with the threshold of "1"

and "3" rather than "2" and "5", except once you hit 3, the
threshold becomes "1" and "2". So in this case R1 would do the following
a) no IS neighbors: no pseudonode. R1 reports nothing about that port in

its LSP, and does not report a pseudonode.
b) neighbor R2 comes up: no pseudonode: R1 just reports a link to R2 in 
its LSP. R2 reports a link to R1 in its LSP.
c) R3 comes up (two IS nbrs): R1 says "use pseudonode". R1, R2, and R3 
claim neighbor R1.25. R1.25 (the pseudonode name)
reports an LSP with neighbors R1, R2, R3.
d) R3 dies, leaving just R1 and R2: still pseudonode. R1.25 reissued, 
with just R1 and R2 reported. R3's LSP dies of old age.
e) R2 dies (so there is just R1): no pseudonode. R1 does not report any 
adjacencies for that port. R1 reissues its LSP
without R1.25 in it. R1.25's LSP dies of old age (or is given a 
premature death by R1)
f) R2 comes up: R1 says "use pseudonode". R2 issues its first LSP saying

it is connected to R1.25. R1 adds R1.25 to its LSP,
and issues R1.25's LSP with neighbors R1 and R2.

Note I think pseudonode minimization might not work for OSPF, since if I

remember correctly, OSPF reports some things in
the pseudonode LSA (type 2?) like the IP prefix for that link, that I 
think cannot go in
a non-pseudonode LSA (type 1?). So I think OSPF needs a pseudonode for
every link. (is this true?). But TRILL IS-IS has *no* information in the

pseudonode LSP other than reporting router neighbors.

Radia

mike shand wrote:
> On 31/01/2008 mike shand wrote:
>   
>> I'm not even convinced it simplifies the SPF, but since an SPF for a 
>> several hundred node network takes < 1mS, I don't see this as a big 
>> issue either way. However for a 15 node LAN, WITH pseudonode you
explore 
>> 1 hop to the PN then 14 hops to the other nodes, then check on back
link 
>> from each of the 14 to the PN (i.e 29 links). In the non PN case you 
>> explore 14 hops, then another 14 hops back from each of those 14
(i.e. 
>> 210 links). It would need a better analysis to determine exactly what

>> the relative merits are, but at best I would say it is a wash, and it

>>
>> might even be a pessimisation not to have a PN.
>>   
>>     
> I couldn't resist conducting the experiment:-) For what its worth, my 
> simulation seems to indicate that the SPF is faster WITH the
pseudonodes 
> than without, at least for 4 node LANs and above.
>
> I constructed a network consisting of 4 LANs each containing 4
routers. 
> The groups of routers were randomly interconnected with point to point

> links.
>
> The average time to run an SPF WITH pseudonodes was 52 uS, and without

> pseudonodes (i.e. each "LAN" of 4 routers was replaced by a fully
meshed 
> set of pt-pt links... each router connected to the 3 other routers on 
> the "LAN", was 64uS.
>
> The absolute values are irrelevant, but it does seem to indicate that,

> for 4 node LANs, the SPF is faster with pseudonodes.
>
>
> As I said, I don't think this matters at all; it is lost in the noise,

> but it certainly can't be said that it is BETTER not to have the 
> pseudonodes from the SPF point of view.
>
>     Mike
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   

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

Content-class: urn:content-classes:message
Date: Fri, 1 Feb 2008 21:59:10 -0000
From: "Thomas, Matthew R" <[email-masked]>
To: "Les Ginsberg \(ginsberg\)" <[email-masked]>, "Radia Perlman" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Pseudonode minimization thoughts...
Status: RO
Content-Length: 1162

Well unless you are running OSPF Les. If this is the case then the pseudonode is generated whether you have an adjacency or not. To turn it off would require removal of the network from the area or explicit Pt-to-Pt configuration/ and messing about. This proposal is accross the boards and covering ospf as well, so this is an issue. This is easily fixed though, by implementing this proposal suggested by Radia et al

MT

________________________________

From: [email-masked] on behalf of Les Ginsberg (ginsberg)
Sent: Fri 01/02/2008 20:48
To: Radia Perlman; Developing a hybrid router/bridge.
Subject: Re: [rbridge] Pseudonode minimization thoughts...

Radia -

> (Les confirmed my nightmare, that
> all it takes is a single ES adjacency on a port and IS-IS today would
> create a pseudonode for that port. We *really* have to
> fix that case, and without requiring configuration)

Unless you are planning to run ES-IS on IP hosts, you won't have any ES
adjacencies.

Sleep peacefully. :-)

   Les

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

Content-class: urn:content-classes:message
Date: Fri, 1 Feb 2008 12:48:39 -0800
From: "Les Ginsberg (ginsberg)" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Pseudonode minimization thoughts...
Status: RO
Content-Length: 347

Radia -

> (Les confirmed my nightmare, that
> all it takes is a single ES adjacency on a port and IS-IS today would
> create a pseudonode for that port. We *really* have to
> fix that case, and without requiring configuration)

Unless you are planning to run ES-IS on IP hosts, you won't have any ES
adjacencies.

Sleep peacefully. :-)

   Les

Date: Fri, 01 Feb 2008 10:48:27 -0800
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Pseudonode minimization thoughts...
Status: RO
Content-Length: 5392

Here's a compromise proposal.

My goals:
a) no configuration required
b) no pseudonode if you have no router neighbors on the link (whether or 
not there are endnodes).
c) avoid pseudonodes if easy to do so (explain in a minute) when there 
are just 2 routers (with perhaps endnodes)

Before Mike's arithmetic, I was thinking that pseudonodes weren't 
valuable until maybe 10 neighbors, and just was
embarrassed about the whole pseudonode thing in this brave new world 
where "Ethernets" are usually pt-to-pt links, but
now I think it's fine to simply *always* get rid of pseudonodes in the 
case of one router, and *almost always* in the case of
just two routers.

So, here's the proposal:
a) do not report a pseudonode unless there is at least one *IS* 
adjacency. This eliminates my nightmare of an unconfigured
RBridge with 1000 ports, each with one endnode on it, reporting 1000 
pseudonodes. (Les confirmed my nightmare, that
all it takes is a single ES adjacency on a port and IS-IS today would 
create a pseudonode for that port. We *really* have to
fix that case, and without requiring configuration)
b) if there is just one IS adjacency, and you are the DR, and your other 
IS is cool with this feature (as signalled in its Hello), don't use a 
pseudonode.
Just have each of the two IS's report a link to the other.
If your neighbor IS isn't cool with it, go ahead and make an adjacency. 
(Note: for TRILL, I'd hope we'd put this feature in from the
start, so that all RBridges would be cool with this, so that is simple)
c) if there are ever 2 IS adjacencies on the port, create a pseudonode 
*and remember, as long as you are up,
that this link should have a pseudonode as long as there is at least one 
IS adjacency*. In other words,
this is not really a pt-to-pt link, and it won't be wasteful to keep the 
link with a pseudonode because there might be other
IS's that will come up in the future. I would drop the pseudonode (in 
the case of TRILL especially, maybe not for CLNP),
if there is ever no other IS adjacencies.

This is kind of like the original proposal but with the threshold of "1" 
and "3" rather than "2" and "5", except once you hit 3, the
threshold becomes "1" and "2". So in this case R1 would do the following
a) no IS neighbors: no pseudonode. R1 reports nothing about that port in 
its LSP, and does not report a pseudonode.
b) neighbor R2 comes up: no pseudonode: R1 just reports a link to R2 in 
its LSP. R2 reports a link to R1 in its LSP.
c) R3 comes up (two IS nbrs): R1 says "use pseudonode". R1, R2, and R3 
claim neighbor R1.25. R1.25 (the pseudonode name)
reports an LSP with neighbors R1, R2, R3.
d) R3 dies, leaving just R1 and R2: still pseudonode. R1.25 reissued, 
with just R1 and R2 reported. R3's LSP dies of old age.
e) R2 dies (so there is just R1): no pseudonode. R1 does not report any 
adjacencies for that port. R1 reissues its LSP
without R1.25 in it. R1.25's LSP dies of old age (or is given a 
premature death by R1)
f) R2 comes up: R1 says "use pseudonode". R2 issues its first LSP saying 
it is connected to R1.25. R1 adds R1.25 to its LSP,
and issues R1.25's LSP with neighbors R1 and R2.

Note I think pseudonode minimization might not work for OSPF, since if I 
remember correctly, OSPF reports some things in
the pseudonode LSA (type 2?) like the IP prefix for that link, that I 
think cannot go in
a non-pseudonode LSA (type 1?). So I think OSPF needs a pseudonode for
every link. (is this true?). But TRILL IS-IS has *no* information in the 
pseudonode LSP other than reporting router neighbors.

Radia

mike shand wrote:
> On 31/01/2008 mike shand wrote:
>   
>> I'm not even convinced it simplifies the SPF, but since an SPF for a 
>> several hundred node network takes < 1mS, I don't see this as a big 
>> issue either way. However for a 15 node LAN, WITH pseudonode you explore 
>> 1 hop to the PN then 14 hops to the other nodes, then check on back link 
>> from each of the 14 to the PN (i.e 29 links). In the non PN case you 
>> explore 14 hops, then another 14 hops back from each of those 14 (i.e. 
>> 210 links). It would need a better analysis to determine exactly what 
>> the relative merits are, but at best I would say it is a wash, and it 
>>
>> might even be a pessimisation not to have a PN.
>>   
>>     
> I couldn't resist conducting the experiment:-) For what its worth, my 
> simulation seems to indicate that the SPF is faster WITH the pseudonodes 
> than without, at least for 4 node LANs and above.
>
> I constructed a network consisting of 4 LANs each containing 4 routers. 
> The groups of routers were randomly interconnected with point to point 
> links.
>
> The average time to run an SPF WITH pseudonodes was 52 uS, and without 
> pseudonodes (i.e. each "LAN" of 4 routers was replaced by a fully meshed 
> set of pt-pt links... each router connected to the 3 other routers on 
> the "LAN", was 64uS.
>
> The absolute values are irrelevant, but it does seem to indicate that, 
> for 4 node LANs, the SPF is faster with pseudonodes.
>
>
> As I said, I don't think this matters at all; it is lost in the noise, 
> but it certainly can't be said that it is BETTER not to have the 
> pseudonodes from the SPF point of view.
>
>     Mike
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   

Date: Fri, 01 Feb 2008 16:29:49 +0000
From: mike shand <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Pseudonode minimization thoughts...
Status: RO
Content-Length: 1580

On 31/01/2008 mike shand wrote:
> I'm not even convinced it simplifies the SPF, but since an SPF for a 
> several hundred node network takes < 1mS, I don't see this as a big 
> issue either way. However for a 15 node LAN, WITH pseudonode you explore 
> 1 hop to the PN then 14 hops to the other nodes, then check on back link 
> from each of the 14 to the PN (i.e 29 links). In the non PN case you 
> explore 14 hops, then another 14 hops back from each of those 14 (i.e. 
> 210 links). It would need a better analysis to determine exactly what 
> the relative merits are, but at best I would say it is a wash, and it 
>
> might even be a pessimisation not to have a PN.
>   
I couldn't resist conducting the experiment:-) For what its worth, my 
simulation seems to indicate that the SPF is faster WITH the pseudonodes 
than without, at least for 4 node LANs and above.

I constructed a network consisting of 4 LANs each containing 4 routers. 
The groups of routers were randomly interconnected with point to point 
links.

The average time to run an SPF WITH pseudonodes was 52 uS, and without 
pseudonodes (i.e. each "LAN" of 4 routers was replaced by a fully meshed 
set of pt-pt links... each router connected to the 3 other routers on 
the "LAN", was 64uS.

The absolute values are irrelevant, but it does seem to indicate that, 
for 4 node LANs, the SPF is faster with pseudonodes.

As I said, I don't think this matters at all; it is lost in the noise, 
but it certainly can't be said that it is BETTER not to have the 
pseudonodes from the SPF point of view.

    Mike

Date: Fri, 01 Feb 2008 10:50:56 +0000
From: mike shand <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Pseudonode minimization thoughts...
Status: RO
Content-Length: 708

On 31/01/2008 Radia Perlman wrote:
> You said that to report a neighbor it is 12 octets for narrow metrics, 
> and 1 octets for wide metrics. Is that backwards perhaps?
> I'd think it should take more space to report a side metric, but no 
> matter -- I'll use 12 octets per neighbor. (though it would
> be nice to get a clarification on that -- I could imagine that when 
> they redid the TLV for reporting metrics, they not only
> widened the metric but also compressed the format, or maybe got rid of 
> multiple metrics).
>
Excatly. 12 for narrow, 11 for wide, becuase although the metric istelf 
uses 3 octets rather than one, we only have the single metric, rather 
than 4 separate metrics.

    Mike

Content-class: urn:content-classes:message
Date: Fri, 1 Feb 2008 09:27:51 -0000
From: "Thomas, Matthew R" <[email-masked]>
To: "Les Ginsberg \(ginsberg\)" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Pseudonode minimization thoughts...
Status: RO
Content-Length: 2265

Hi Les,
 
Just for comparison: In the case a.)  then with OSPF, then yes it actually would issue a Psuedonode. (LSA type 2)
 
Matthew

________________________________

From: [email-masked] on behalf of Les Ginsberg (ginsberg)
Sent: Fri 01/02/2008 08:47
To: Radia Perlman
Cc: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Pseudonode minimization thoughts...

Radia -

It seems you missed my point entirely. When I objected to your
characterization of the proposal as:

"I don't think it is complex. It costs 2 bits in Hellos."

I was not trying to demonstrate that the problem is insolvable - just
that the solution is not trivial - and requires care in both
specification and implementation. This raises the bar - at least to me -
in that the benefits have to be worth the cost. Obviously we differ on
that value judgment.

As to your questions:

> a) without configuration, would an IS-IS router today create a
> pseudonode if it is the only router on an Ethernet link?
> For instance, suppose R1 and R2
> are neighbors on an Ethernet, and R2 goes down. Will R1 will issue two
> LSPs, one saying the pseudonode is R1.25 with neighbor R1,
> and another saying R1 has neighbor R1.25? Or when R2 goes down, does
R1
> get rid of the pseudonode?

In order for a router to elect itself DIS on a circuit it MUST have at
least one ES or IS adjacency on that circuit in the UP state. (ISO
10589:2002 Section 8.4.5)

>
> b) suppose R1 and R2 are both on the same Ethernet, and one is
> configured that that port is pt-to-pt and the other is not configured
> that way. What happens?

No adjacency will be formed as the router which is configured to be
Pt-Pt discards LAN IIHs it receives on that circuit.

>
> c) suppose R1, R2, and R3 are all on the same Ethernet, and all are
> configured that that port is pt-to-pt. What happens?

No more than one adjacency will be formed on each router. Received
hellos whose system ID does not match an existing adjacency are
discarded.

See Section 4.5 of

http://www.ietf.org/internet-drafts/draft-ietf-isis-igp-p2p-over-lan-06.
txt

for further details.

   Les

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

Content-class: urn:content-classes:message
Date: Fri, 1 Feb 2008 00:47:35 -0800
From: "Les Ginsberg (ginsberg)" <[email-masked]>
To: "Radia Perlman" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Pseudonode minimization thoughts...
Status: RO
Content-Length: 1741

Radia -

It seems you missed my point entirely. When I objected to your
characterization of the proposal as:

"I don't think it is complex. It costs 2 bits in Hellos."

I was not trying to demonstrate that the problem is insolvable - just
that the solution is not trivial - and requires care in both
specification and implementation. This raises the bar - at least to me -
in that the benefits have to be worth the cost. Obviously we differ on
that value judgment.

As to your questions:

> a) without configuration, would an IS-IS router today create a
> pseudonode if it is the only router on an Ethernet link?
> For instance, suppose R1 and R2
> are neighbors on an Ethernet, and R2 goes down. Will R1 will issue two
> LSPs, one saying the pseudonode is R1.25 with neighbor R1,
> and another saying R1 has neighbor R1.25? Or when R2 goes down, does
R1
> get rid of the pseudonode?

In order for a router to elect itself DIS on a circuit it MUST have at
least one ES or IS adjacency on that circuit in the UP state. (ISO
10589:2002 Section 8.4.5)

> 
> b) suppose R1 and R2 are both on the same Ethernet, and one is
> configured that that port is pt-to-pt and the other is not configured
> that way. What happens?

No adjacency will be formed as the router which is configured to be
Pt-Pt discards LAN IIHs it receives on that circuit.

> 
> c) suppose R1, R2, and R3 are all on the same Ethernet, and all are
> configured that that port is pt-to-pt. What happens?

No more than one adjacency will be formed on each router. Received
hellos whose system ID does not match an existing adjacency are
discarded.

See Section 4.5 of 

http://www.ietf.org/internet-drafts/draft-ietf-isis-igp-p2p-over-lan-06.
txt

for further details.

   Les