Subject: [rbridge] draft WG minutes

From: Vishwas at sinett.com (Vishwas Manral)
Date: Wed, 31 Aug 2005 10:02:29 -0700

Hi,
 
???? is me(Vishwas).
 
Besides "????:  Are you considering something like MSDP like multiple spanning
trees per VLANs." is MSTP and not MSDP.
 
Thanks,
Vishwas
________________________________

From: rbridge-bounces at postel.org on behalf of Erik Nordmark
Sent: Wed 8/31/2005 7:01 AM
To: Developing a hybrid router/bridge.
Subject: [rbridge] draft WG minutes

Any corrections to what was said/discussed/agreed upon?

    Erik

---

TRILL WG  Minutes August 4, 2005

Minutes taken by Alia Atlas.

Agenda:

Deliverables:

Erik Nordmark: "Some fairly tight dates on getting at least the problem
    statement and architecture document.  This is something the IETF
    wants to see. There was a proposed outline sent around that we can
    share with the list.

    Requirements for a TRILL-capable routing protocol & select existing
    protocols. Work with appropriate routing wg on suitability/extensions.

    Produce a set of TRILL specs for standards track.
    draft-perlman-rbridge is the start."

Russ White:  The extensions to the routing protocols is already a work in
    progress - just not published yet.

Erik Nordmark: When that gets published as a draft, will go to the
    list so people can have a look at it.

====================
Coordination with IEEE 802.1:

Donald Eastlake:  Quick overview on 802.1 liaison.  IEEE 802.1 is
     custodian of the 802 Architecture & defines what it is.
     (See presentation slides)

     Bernard Aboba is the overall liaison but there's plenty of room for
more
     specific liaisons.

Paul Congdon:  Vice chair for 802.1(??).  There is a big difference in
IEEE as well & 802.1 operates more informally than many 802 groups.
Don't vote on each little thing & operate on consensus.  While we do
have a formal voting process, we do typically accept comments from
people who aren't part of the WG & I've never seen outside comments
not processed.  802.1 is much more informal and a relationship with
TRILL should be straightforward.  My questions is when you talk about
the liaison relationship, it wasn't clear what you'd want 802.1 to be
doing explicitly.  Obviously, we'll have people attending anyway as
IETF participants.

Donald:  First, I want to agree with what you said about 802.1 being
more open about comments from outside the WG.  In 802.11, which is
more formal, if there are technical questions, the chair can submit
them as his own.  For the question, the liaisons at a minimum would
report what was happening & report

Paul:  Dorothy is the liaison for most of the wireless, but I've been
serving as liaison for the 802.1 related work & will continue to do so.

Steve Drawbridge(??):  One of the co-authors on the new IETF liaison
process.  Part involves the IAB appointing an individual to look after
the liaison.  Liaison relationship actually means something in the IETF
context.

====================
Problem statement and architecture

Erik:  Editor for this draft should be here, but person is still TBD.
        Put this up to encourage people on it.  Looking for a volunteer
        author/editor.

        (See presentation)

Richard Spencer:  You put a list of what could be considered
requirements.  Can you tell us where those requirements have come
from?  What enterprise customers have said these meet their
requirements?  Have they said that these are the problems that they
want to be solved & this is the solutions?  Are there any enterprise
customers here that have these problems that need to be solved?

Erik:  These things have made it into the charter based on people
saying they've had these requirements.  I think it's hard to pinpoint
the origin of all of these requirements.

Richard:  It seems to me that we have a solution & are looking
requirements.

Erik:  We have a charter saying that the rbridge is a start & we
discussed this during the BOF.

Richard:  Are you intending to create a new market for this solution.

Erik: Yes.  Whatever it said on the first page, shortest-path frame
routing in multi-hop 802 network.

Richard:  If we don't have requirements, how do we know this is the
best solution?

Erik:  I think this is out of scope.

Joe Touch:  There are several docs.  I've seen WG have as many as 8 or
10 docs that lead up to the solution; shouldn't do that.  The doc that
we have to date is a combo of a problem statement and architecture.
The problem statement should include the applicability.  The
architecture should also list the requirements.  Some of those listed
are architectural requirements, not problem statements.  Shouldn't be
that hard to take a first stab at that.  Easier to see it from the
docs; it's hard to do that on the fly.

Erik:  If we can get that clarity, I agree.  I'm not sure how we're
going to work on moving forward on describing the problem statement
and the architecture.

Christian Huitema:  I really think we need to work on the
requirements.  When I read these slides, what's missing is the ref to
the wireless networks.  I don't know if that was deliberate, but it is
a large area of campus networks.

Erik:  Had question in BOF if targeted explicitly at wireless &
answer was no, but could be useful there.

Christian:  I agree but I'm talking about the wireless networks.
Taking the differences into account makes it likely that the solution
won't be applicable.

Erik:  Popping up, during the charter discussion, decided that we
didn't need a requirements doc first.  This is fairly solutions driven
from an architecture perspective.  Having a solution in the rbridge
means that we don't need a year or 2 to write a requirements doc.

Christian:  Agree not to spend 2 years arguing about requirements
first.  However, the requirements (or architecture) draft should
consider the wireless as well.

?? Jenkins:  Share some concerns about the requirements.  The problem
statement isn't a problem statement that is to be solved.  Until I can
see that, architecture seems a bit premature.

Russ White:  The IETF typically doesn't take requirements from
customers, but from vendors.  The vendors I know (Cisco for one) has
customers who are interested.  We have people interested in working on
this & vendors interested in implementing this so we move ahead.  On
802.11, I think that this will be useful there, but it might be good
to limit the discussion scope architecture about how this works & then
look at the wireless as we know this is coming next & commit to
looking at that and working on it, but let's solve what's on the table
first.

Vach Kompella: Speaking as chair of L2VPN, I don't think that there's
enough in the charter that distinguishes this from L2VPN.  I think
that a requirements doc is more necessary than you imagine & then make
that discussion here.  We did have a scope discussion about work here
versus L2VPN.  I agree with Joe that this could be useful.  I don't
want to get hung up on bureaucracy, but in L2VPN, L3VPN, etc. we have
the customers write the requirements - so I disagree with Russ.  Of
course, we have a smaller set of clueful service providers, so I'm not
saying that we need to go find clueful enterprises.  There should be
some people who will sign on and say that this is a problem & we see
the issues.

Joe Touch:  Usually when you include a problem statement, it's bundled
with the applicability.

Mark Townsley:  Could we focus on the problem statement &
applicability & if this isn't sufficient, then we'll think about a
requirements doc.  They're useful, but not always necessary.  Let's
focus just on the problem statement & applicability inside that, which
might help satisfy Vach's concerns.

Joe:  It might also help address the question of who wants this
problem.

Erik:  We did have the question about how this compares to L2VPN.  We
did have this in the charter, but took out.  I think it makes sense in
explaining this as part of the

??:  I think a lot of people are missing the obvious, if we did a
survey about how many enterprise customers are in here, well everyone
in here are enterprise customers.

Erik: But if they're building equipment to serve the SP network, are
they thinking of those or of their own networks?   It's good b/c this
helps clarify some of what I've been missing in terms of what the
problem statement and applicability should talk about.

(More presentation)

Joe Touch:  There's a bunch of threats that don't come to mind, such
as misconfiguration.  There's a lot longer list of things under the
"do no harm".

Erik:  Right, there's a lot of robustness concerns that could be
exploited.

Joe:  Even not considered as attackers but rather accidentally.

Erik: Traditionally, we think about active attackers.

Joe:  In the architecture, go through both active attackers &
misconfigurations.

Erik:  I'm not sure if the security ADs would agree with calling them
threats.

Joe: Right, but the first do no harm is a lot broader than the text.

Alex Zinin: On scalability, one thing to keep in mind is the frequency of
updates, such as start of the day when things are coming on-line &
hosts moving around.

Erik:  That would be in the applicability.

Alex: Yes, you'd need to define what is the scalability range that
you're optimizing for.

Erik:  I'd like to see this as a concise document?  What's missing?
Looking for volunteers..

====================
Requirements on routing protocols

Erik: Again, this is a TBD author.  Trill will provide a requirements
   doc for the routing protocols & then select which to use.  Any
   extensions needed to the routing protocol.  There's been some work &
   an ISIS extensions draft is already underway.

   Want to enable 0-touch, so can operate without manual
   configuration.  (See presentation)

====================
Protocol document:

Radia Perlman:  (see presentation)
       How many spanning trees?

       How to learn endnode information?

       How to handle multicast
          - IP multicast
          - non-IP multicast

Vach Kompella: How do you know which VLANs belong to which RBridges?

Radia:  That would have to be configured.  It would be in the
link-state protocol.  Not just "hi I'm Radia, but also these are my
VLANs".

Alex Zinin: From my understanding, the bridges that announce their
VLAN membership is just the RBridges connected to the end-hosts.

Radia:  All the RBridges support traffic transport.

Alex: So how do you decide where to forward?

Radia: Calculate a spanning tree (assume one) & you're not in any
VLANs.  Look downstream to see which VLANs are connected to the
RBridges.   (Continuing presentation showing why one might want
separate spanning trees per VLAN).

Dino:  Might want to say what a per-VLAN spanning tree would be used
versus a global spanning tree.

(More presentation)

Erik:  A question on the dynamic nature of this, through 802.11x, this
might attach to a particular access point.  Hosts could move & VLANs
might come & go on RBridges.

Radia:  yeah

Alex: One comment on spanning tree calculation.  Suggested just
selecting the lowest router ID. One problem is that that router might
be momentarily unavailable or frequently.

Radia:  If we're doing a tree per RBridge, not a problem.

Alex:  Yes, but for a single spanning tree, it would be.  The draft
has some words for ECMP-tie breakers.  You really need to worry about
bundles between nodes.

Radia:  It depends if those links are transparent to the rest of the
world.  If not, we'd need a deterministic tie-breaker, so would need to
include the port ID as well as the router ID.

(Second presentation)

Michael Smith:  Quick question.  The recommendation is to still pass
the MAC addresses

Radia:  Yes, but just passing around & not need to store them if not
part of the same VLAN.

Michael:  I was quite encouraged by the second approach where you do
the learning.

Radia:  Yes, this is something which is better suited to discussion on
the mailing list.

Erik:  It would be useful to write up an email to see the pros and
cons on the possibilities.

Radia:  Yes, and if sufficiently long, might be a draft.

Alex: Before we start discussing the pros and cons, having the
possible solutions fully described would help.

(Third presentation)

Tim Shepherd:  Are we concerned about defending against denial of
service attacks?

Radia: We certainly could say that there's a certain percentage of
traffic that's available to multicast - but that's orthogonal.

Tim:  But earlier, for unicast, if one hasn't heard of the address,
then it is broadcast.

Radia:  That's the case today...

Tim: If this tech allows larger domains without routers, could DoS
whole domain...

Erik: Would be interesting to understand if people understand with
snooping if there are things delivered without the IGMP.  ???

Dino:  They default to dropping, if IGMP snooping is configured on all
switches, if the MAC is IP-derived.

Erik:  There are 2 different behaviors depending on if the MAC is
IP-derived.

(presentation continues)

Dino:  IGMP forwarding doesn't happen for that case.  Existing snooping
IGMP bridges don't have this problem.

Radia: We need to make sure they don't.  We haven't written down the
design yet, so just need to make sure that we don't break that.  It
could be that we just copy the design for IGMP snooping bridges, or we
may need to do more.

Radia:  Should we allow cross-VLAN delivery of IP multicast?

Alex Zinin:  That's a router function; I'd leave it alone.  I think we
should preserve the functionality that is there.

Radia:  This is something else we should discuss on the list.

Erik:  What happens when you have a mixture of bridges and RBridges?
What happens when some bridges do IGMP snooping & some don't?

Dino??: There's nothing standardized, but MAGMA has something written
down talking about how not to break it.

Dino??:  If the RBridges don't do the IGMP snooping & the existing bridges
do, how does that work?

Erik: On the cross-VLAN thing, people may deploy VLANs for different
reasons.  Some may be for security & some may be to limit the
broadcast domain.  This

???: When we talk about non-IP multicast, we need to consider MPLS
multicast.

Erik:  They're specifying multicast in MPLS, but

Alex:  As a general response, let's leave MPLS multicast for later.
It's not yet a done deal & it won't be as easy as IP multicast.

Dino:  I think we'll have a struggle between management isolation &
optimization.  Then, do you want to support both or just make a
decision?

Alex:  We could limit it to L2 as part of this & then some nodes could
do it as part of their L3 functionality.

????:  Are you considering something like MSDP like multiple spanning
trees per VLANs.

Radia:  If you're doing per-RBridge spanning trees, then don't need
for per-VLAN.  Then which VLAN it is is only filtering information per
port.

????: Assume a bridge that is doing IGMP snooping, how will the bridge
in the middle be able to interoperate since we're adding a header.

Radia:  That's a question.  Since this isn't written down, we need to
get the design correct.  It'd be good if we had people on the list who
really understood how IGMP bridge snooping really worked.

????:  What about MTU issues?  Have we thought about those?

Radia:  For a few years, I always assumed that adding a few bytes
would be fatal, but now they're doing VLAN tags and MAC-in-MAC so
apparently it's not a problem.

Erik: So at end of the agenda, should we accept this rbridge doc as a
WG doc...  Are we ready to answer the question?

Loa:  This doc is actually mentioned as the starting point in the
charter, so is there a question.

Joe Touch:  It might be more productive to offer to start with
breaking the document into two pieces.  One that looks more like an
applicability and one that looks like an architecture...

Erik:  The only reason to ask the question now is to rename the doc so
it's easier to find.   Second step is figuring out which docs we need.

Paul:  It does seem a bit odd to adopt a protocol doc before you even
have other docs written or even outlined.  It makes sense that it
would be a WG doc at some point, but not sure whether the WG will
consider other approaches.

Erik:  The IESG re-wrote it into the charter.  The document will
definitely evolve; it's a starting point.

?????:  What we have here is a doc that we clearly think will be
broken up.  2 revs down the road, it'll clearly go away.  Sounds to me
like at least 3 (apps, arch, protocol).  Once those are spun out, then
we can talk about adopting them.

Vach Kompella:  It also seems odd to have this in the charter...  You
need at least one rev of the charter now, to take this out.

---
_______________________________________________
rbridge mailing list
rbridge at postel.org
http://www.postel.org/mailman/listinfo/rbridge

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 18335 bytes
Desc: not available
Url : http://www.postel.org/pipermail/rbridge/attachments/20050831/6e10a870/attachment-0001.bin

Content-class: urn:content-classes:message
Date: Wed, 31 Aug 2005 10:02:29 -0700
From: "Vishwas Manral" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] draft WG minutes
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 42020

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5AE4E.1668E4A8
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
???? is me(Vishwas).
=20
Besides "????:  Are you considering something like MSDP like multiple =
spanning
trees per VLANs." is MSTP and not MSDP.
=20
Thanks,
Vishwas
________________________________

From: [email-masked] on behalf of Erik Nordmark
Sent: Wed 8/31/2005 7:01 AM
To: Developing a hybrid router/bridge.
Subject: [rbridge] draft WG minutes

Any corrections to what was said/discussed/agreed upon?

    Erik

---

TRILL WG  Minutes August 4, 2005

Minutes taken by Alia Atlas.

Agenda:

Deliverables:

Erik Nordmark: "Some fairly tight dates on getting at least the problem
    statement and architecture document.  This is something the IETF
    wants to see. There was a proposed outline sent around that we can
    share with the list.

    Requirements for a TRILL-capable routing protocol & select existing
    protocols. Work with appropriate routing wg on =
suitability/extensions.

    Produce a set of TRILL specs for standards track.
    draft-perlman-rbridge is the start."

Russ White:  The extensions to the routing protocols is already a work =
in
    progress - just not published yet.

Erik Nordmark: When that gets published as a draft, will go to the
    list so people can have a look at it.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Coordination with IEEE 802.1:

Donald Eastlake:  Quick overview on 802.1 liaison.  IEEE 802.1 is
     custodian of the 802 Architecture & defines what it is.
     (See presentation slides)

     Bernard Aboba is the overall liaison but there's plenty of room for
more
     specific liaisons.

Paul Congdon:  Vice chair for 802.1(??).  There is a big difference in
IEEE as well & 802.1 operates more informally than many 802 groups.
Don't vote on each little thing & operate on consensus.  While we do
have a formal voting process, we do typically accept comments from
people who aren't part of the WG & I've never seen outside comments
not processed.  802.1 is much more informal and a relationship with
TRILL should be straightforward.  My questions is when you talk about
the liaison relationship, it wasn't clear what you'd want 802.1 to be
doing explicitly.  Obviously, we'll have people attending anyway as
IETF participants.

Donald:  First, I want to agree with what you said about 802.1 being
more open about comments from outside the WG.  In 802.11, which is
more formal, if there are technical questions, the chair can submit
them as his own.  For the question, the liaisons at a minimum would
report what was happening & report

Paul:  Dorothy is the liaison for most of the wireless, but I've been
serving as liaison for the 802.1 related work & will continue to do so.

Steve Drawbridge(??):  One of the co-authors on the new IETF liaison
process.  Part involves the IAB appointing an individual to look after
the liaison.  Liaison relationship actually means something in the IETF
context.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Problem statement and architecture

Erik:  Editor for this draft should be here, but person is still TBD.
        Put this up to encourage people on it.  Looking for a volunteer
        author/editor.

        (See presentation)

Richard Spencer:  You put a list of what could be considered
requirements.  Can you tell us where those requirements have come
from?  What enterprise customers have said these meet their
requirements?  Have they said that these are the problems that they
want to be solved & this is the solutions?  Are there any enterprise
customers here that have these problems that need to be solved?

Erik:  These things have made it into the charter based on people
saying they've had these requirements.  I think it's hard to pinpoint
the origin of all of these requirements.

Richard:  It seems to me that we have a solution & are looking
requirements.

Erik:  We have a charter saying that the rbridge is a start & we
discussed this during the BOF.

Richard:  Are you intending to create a new market for this solution.

Erik: Yes.  Whatever it said on the first page, shortest-path frame
routing in multi-hop 802 network.

Richard:  If we don't have requirements, how do we know this is the
best solution?

Erik:  I think this is out of scope.

Joe Touch:  There are several docs.  I've seen WG have as many as 8 or
10 docs that lead up to the solution; shouldn't do that.  The doc that
we have to date is a combo of a problem statement and architecture.
The problem statement should include the applicability.  The
architecture should also list the requirements.  Some of those listed
are architectural requirements, not problem statements.  Shouldn't be
that hard to take a first stab at that.  Easier to see it from the
docs; it's hard to do that on the fly.

Erik:  If we can get that clarity, I agree.  I'm not sure how we're
going to work on moving forward on describing the problem statement
and the architecture.

Christian Huitema:  I really think we need to work on the
requirements.  When I read these slides, what's missing is the ref to
the wireless networks.  I don't know if that was deliberate, but it is
a large area of campus networks.

Erik:  Had question in BOF if targeted explicitly at wireless &
answer was no, but could be useful there.

Christian:  I agree but I'm talking about the wireless networks.
Taking the differences into account makes it likely that the solution
won't be applicable.

Erik:  Popping up, during the charter discussion, decided that we
didn't need a requirements doc first.  This is fairly solutions driven
from an architecture perspective.  Having a solution in the rbridge
means that we don't need a year or 2 to write a requirements doc.

Christian:  Agree not to spend 2 years arguing about requirements
first.  However, the requirements (or architecture) draft should
consider the wireless as well.

?? Jenkins:  Share some concerns about the requirements.  The problem
statement isn't a problem statement that is to be solved.  Until I can
see that, architecture seems a bit premature.

Russ White:  The IETF typically doesn't take requirements from
customers, but from vendors.  The vendors I know (Cisco for one) has
customers who are interested.  We have people interested in working on
this & vendors interested in implementing this so we move ahead.  On
802.11, I think that this will be useful there, but it might be good
to limit the discussion scope architecture about how this works & then
look at the wireless as we know this is coming next & commit to
looking at that and working on it, but let's solve what's on the table
first.

Vach Kompella: Speaking as chair of L2VPN, I don't think that there's
enough in the charter that distinguishes this from L2VPN.  I think
that a requirements doc is more necessary than you imagine & then make
that discussion here.  We did have a scope discussion about work here
versus L2VPN.  I agree with Joe that this could be useful.  I don't
want to get hung up on bureaucracy, but in L2VPN, L3VPN, etc. we have
the customers write the requirements - so I disagree with Russ.  Of
course, we have a smaller set of clueful service providers, so I'm not
saying that we need to go find clueful enterprises.  There should be
some people who will sign on and say that this is a problem & we see
the issues.

Joe Touch:  Usually when you include a problem statement, it's bundled
with the applicability.

Mark Townsley:  Could we focus on the problem statement &
applicability & if this isn't sufficient, then we'll think about a
requirements doc.  They're useful, but not always necessary.  Let's
focus just on the problem statement & applicability inside that, which
might help satisfy Vach's concerns.

Joe:  It might also help address the question of who wants this
problem.

Erik:  We did have the question about how this compares to L2VPN.  We
did have this in the charter, but took out.  I think it makes sense in
explaining this as part of the

??:  I think a lot of people are missing the obvious, if we did a
survey about how many enterprise customers are in here, well everyone
in here are enterprise customers.

Erik: But if they're building equipment to serve the SP network, are
they thinking of those or of their own networks?   It's good b/c this
helps clarify some of what I've been missing in terms of what the
problem statement and applicability should talk about.

(More presentation)

Joe Touch:  There's a bunch of threats that don't come to mind, such
as misconfiguration.  There's a lot longer list of things under the
"do no harm".

Erik:  Right, there's a lot of robustness concerns that could be
exploited.

Joe:  Even not considered as attackers but rather accidentally.

Erik: Traditionally, we think about active attackers.

Joe:  In the architecture, go through both active attackers &
misconfigurations.

Erik:  I'm not sure if the security ADs would agree with calling them
threats.

Joe: Right, but the first do no harm is a lot broader than the text.

Alex Zinin: On scalability, one thing to keep in mind is the frequency =
of
updates, such as start of the day when things are coming on-line &
hosts moving around.

Erik:  That would be in the applicability.

Alex: Yes, you'd need to define what is the scalability range that
you're optimizing for.

Erik:  I'd like to see this as a concise document?  What's missing?
Looking for volunteers..

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Requirements on routing protocols

Erik: Again, this is a TBD author.  Trill will provide a requirements
   doc for the routing protocols & then select which to use.  Any
   extensions needed to the routing protocol.  There's been some work &
   an ISIS extensions draft is already underway.

   Want to enable 0-touch, so can operate without manual
   configuration.  (See presentation)

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Protocol document:

Radia Perlman:  (see presentation)
       How many spanning trees?

       How to learn endnode information?

       How to handle multicast
          - IP multicast
          - non-IP multicast

Vach Kompella: How do you know which VLANs belong to which RBridges?

Radia:  That would have to be configured.  It would be in the
link-state protocol.  Not just "hi I'm Radia, but also these are my
VLANs".

Alex Zinin: From my understanding, the bridges that announce their
VLAN membership is just the RBridges connected to the end-hosts.

Radia:  All the RBridges support traffic transport.

Alex: So how do you decide where to forward?

Radia: Calculate a spanning tree (assume one) & you're not in any
VLANs.  Look downstream to see which VLANs are connected to the
RBridges.   (Continuing presentation showing why one might want
separate spanning trees per VLAN).

Dino:  Might want to say what a per-VLAN spanning tree would be used
versus a global spanning tree.

(More presentation)

Erik:  A question on the dynamic nature of this, through 802.11x, this
might attach to a particular access point.  Hosts could move & VLANs
might come & go on RBridges.

Radia:  yeah

Alex: One comment on spanning tree calculation.  Suggested just
selecting the lowest router ID. One problem is that that router might
be momentarily unavailable or frequently.

Radia:  If we're doing a tree per RBridge, not a problem.

Alex:  Yes, but for a single spanning tree, it would be.  The draft
has some words for ECMP-tie breakers.  You really need to worry about
bundles between nodes.

Radia:  It depends if those links are transparent to the rest of the
world.  If not, we'd need a deterministic tie-breaker, so would need to
include the port ID as well as the router ID.

(Second presentation)

Michael Smith:  Quick question.  The recommendation is to still pass
the MAC addresses

Radia:  Yes, but just passing around & not need to store them if not
part of the same VLAN.

Michael:  I was quite encouraged by the second approach where you do
the learning.

Radia:  Yes, this is something which is better suited to discussion on
the mailing list.

Erik:  It would be useful to write up an email to see the pros and
cons on the possibilities.

Radia:  Yes, and if sufficiently long, might be a draft.

Alex: Before we start discussing the pros and cons, having the
possible solutions fully described would help.

(Third presentation)

Tim Shepherd:  Are we concerned about defending against denial of
service attacks?

Radia: We certainly could say that there's a certain percentage of
traffic that's available to multicast - but that's orthogonal.

Tim:  But earlier, for unicast, if one hasn't heard of the address,
then it is broadcast.

Radia:  That's the case today...

Tim: If this tech allows larger domains without routers, could DoS
whole domain...

Erik: Would be interesting to understand if people understand with
snooping if there are things delivered without the IGMP.  ???

Dino:  They default to dropping, if IGMP snooping is configured on all
switches, if the MAC is IP-derived.

Erik:  There are 2 different behaviors depending on if the MAC is
IP-derived.

(presentation continues)

Dino:  IGMP forwarding doesn't happen for that case.  Existing snooping
IGMP bridges don't have this problem.

Radia: We need to make sure they don't.  We haven't written down the
design yet, so just need to make sure that we don't break that.  It
could be that we just copy the design for IGMP snooping bridges, or we
may need to do more.

Radia:  Should we allow cross-VLAN delivery of IP multicast?

Alex Zinin:  That's a router function; I'd leave it alone.  I think we
should preserve the functionality that is there.

Radia:  This is something else we should discuss on the list.

Erik:  What happens when you have a mixture of bridges and RBridges?
What happens when some bridges do IGMP snooping & some don't?

Dino??: There's nothing standardized, but MAGMA has something written
down talking about how not to break it.

Dino??:  If the RBridges don't do the IGMP snooping & the existing =
bridges
do, how does that work?

Erik: On the cross-VLAN thing, people may deploy VLANs for different
reasons.  Some may be for security & some may be to limit the
broadcast domain.  This

???: When we talk about non-IP multicast, we need to consider MPLS
multicast.

Erik:  They're specifying multicast in MPLS, but

Alex:  As a general response, let's leave MPLS multicast for later.
It's not yet a done deal & it won't be as easy as IP multicast.

Dino:  I think we'll have a struggle between management isolation &
optimization.  Then, do you want to support both or just make a
decision?

Alex:  We could limit it to L2 as part of this & then some nodes could
do it as part of their L3 functionality.

????:  Are you considering something like MSDP like multiple spanning
trees per VLANs.

Radia:  If you're doing per-RBridge spanning trees, then don't need
for per-VLAN.  Then which VLAN it is is only filtering information per
port.

????: Assume a bridge that is doing IGMP snooping, how will the bridge
in the middle be able to interoperate since we're adding a header.

Radia:  That's a question.  Since this isn't written down, we need to
get the design correct.  It'd be good if we had people on the list who
really understood how IGMP bridge snooping really worked.

????:  What about MTU issues?  Have we thought about those?

Radia:  For a few years, I always assumed that adding a few bytes
would be fatal, but now they're doing VLAN tags and MAC-in-MAC so
apparently it's not a problem.

Erik: So at end of the agenda, should we accept this rbridge doc as a
WG doc...  Are we ready to answer the question?

Loa:  This doc is actually mentioned as the starting point in the
charter, so is there a question.

Joe Touch:  It might be more productive to offer to start with
breaking the document into two pieces.  One that looks more like an
applicability and one that looks like an architecture...

Erik:  The only reason to ask the question now is to rename the doc so
it's easier to find.   Second step is figuring out which docs we need.

Paul:  It does seem a bit odd to adopt a protocol doc before you even
have other docs written or even outlined.  It makes sense that it
would be a WG doc at some point, but not sure whether the WG will
consider other approaches.

Erik:  The IESG re-wrote it into the charter.  The document will
definitely evolve; it's a starting point.

?????:  What we have here is a doc that we clearly think will be
broken up.  2 revs down the road, it'll clearly go away.  Sounds to me
like at least 3 (apps, arch, protocol).  Once those are spun out, then
we can talk about adopting them.

Vach Kompella:  It also seems odd to have this in the charter...  You
need at least one rev of the charter now, to take this out.

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

------_=_NextPart_001_01C5AE4E.1668E4A8
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C5AE4E.1668E4A8--

From: "Gray, Eric" <[email-masked]>
To: "Erik Nordmark (E-mail)" <[email-masked]>
Date: Wed, 31 Aug 2005 10:51:39 -0400
Cc: "'Developing a hybrid router/bridge.'" <[email-masked]>
Subject: Re: [rbridge] draft WG minutes
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 18877

Erik,

	It's "Steve Trowbridge", not "Drawbridge"...

	The comment ("??") about "missing the obvious" was me.

	"Dino" is D. Farinacci (for anyone that does not know
him).

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Erik Nordmark
--> Sent: Wednesday, August 31, 2005 10:02 AM
--> To: Developing a hybrid router/bridge.
--> Subject: [rbridge] draft WG minutes
--> 
--> 
--> 
--> Any corrections to what was said/discussed/agreed upon?
--> 
-->     Erik
--> 
--> ---
--> 
--> TRILL WG  Minutes August 4, 2005
--> 
--> Minutes taken by Alia Atlas.
--> 
--> Agenda:
--> 
--> Deliverables:
--> 
--> Erik Nordmark: "Some fairly tight dates on getting at least 
--> the problem
-->     statement and architecture document.  This is something the IETF
-->     wants to see. There was a proposed outline sent around 
--> that we can
-->     share with the list.
--> 
-->     Requirements for a TRILL-capable routing protocol & 
--> select existing
-->     protocols. Work with appropriate routing wg on 
--> suitability/extensions.
--> 
-->     Produce a set of TRILL specs for standards track.
-->     draft-perlman-rbridge is the start."
--> 
--> Russ White:  The extensions to the routing protocols is 
--> already a work in
-->     progress - just not published yet.
--> 
--> Erik Nordmark: When that gets published as a draft, will go to the
-->     list so people can have a look at it.
--> 
--> ====================
--> Coordination with IEEE 802.1:
--> 
--> Donald Eastlake:  Quick overview on 802.1 liaison.  IEEE 802.1 is
-->      custodian of the 802 Architecture & defines what it is.
-->      (See presentation slides)
--> 
-->      Bernard Aboba is the overall liaison but there's 
--> plenty of room for 
--> more
-->      specific liaisons.
--> 
--> Paul Congdon:  Vice chair for 802.1(??).  There is a big 
--> difference in
--> IEEE as well & 802.1 operates more informally than many 802 groups.
--> Don't vote on each little thing & operate on consensus.  While we do
--> have a formal voting process, we do typically accept comments from
--> people who aren't part of the WG & I've never seen outside comments
--> not processed.  802.1 is much more informal and a relationship with
--> TRILL should be straightforward.  My questions is when you 
--> talk about
--> the liaison relationship, it wasn't clear what you'd want 
--> 802.1 to be
--> doing explicitly.  Obviously, we'll have people attending anyway as
--> IETF participants.
--> 
--> Donald:  First, I want to agree with what you said about 802.1 being
--> more open about comments from outside the WG.  In 802.11, which is
--> more formal, if there are technical questions, the chair can submit
--> them as his own.  For the question, the liaisons at a minimum would
--> report what was happening & report
--> 
--> Paul:  Dorothy is the liaison for most of the wireless, but 
--> I've been
--> serving as liaison for the 802.1 related work & will 
--> continue to do so.
--> 
--> Steve Drawbridge(??):  One of the co-authors on the new IETF liaison
--> process.  Part involves the IAB appointing an individual to 
--> look after
--> the liaison.  Liaison relationship actually means something 
--> in the IETF
--> context.
--> 
--> ====================
--> Problem statement and architecture
--> 
--> Erik:  Editor for this draft should be here, but person is 
--> still TBD.
-->         Put this up to encourage people on it.  Looking for 
--> a volunteer
-->         author/editor.
--> 
-->         (See presentation)
--> 
--> Richard Spencer:  You put a list of what could be considered
--> requirements.  Can you tell us where those requirements have come
--> from?  What enterprise customers have said these meet their
--> requirements?  Have they said that these are the problems that they
--> want to be solved & this is the solutions?  Are there any enterprise
--> customers here that have these problems that need to be solved?
--> 
--> Erik:  These things have made it into the charter based on people
--> saying they've had these requirements.  I think it's hard 
--> to pinpoint
--> the origin of all of these requirements.
--> 
--> Richard:  It seems to me that we have a solution & are looking
--> requirements.
--> 
--> Erik:  We have a charter saying that the rbridge is a start & we
--> discussed this during the BOF.
--> 
--> Richard:  Are you intending to create a new market for this 
--> solution.
--> 
--> Erik: Yes.  Whatever it said on the first page, shortest-path frame
--> routing in multi-hop 802 network.
--> 
--> Richard:  If we don't have requirements, how do we know this is the
--> best solution?
--> 
--> Erik:  I think this is out of scope.
--> 
--> Joe Touch:  There are several docs.  I've seen WG have as 
--> many as 8 or
--> 10 docs that lead up to the solution; shouldn't do that.  
--> The doc that
--> we have to date is a combo of a problem statement and architecture.
--> The problem statement should include the applicability.  The
--> architecture should also list the requirements.  Some of 
--> those listed
--> are architectural requirements, not problem statements.  
--> Shouldn't be
--> that hard to take a first stab at that.  Easier to see it from the
--> docs; it's hard to do that on the fly.
--> 
--> Erik:  If we can get that clarity, I agree.  I'm not sure how we're
--> going to work on moving forward on describing the problem statement
--> and the architecture.
--> 
--> Christian Huitema:  I really think we need to work on the
--> requirements.  When I read these slides, what's missing is 
--> the ref to
--> the wireless networks.  I don't know if that was 
--> deliberate, but it is
--> a large area of campus networks.
--> 
--> Erik:  Had question in BOF if targeted explicitly at wireless &
--> answer was no, but could be useful there.
--> 
--> Christian:  I agree but I'm talking about the wireless networks.
--> Taking the differences into account makes it likely that 
--> the solution
--> won't be applicable.
--> 
--> Erik:  Popping up, during the charter discussion, decided that we
--> didn't need a requirements doc first.  This is fairly 
--> solutions driven
--> from an architecture perspective.  Having a solution in the rbridge
--> means that we don't need a year or 2 to write a requirements doc.
--> 
--> Christian:  Agree not to spend 2 years arguing about requirements
--> first.  However, the requirements (or architecture) draft should
--> consider the wireless as well.
--> 
--> ?? Jenkins:  Share some concerns about the requirements.  
--> The problem
--> statement isn't a problem statement that is to be solved.  
--> Until I can
--> see that, architecture seems a bit premature.
--> 
--> Russ White:  The IETF typically doesn't take requirements from
--> customers, but from vendors.  The vendors I know (Cisco for one) has
--> customers who are interested.  We have people interested in 
--> working on
--> this & vendors interested in implementing this so we move ahead.  On
--> 802.11, I think that this will be useful there, but it might be good
--> to limit the discussion scope architecture about how this 
--> works & then
--> look at the wireless as we know this is coming next & commit to
--> looking at that and working on it, but let's solve what's 
--> on the table
--> first.
--> 
--> Vach Kompella: Speaking as chair of L2VPN, I don't think 
--> that there's
--> enough in the charter that distinguishes this from L2VPN.  I think
--> that a requirements doc is more necessary than you imagine 
--> & then make
--> that discussion here.  We did have a scope discussion about 
--> work here
--> versus L2VPN.  I agree with Joe that this could be useful.  I don't
--> want to get hung up on bureaucracy, but in L2VPN, L3VPN, 
--> etc. we have
--> the customers write the requirements - so I disagree with Russ.  Of
--> course, we have a smaller set of clueful service providers, 
--> so I'm not
--> saying that we need to go find clueful enterprises.  There should be
--> some people who will sign on and say that this is a problem & we see
--> the issues.
--> 
--> Joe Touch:  Usually when you include a problem statement, 
--> it's bundled
--> with the applicability.
--> 
--> Mark Townsley:  Could we focus on the problem statement &
--> applicability & if this isn't sufficient, then we'll think about a
--> requirements doc.  They're useful, but not always necessary.  Let's
--> focus just on the problem statement & applicability inside 
--> that, which
--> might help satisfy Vach's concerns.
--> 
--> Joe:  It might also help address the question of who wants this
--> problem.
--> 
--> Erik:  We did have the question about how this compares to 
--> L2VPN.  We
--> did have this in the charter, but took out.  I think it 
--> makes sense in
--> explaining this as part of the
--> 
--> ??:  I think a lot of people are missing the obvious, if we did a
--> survey about how many enterprise customers are in here, 
--> well everyone
--> in here are enterprise customers.
--> 
--> Erik: But if they're building equipment to serve the SP network, are
--> they thinking of those or of their own networks?   It's 
--> good b/c this
--> helps clarify some of what I've been missing in terms of what the
--> problem statement and applicability should talk about.
--> 
--> (More presentation)
--> 
--> Joe Touch:  There's a bunch of threats that don't come to mind, such
--> as misconfiguration.  There's a lot longer list of things under the
--> "do no harm".
--> 
--> Erik:  Right, there's a lot of robustness concerns that could be
--> exploited.
--> 
--> Joe:  Even not considered as attackers but rather accidentally.
--> 
--> Erik: Traditionally, we think about active attackers.
--> 
--> Joe:  In the architecture, go through both active attackers &
--> misconfigurations.
--> 
--> Erik:  I'm not sure if the security ADs would agree with 
--> calling them
--> threats.
--> 
--> Joe: Right, but the first do no harm is a lot broader than the text.
--> 
--> Alex Zinin: On scalability, one thing to keep in mind is 
--> the frequency of
--> updates, such as start of the day when things are coming on-line &
--> hosts moving around.
--> 
--> Erik:  That would be in the applicability.
--> 
--> Alex: Yes, you'd need to define what is the scalability range that
--> you're optimizing for.
--> 
--> Erik:  I'd like to see this as a concise document?  What's missing?
--> Looking for volunteers..
--> 
--> ====================
--> Requirements on routing protocols
--> 
--> Erik: Again, this is a TBD author.  Trill will provide a 
--> requirements
-->    doc for the routing protocols & then select which to use.  Any
-->    extensions needed to the routing protocol.  There's been 
--> some work &
-->    an ISIS extensions draft is already underway.
--> 
-->    Want to enable 0-touch, so can operate without manual
-->    configuration.  (See presentation)
--> 
--> ====================
--> Protocol document:
--> 
--> Radia Perlman:  (see presentation)
-->        How many spanning trees?
--> 
-->        How to learn endnode information?
--> 
-->        How to handle multicast
--> 	  - IP multicast
--> 	  - non-IP multicast
--> 
--> Vach Kompella: How do you know which VLANs belong to which RBridges?
--> 
--> Radia:  That would have to be configured.  It would be in the
--> link-state protocol.  Not just "hi I'm Radia, but also these are my
--> VLANs".
--> 
--> Alex Zinin: From my understanding, the bridges that announce their
--> VLAN membership is just the RBridges connected to the end-hosts.
--> 
--> Radia:  All the RBridges support traffic transport.
--> 
--> Alex: So how do you decide where to forward?
--> 
--> Radia: Calculate a spanning tree (assume one) & you're not in any
--> VLANs.  Look downstream to see which VLANs are connected to the
--> RBridges.   (Continuing presentation showing why one might want
--> separate spanning trees per VLAN).
--> 
--> Dino:  Might want to say what a per-VLAN spanning tree would be used
--> versus a global spanning tree.
--> 
--> (More presentation)
--> 
--> Erik:  A question on the dynamic nature of this, through 
--> 802.11x, this
--> might attach to a particular access point.  Hosts could move & VLANs
--> might come & go on RBridges.
--> 
--> Radia:  yeah
--> 
--> Alex: One comment on spanning tree calculation.  Suggested just
--> selecting the lowest router ID. One problem is that that 
--> router might
--> be momentarily unavailable or frequently.
--> 
--> Radia:  If we're doing a tree per RBridge, not a problem.
--> 
--> Alex:  Yes, but for a single spanning tree, it would be.  The draft
--> has some words for ECMP-tie breakers.  You really need to 
--> worry about
--> bundles between nodes.
--> 
--> Radia:  It depends if those links are transparent to the rest of the
--> world.  If not, we'd need a deterministic tie-breaker, so 
--> would need to
--> include the port ID as well as the router ID.
--> 
--> (Second presentation)
--> 
--> Michael Smith:  Quick question.  The recommendation is to still pass
--> the MAC addresses
--> 
--> Radia:  Yes, but just passing around & not need to store them if not
--> part of the same VLAN.
--> 
--> Michael:  I was quite encouraged by the second approach where you do
--> the learning.
--> 
--> Radia:  Yes, this is something which is better suited to 
--> discussion on
--> the mailing list.
--> 
--> Erik:  It would be useful to write up an email to see the pros and
--> cons on the possibilities.
--> 
--> Radia:  Yes, and if sufficiently long, might be a draft.
--> 
--> Alex: Before we start discussing the pros and cons, having the
--> possible solutions fully described would help.
--> 
--> (Third presentation)
--> 
--> Tim Shepherd:  Are we concerned about defending against denial of
--> service attacks?
--> 
--> Radia: We certainly could say that there's a certain percentage of
--> traffic that's available to multicast - but that's orthogonal.
--> 
--> Tim:  But earlier, for unicast, if one hasn't heard of the address,
--> then it is broadcast.
--> 
--> Radia:  That's the case today...
--> 
--> Tim: If this tech allows larger domains without routers, could DoS
--> whole domain...
--> 
--> Erik: Would be interesting to understand if people understand with
--> snooping if there are things delivered without the IGMP.  ???
--> 
--> Dino:  They default to dropping, if IGMP snooping is 
--> configured on all
--> switches, if the MAC is IP-derived.
--> 
--> Erik:  There are 2 different behaviors depending on if the MAC is
--> IP-derived.
--> 
--> (presentation continues)
--> 
--> Dino:  IGMP forwarding doesn't happen for that case.  
--> Existing snooping
--> IGMP bridges don't have this problem.
--> 
--> Radia: We need to make sure they don't.  We haven't written down the
--> design yet, so just need to make sure that we don't break that.  It
--> could be that we just copy the design for IGMP snooping 
--> bridges, or we
--> may need to do more.
--> 
--> Radia:  Should we allow cross-VLAN delivery of IP multicast?
--> 
--> Alex Zinin:  That's a router function; I'd leave it alone.  
--> I think we
--> should preserve the functionality that is there.
--> 
--> Radia:  This is something else we should discuss on the list.
--> 
--> Erik:  What happens when you have a mixture of bridges and RBridges?
--> What happens when some bridges do IGMP snooping & some don't?
--> 
--> Dino??: There's nothing standardized, but MAGMA has 
--> something written
--> down talking about how not to break it.
--> 
--> Dino??:  If the RBridges don't do the IGMP snooping & the 
--> existing bridges
--> do, how does that work?
--> 
--> Erik: On the cross-VLAN thing, people may deploy VLANs for different
--> reasons.  Some may be for security & some may be to limit the
--> broadcast domain.  This
--> 
--> ???: When we talk about non-IP multicast, we need to consider MPLS
--> multicast.
--> 
--> Erik:  They're specifying multicast in MPLS, but
--> 
--> Alex:  As a general response, let's leave MPLS multicast for later.
--> It's not yet a done deal & it won't be as easy as IP multicast.
--> 
--> Dino:  I think we'll have a struggle between management isolation &
--> optimization.  Then, do you want to support both or just make a
--> decision?
--> 
--> Alex:  We could limit it to L2 as part of this & then some 
--> nodes could
--> do it as part of their L3 functionality.
--> 
--> ????:  Are you considering something like MSDP like 
--> multiple spanning
--> trees per VLANs.
--> 
--> Radia:  If you're doing per-RBridge spanning trees, then don't need
--> for per-VLAN.  Then which VLAN it is is only filtering 
--> information per
--> port.
--> 
--> ????: Assume a bridge that is doing IGMP snooping, how will 
--> the bridge
--> in the middle be able to interoperate since we're adding a header.
--> 
--> Radia:  That's a question.  Since this isn't written down, 
--> we need to
--> get the design correct.  It'd be good if we had people on 
--> the list who
--> really understood how IGMP bridge snooping really worked.
--> 
--> ????:  What about MTU issues?  Have we thought about those?
--> 
--> Radia:  For a few years, I always assumed that adding a few bytes
--> would be fatal, but now they're doing VLAN tags and MAC-in-MAC so
--> apparently it's not a problem.
--> 
--> Erik: So at end of the agenda, should we accept this 
--> rbridge doc as a
--> WG doc...  Are we ready to answer the question?
--> 
--> Loa:  This doc is actually mentioned as the starting point in the
--> charter, so is there a question.
--> 
--> Joe Touch:  It might be more productive to offer to start with
--> breaking the document into two pieces.  One that looks more like an
--> applicability and one that looks like an architecture...
--> 
--> Erik:  The only reason to ask the question now is to rename 
--> the doc so
--> it's easier to find.   Second step is figuring out which 
--> docs we need.
--> 
--> Paul:  It does seem a bit odd to adopt a protocol doc 
--> before you even
--> have other docs written or even outlined.  It makes sense that it
--> would be a WG doc at some point, but not sure whether the WG will
--> consider other approaches.
--> 
--> Erik:  The IESG re-wrote it into the charter.  The document will
--> definitely evolve; it's a starting point.
--> 
--> ?????:  What we have here is a doc that we clearly think will be
--> broken up.  2 revs down the road, it'll clearly go away.  
--> Sounds to me
--> like at least 3 (apps, arch, protocol).  Once those are 
--> spun out, then
--> we can talk about adopting them.
--> 
--> Vach Kompella:  It also seems odd to have this in the 
--> charter...  You
--> need at least one rev of the charter now, to take this out.
--> 
--> ---
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Date: Wed, 31 Aug 2005 07:01:46 -0700
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] draft WG minutes
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 16205

Any corrections to what was said/discussed/agreed upon?

    Erik

---

TRILL WG  Minutes August 4, 2005

Minutes taken by Alia Atlas.

Agenda:

Deliverables:

Erik Nordmark: "Some fairly tight dates on getting at least the problem
    statement and architecture document.  This is something the IETF
    wants to see. There was a proposed outline sent around that we can
    share with the list.

    Requirements for a TRILL-capable routing protocol & select existing
    protocols. Work with appropriate routing wg on suitability/extensions.

    Produce a set of TRILL specs for standards track.
    draft-perlman-rbridge is the start."

Russ White:  The extensions to the routing protocols is already a work in
    progress - just not published yet.

Erik Nordmark: When that gets published as a draft, will go to the
    list so people can have a look at it.

====================
Coordination with IEEE 802.1:

Donald Eastlake:  Quick overview on 802.1 liaison.  IEEE 802.1 is
     custodian of the 802 Architecture & defines what it is.
     (See presentation slides)

     Bernard Aboba is the overall liaison but there's plenty of room for 
more
     specific liaisons.

Paul Congdon:  Vice chair for 802.1(??).  There is a big difference in
IEEE as well & 802.1 operates more informally than many 802 groups.
Don't vote on each little thing & operate on consensus.  While we do
have a formal voting process, we do typically accept comments from
people who aren't part of the WG & I've never seen outside comments
not processed.  802.1 is much more informal and a relationship with
TRILL should be straightforward.  My questions is when you talk about
the liaison relationship, it wasn't clear what you'd want 802.1 to be
doing explicitly.  Obviously, we'll have people attending anyway as
IETF participants.

Donald:  First, I want to agree with what you said about 802.1 being
more open about comments from outside the WG.  In 802.11, which is
more formal, if there are technical questions, the chair can submit
them as his own.  For the question, the liaisons at a minimum would
report what was happening & report

Paul:  Dorothy is the liaison for most of the wireless, but I've been
serving as liaison for the 802.1 related work & will continue to do so.

Steve Drawbridge(??):  One of the co-authors on the new IETF liaison
process.  Part involves the IAB appointing an individual to look after
the liaison.  Liaison relationship actually means something in the IETF
context.

====================
Problem statement and architecture

Erik:  Editor for this draft should be here, but person is still TBD.
        Put this up to encourage people on it.  Looking for a volunteer
        author/editor.

        (See presentation)

Richard Spencer:  You put a list of what could be considered
requirements.  Can you tell us where those requirements have come
from?  What enterprise customers have said these meet their
requirements?  Have they said that these are the problems that they
want to be solved & this is the solutions?  Are there any enterprise
customers here that have these problems that need to be solved?

Erik:  These things have made it into the charter based on people
saying they've had these requirements.  I think it's hard to pinpoint
the origin of all of these requirements.

Richard:  It seems to me that we have a solution & are looking
requirements.

Erik:  We have a charter saying that the rbridge is a start & we
discussed this during the BOF.

Richard:  Are you intending to create a new market for this solution.

Erik: Yes.  Whatever it said on the first page, shortest-path frame
routing in multi-hop 802 network.

Richard:  If we don't have requirements, how do we know this is the
best solution?

Erik:  I think this is out of scope.

Joe Touch:  There are several docs.  I've seen WG have as many as 8 or
10 docs that lead up to the solution; shouldn't do that.  The doc that
we have to date is a combo of a problem statement and architecture.
The problem statement should include the applicability.  The
architecture should also list the requirements.  Some of those listed
are architectural requirements, not problem statements.  Shouldn't be
that hard to take a first stab at that.  Easier to see it from the
docs; it's hard to do that on the fly.

Erik:  If we can get that clarity, I agree.  I'm not sure how we're
going to work on moving forward on describing the problem statement
and the architecture.

Christian Huitema:  I really think we need to work on the
requirements.  When I read these slides, what's missing is the ref to
the wireless networks.  I don't know if that was deliberate, but it is
a large area of campus networks.

Erik:  Had question in BOF if targeted explicitly at wireless &
answer was no, but could be useful there.

Christian:  I agree but I'm talking about the wireless networks.
Taking the differences into account makes it likely that the solution
won't be applicable.

Erik:  Popping up, during the charter discussion, decided that we
didn't need a requirements doc first.  This is fairly solutions driven
from an architecture perspective.  Having a solution in the rbridge
means that we don't need a year or 2 to write a requirements doc.

Christian:  Agree not to spend 2 years arguing about requirements
first.  However, the requirements (or architecture) draft should
consider the wireless as well.

?? Jenkins:  Share some concerns about the requirements.  The problem
statement isn't a problem statement that is to be solved.  Until I can
see that, architecture seems a bit premature.

Russ White:  The IETF typically doesn't take requirements from
customers, but from vendors.  The vendors I know (Cisco for one) has
customers who are interested.  We have people interested in working on
this & vendors interested in implementing this so we move ahead.  On
802.11, I think that this will be useful there, but it might be good
to limit the discussion scope architecture about how this works & then
look at the wireless as we know this is coming next & commit to
looking at that and working on it, but let's solve what's on the table
first.

Vach Kompella: Speaking as chair of L2VPN, I don't think that there's
enough in the charter that distinguishes this from L2VPN.  I think
that a requirements doc is more necessary than you imagine & then make
that discussion here.  We did have a scope discussion about work here
versus L2VPN.  I agree with Joe that this could be useful.  I don't
want to get hung up on bureaucracy, but in L2VPN, L3VPN, etc. we have
the customers write the requirements - so I disagree with Russ.  Of
course, we have a smaller set of clueful service providers, so I'm not
saying that we need to go find clueful enterprises.  There should be
some people who will sign on and say that this is a problem & we see
the issues.

Joe Touch:  Usually when you include a problem statement, it's bundled
with the applicability.

Mark Townsley:  Could we focus on the problem statement &
applicability & if this isn't sufficient, then we'll think about a
requirements doc.  They're useful, but not always necessary.  Let's
focus just on the problem statement & applicability inside that, which
might help satisfy Vach's concerns.

Joe:  It might also help address the question of who wants this
problem.

Erik:  We did have the question about how this compares to L2VPN.  We
did have this in the charter, but took out.  I think it makes sense in
explaining this as part of the

??:  I think a lot of people are missing the obvious, if we did a
survey about how many enterprise customers are in here, well everyone
in here are enterprise customers.

Erik: But if they're building equipment to serve the SP network, are
they thinking of those or of their own networks?   It's good b/c this
helps clarify some of what I've been missing in terms of what the
problem statement and applicability should talk about.

(More presentation)

Joe Touch:  There's a bunch of threats that don't come to mind, such
as misconfiguration.  There's a lot longer list of things under the
"do no harm".

Erik:  Right, there's a lot of robustness concerns that could be
exploited.

Joe:  Even not considered as attackers but rather accidentally.

Erik: Traditionally, we think about active attackers.

Joe:  In the architecture, go through both active attackers &
misconfigurations.

Erik:  I'm not sure if the security ADs would agree with calling them
threats.

Joe: Right, but the first do no harm is a lot broader than the text.

Alex Zinin: On scalability, one thing to keep in mind is the frequency of
updates, such as start of the day when things are coming on-line &
hosts moving around.

Erik:  That would be in the applicability.

Alex: Yes, you'd need to define what is the scalability range that
you're optimizing for.

Erik:  I'd like to see this as a concise document?  What's missing?
Looking for volunteers..

====================
Requirements on routing protocols

Erik: Again, this is a TBD author.  Trill will provide a requirements
   doc for the routing protocols & then select which to use.  Any
   extensions needed to the routing protocol.  There's been some work &
   an ISIS extensions draft is already underway.

   Want to enable 0-touch, so can operate without manual
   configuration.  (See presentation)

====================
Protocol document:

Radia Perlman:  (see presentation)
       How many spanning trees?

       How to learn endnode information?

       How to handle multicast
	  - IP multicast
	  - non-IP multicast

Vach Kompella: How do you know which VLANs belong to which RBridges?

Radia:  That would have to be configured.  It would be in the
link-state protocol.  Not just "hi I'm Radia, but also these are my
VLANs".

Alex Zinin: From my understanding, the bridges that announce their
VLAN membership is just the RBridges connected to the end-hosts.

Radia:  All the RBridges support traffic transport.

Alex: So how do you decide where to forward?

Radia: Calculate a spanning tree (assume one) & you're not in any
VLANs.  Look downstream to see which VLANs are connected to the
RBridges.   (Continuing presentation showing why one might want
separate spanning trees per VLAN).

Dino:  Might want to say what a per-VLAN spanning tree would be used
versus a global spanning tree.

(More presentation)

Erik:  A question on the dynamic nature of this, through 802.11x, this
might attach to a particular access point.  Hosts could move & VLANs
might come & go on RBridges.

Radia:  yeah

Alex: One comment on spanning tree calculation.  Suggested just
selecting the lowest router ID. One problem is that that router might
be momentarily unavailable or frequently.

Radia:  If we're doing a tree per RBridge, not a problem.

Alex:  Yes, but for a single spanning tree, it would be.  The draft
has some words for ECMP-tie breakers.  You really need to worry about
bundles between nodes.

Radia:  It depends if those links are transparent to the rest of the
world.  If not, we'd need a deterministic tie-breaker, so would need to
include the port ID as well as the router ID.

(Second presentation)

Michael Smith:  Quick question.  The recommendation is to still pass
the MAC addresses

Radia:  Yes, but just passing around & not need to store them if not
part of the same VLAN.

Michael:  I was quite encouraged by the second approach where you do
the learning.

Radia:  Yes, this is something which is better suited to discussion on
the mailing list.

Erik:  It would be useful to write up an email to see the pros and
cons on the possibilities.

Radia:  Yes, and if sufficiently long, might be a draft.

Alex: Before we start discussing the pros and cons, having the
possible solutions fully described would help.

(Third presentation)

Tim Shepherd:  Are we concerned about defending against denial of
service attacks?

Radia: We certainly could say that there's a certain percentage of
traffic that's available to multicast - but that's orthogonal.

Tim:  But earlier, for unicast, if one hasn't heard of the address,
then it is broadcast.

Radia:  That's the case today...

Tim: If this tech allows larger domains without routers, could DoS
whole domain...

Erik: Would be interesting to understand if people understand with
snooping if there are things delivered without the IGMP.  ???

Dino:  They default to dropping, if IGMP snooping is configured on all
switches, if the MAC is IP-derived.

Erik:  There are 2 different behaviors depending on if the MAC is
IP-derived.

(presentation continues)

Dino:  IGMP forwarding doesn't happen for that case.  Existing snooping
IGMP bridges don't have this problem.

Radia: We need to make sure they don't.  We haven't written down the
design yet, so just need to make sure that we don't break that.  It
could be that we just copy the design for IGMP snooping bridges, or we
may need to do more.

Radia:  Should we allow cross-VLAN delivery of IP multicast?

Alex Zinin:  That's a router function; I'd leave it alone.  I think we
should preserve the functionality that is there.

Radia:  This is something else we should discuss on the list.

Erik:  What happens when you have a mixture of bridges and RBridges?
What happens when some bridges do IGMP snooping & some don't?

Dino??: There's nothing standardized, but MAGMA has something written
down talking about how not to break it.

Dino??:  If the RBridges don't do the IGMP snooping & the existing bridges
do, how does that work?

Erik: On the cross-VLAN thing, people may deploy VLANs for different
reasons.  Some may be for security & some may be to limit the
broadcast domain.  This

???: When we talk about non-IP multicast, we need to consider MPLS
multicast.

Erik:  They're specifying multicast in MPLS, but

Alex:  As a general response, let's leave MPLS multicast for later.
It's not yet a done deal & it won't be as easy as IP multicast.

Dino:  I think we'll have a struggle between management isolation &
optimization.  Then, do you want to support both or just make a
decision?

Alex:  We could limit it to L2 as part of this & then some nodes could
do it as part of their L3 functionality.

????:  Are you considering something like MSDP like multiple spanning
trees per VLANs.

Radia:  If you're doing per-RBridge spanning trees, then don't need
for per-VLAN.  Then which VLAN it is is only filtering information per
port.

????: Assume a bridge that is doing IGMP snooping, how will the bridge
in the middle be able to interoperate since we're adding a header.

Radia:  That's a question.  Since this isn't written down, we need to
get the design correct.  It'd be good if we had people on the list who
really understood how IGMP bridge snooping really worked.

????:  What about MTU issues?  Have we thought about those?

Radia:  For a few years, I always assumed that adding a few bytes
would be fatal, but now they're doing VLAN tags and MAC-in-MAC so
apparently it's not a problem.

Erik: So at end of the agenda, should we accept this rbridge doc as a
WG doc...  Are we ready to answer the question?

Loa:  This doc is actually mentioned as the starting point in the
charter, so is there a question.

Joe Touch:  It might be more productive to offer to start with
breaking the document into two pieces.  One that looks more like an
applicability and one that looks like an architecture...

Erik:  The only reason to ask the question now is to rename the doc so
it's easier to find.   Second step is figuring out which docs we need.

Paul:  It does seem a bit odd to adopt a protocol doc before you even
have other docs written or even outlined.  It makes sense that it
would be a WG doc at some point, but not sure whether the WG will
consider other approaches.

Erik:  The IESG re-wrote it into the charter.  The document will
definitely evolve; it's a starting point.

?????:  What we have here is a doc that we clearly think will be
broken up.  2 revs down the road, it'll clearly go away.  Sounds to me
like at least 3 (apps, arch, protocol).  Once those are spun out, then
we can talk about adopting them.

Vach Kompella:  It also seems odd to have this in the charter...  You
need at least one rev of the charter now, to take this out.

---

Date: Mon, 29 Aug 2005 07:57:38 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Doubts about Rbridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2754

Just like with regular bridges, the first bridge or RBridge will insert 
the VLAN header into the
inner header. So if it's MAC-based, the first bridge or RBridge will do 
that. Then the
outer header is only to carry it between the RBridges. At that point, 
RBridges only look
at VLAN in order to decide whether they can optimize by not forwarding 
it down
a branch of the ingress-RBridge-spanning tree.

The inner header is still available for inspection by RBridges. Bridges 
in the core won't
see the VLAN tag, but they don't need to...they are only forwarding in 
the tiny universe
of the link between two adjacent RBridges.

And finally, the last RBridge removes the outer header and shim, and the 
VLAN tag, before
forwarding onto the last link.

Radia

Vishwas Manral wrote:

>Hi Erik,
>
>One part you may have missed out is the action taken as a result of
>seeing the other header. 
>
>As the Outer Ethernet Header is changed, Protocol VLAN too may have
>problems which are based on EtherType. Similarly as Source MAC Address
>is changed Mac-Based VLAN will not work.
>
>Thanks,
>Vishwas
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Erik Nordmark
>Sent: Saturday, August 27, 2005 4:39 AM
>To: Developing a hybrid router/bridge.
>Subject: Re: [rbridge] Doubts about Rbridge
>
>Vishwas Manral wrote:
>  
>
>>Hi Radia,
>>
>>(PS: I am changing the subject line) The existing bridges (switches)
>>already do IGMP snooping, to limit multicast traffic. That scenario
>>would break.
>>
>>A lot of existing layer-2 devices do firewall functionality. Firewall
>>functionality in the silicon may not work with Rbridges coming in.
>>    
>>
>
>Sorry for the late response.
>
>It seems like there are two places that are interesting to look at for 
>both of these issues:
>1. Between the hosts/routers and the first rbridge
>2. The path between rbridges
>
>At #1, the packets remain unmodified, this any bridge functionality that
>
>peeks into higher-layer headers would work just as it does today.
>So I don't see how anything could break there.
>
>At #2, the packets are encapsulated in an rbridge header. Thus any 
>bridges between the rbridges that look for higher level headers will not
>
>find them unless they are taught to skip the rbridge headers. (The same 
>issues presumably apply for other encapsulations, be it mac-in-mac, 
>q-in-q, or something else.)
>
>At #2 IGMP/MLD snooping might not be critical; assuming that the 
>rbridges do IGMP/MLD snooping the result would be to limit the flooding 
>of multicast packets.
>
>    Erik
>
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>

Content-class: urn:content-classes:message
Date: Mon, 29 Aug 2005 02:23:36 -0700
From: "Vishwas Manral" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Doubts about Rbridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1765

Hi Erik,

One part you may have missed out is the action taken as a result of
seeing the other header. 

As the Outer Ethernet Header is changed, Protocol VLAN too may have
problems which are based on EtherType. Similarly as Source MAC Address
is changed Mac-Based VLAN will not work.

Thanks,
Vishwas
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Erik Nordmark
Sent: Saturday, August 27, 2005 4:39 AM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Doubts about Rbridge

Vishwas Manral wrote:
> Hi Radia,
> 
> (PS: I am changing the subject line) The existing bridges (switches)
> already do IGMP snooping, to limit multicast traffic. That scenario
> would break.
> 
> A lot of existing layer-2 devices do firewall functionality. Firewall
> functionality in the silicon may not work with Rbridges coming in.

Sorry for the late response.

It seems like there are two places that are interesting to look at for 
both of these issues:
1. Between the hosts/routers and the first rbridge
2. The path between rbridges

At #1, the packets remain unmodified, this any bridge functionality that

peeks into higher-layer headers would work just as it does today.
So I don't see how anything could break there.

At #2, the packets are encapsulated in an rbridge header. Thus any 
bridges between the rbridges that look for higher level headers will not

find them unless they are taught to skip the rbridge headers. (The same 
issues presumably apply for other encapsulations, be it mac-in-mac, 
q-in-q, or something else.)

At #2 IGMP/MLD snooping might not be critical; assuming that the 
rbridges do IGMP/MLD snooping the result would be to limit the flooding 
of multicast packets.

    Erik

Date: Mon, 29 Aug 2005 10:48:17 +0200 (CEST)
From: Wojtek Paprowicz <[email-masked]>
To: [email-masked]
Organization: Agora S.A.
Subject: [rbridge] Convergence time
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 488

Hi everybody,

I was wondering if convergence is a case in RBRIDGE idea. Taking
into concideration, that currently RBRIDGEs run ISIS, I think it
should be. How do you think should be the timers set in order to
achieve results similar to SDH? The default timers will not do the
trick. On the other hand, we cannot lower e.g. helloInterval too
much. The timers are also crucial for node/link failures and failure
recovery times. Be grateful for your opinions.

Regards,
Wojtek Paprowicz

Content-class: urn:content-classes:message
Date: Sun, 28 Aug 2005 21:45:40 -0700
From: "Vishwas Manral" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, [email-masked]
Subject: Re: [rbridge] Summary 1 of load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2813

Hi Joe,

> I still do not see the particular utility of reinventing 
> MPLS-ish tags in the shim header; if you want MPLS, you can use 
> that. If not, then let the interior rbridges decide how they want
> to handle load balancing themselves. None of the peeking we're 
> talking about is extraordinarily complex.
I think the idea was more like a Flow label in IPv6 and not the MPLS
label (which needs to be pre-signaled and is also used for forwarding).

That said; I figured in the IPv6 implementation report
http://www.ietf.org/IESG/Implementations/ipv6-implementations.txt few
implementations support Flow Label (the document unfortunately is not
dated). Maybe someone else can clarify if that is right?

Thanks,
Vishwas
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Alia Atlas
> Sent: Thursday, August 11, 2005 11:43 PM
> To: [email-masked]; Developing a hybrid router/bridge.
> Cc: Joe Touch
> Subject: [rbridge] Summary 1 of load-balancing rbridges
> 
> As per Radia's request, here's my best effort at a summarization.
> 
> The introduction of rbridges implies that rbridges will need to do
> load-balancing among equal-cost paths.  To avoid reordering at Layer
> 4, it is very desirable (even necessary) to have the rbridges able to
> identify the micro-flows.  There are 3 possible ways of doing this
> that were discussed.
> 
> (1) Each rbridge peeks under the rbridge shim header & encapsulated
> MAC frame to the (potentially) IP packet underneath.  If there is an
> IP packet, then an identification as to the micro-flow is made and the
> frame is forwarded based on the micro-flow.  Behavior if there isn't
> an IP packet hasn't been discussed.
> 
> (2) The ingress rbridge determines the micro-flow and marks the frame
> with a micro-flow tag in some way.  Interior (or midpoint) rbridges
> can use this tag to identify the micro-flow instead of having to peek
> underneath the rbridge shim header.  This is an optimization of (1)
> that reduces the complexity of interior rbridges at the cost of
> additional header size.
> 
> (3)Each egress rbridge could have a number of aliases.  The ingress
> rbridge identifies a micro-flow & forwards the frame to a particular
> alias, indicating a path.  There are some issues here with number of
> paths,  handling addresses connected to multiple egress rbridges, etc.
> 
> Option (2) seems promising, but whether it is the correct trade-off
> versus (1) needs more discussion and input.  Please comment.  :-)
> 
> Alia
> 

Date: Fri, 26 Aug 2005 16:09:01 -0700
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Doubts about Rbridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1215

Vishwas Manral wrote:
> Hi Radia,
> 
> (PS: I am changing the subject line) The existing bridges (switches)
> already do IGMP snooping, to limit multicast traffic. That scenario
> would break.
> 
> A lot of existing layer-2 devices do firewall functionality. Firewall
> functionality in the silicon may not work with Rbridges coming in.

Sorry for the late response.

It seems like there are two places that are interesting to look at for 
both of these issues:
1. Between the hosts/routers and the first rbridge
2. The path between rbridges

At #1, the packets remain unmodified, this any bridge functionality that 
peeks into higher-layer headers would work just as it does today.
So I don't see how anything could break there.

At #2, the packets are encapsulated in an rbridge header. Thus any 
bridges between the rbridges that look for higher level headers will not 
find them unless they are taught to skip the rbridge headers. (The same 
issues presumably apply for other encapsulations, be it mac-in-mac, 
q-in-q, or something else.)

At #2 IGMP/MLD snooping might not be critical; assuming that the 
rbridges do IGMP/MLD snooping the result would be to limit the flooding 
of multicast packets.

    Erik

Date: Fri, 19 Aug 2005 22:33:27 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Summary 1 of load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1363

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF7BE77102D8A05CFF274DEBD
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Stephen J. Bevan wrote:
> Joe Touch writes:
>  > It does not matter if different switches use different criteria for
>  > load balancing, though - it matters only that each switch is
>  > consistent.
> 
> True, but if one can arrange for the switches to, optionally, use the
> same criteria then it opens up the possiblity of doing split
> multi-link trunking (to use Nortel's term for this) in a vendor
> neutral manner.

Wouldn't that happen as the result of a consistent, multi-path routing
protocol? I.e., what I'm proposing is that switches MAY use local
criteria for balancing or supporting multipath, but MAY also use a
coordinated system if they agree to.

Joe

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

--------------enigF7BE77102D8A05CFF274DEBD--

Date: Fri, 19 Aug 2005 20:03:11 -0700
To: "Developing a hybrid router/bridge." <[email-masked]>
From: [email-masked] (Stephen J. Bevan)
Subject: Re: [rbridge] Summary 1 of load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 380

Joe Touch writes:
 > It does not matter if different switches use different criteria for
 > load balancing, though - it matters only that each switch is
 > consistent.

True, but if one can arrange for the switches to, optionally, use the
same criteria then it opens up the possiblity of doing split
multi-link trunking (to use Nortel's term for this) in a vendor
neutral manner.

Date: Sat, 13 Aug 2005 11:14:25 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Summary 1 of load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1744

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7844C583B93AFFC7575ED1D4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Shane Amante wrote:
> Joe,
> 
> On Aug 12, 2005, at 3:56 PM, Joe Touch wrote:
> 
> [ snip ]
> 
>  > MAC-based load balancing, besides not helping with the case I cited,
>  > also fails for systems with multiple NICs that stripe a single  
> transport
>  > across multiple interfaces (e.g., channel bonding). Granted, they're
>  > sort of 'asking for it', but it seems OK to use a fairly common
>  > technique if it solves this problem too.
> 
> I was just curious if you could be more specific as to what you're  
> referring to in the above?  I'm aware of MLPPP that is used to stripe  
> packets across multiple, underlying component circuits in the  
> bundle.  However, I'm not aware of (Ethernet) NIC's and/or protocols  
> that can also provide the same capability on media other than TDM  
> circuit.  Could you elaborate on vendors/NIC's, (if such a thing  
> exists and I'm not misunderstanding you)?

I'm not aware of vendor-provided solutions that do this, but rather
installed configurations that do. Some are in the grid community.

Joe

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

--------------enig7844C583B93AFFC7575ED1D4--

From: Shane Amante <[email-masked]>
Date: Sat, 13 Aug 2005 04:10:59 -0600
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Summary 1 of load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 893

Joe,

On Aug 12, 2005, at 3:56 PM, Joe Touch wrote:

[ snip ]

 > MAC-based load balancing, besides not helping with the case I cited,
 > also fails for systems with multiple NICs that stripe a single  
transport
 > across multiple interfaces (e.g., channel bonding). Granted, they're
 > sort of 'asking for it', but it seems OK to use a fairly common
 > technique if it solves this problem too.

I was just curious if you could be more specific as to what you're  
referring to in the above?  I'm aware of MLPPP that is used to stripe  
packets across multiple, underlying component circuits in the  
bundle.  However, I'm not aware of (Ethernet) NIC's and/or protocols  
that can also provide the same capability on media other than TDM  
circuit.  Could you elaborate on vendors/NIC's, (if such a thing  
exists and I'm not misunderstanding you)?

Thanks,

-shane

> <mime-attachment>

Content-class: urn:content-classes:message
Date: Sat, 13 Aug 2005 01:09:34 -0700
From: "Vishwas Manral" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Summary 1 of load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2687

Joe,

One small thought.

> PS - one final thought. We don't really need to spec any of 
> this per se, IMO. We can mention that per-MAC or per-transportflow
> is fine, and that we leave it up to the rbridge implementation to 
> decide which to support. Again, so long as it's consistent within a 
> single rbridge device it need not be coordinated at all.
I agree we do not need to put the criteria for load balancing in the
spec. It would be ok to discuss it however. In my view it should be
configureable.

Thanks,
Vishwas
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Joe Touch
Sent: Saturday, August 13, 2005 3:29 AM
To: Joe Touch
Cc: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Summary 1 of load-balancing rbridges

Joe Touch wrote:
> 
> 
> John Kristoff wrote:
> 
>>>On Thu, 11 Aug 2005 14:40:33 -0700
>>>Joe Touch <[email-masked]> wrote:
>>>
>>>
>>>
>>>>That's when it would be useful to peek into not only the IP, but
also
>>>>transport headers to mux across the pair of paths without reordering
>>>>within a transport connection.
>>>
>>>
>>>>From an operational perspective I'd prefer Alex's suggestion to use
>>>MAC addresses as the flow hash for load balancing.  It seems much
>>>simpler and seems to solve most of the problem.  Separate tools or
>>>other protocols can be used to achieve more perfect load balancing
>>>if it is needed.
> 
> 
> Load balancing by looking at IP and TCP headers is already common and
> solves the problem at hand (avoiding reordering within a transport
> protocol).
> 
> MAC-based load balancing, besides not helping with the case I cited,
> also fails for systems with multiple NICs that stripe a single
transport
> across multiple interfaces (e.g., channel bonding). Granted, they're
> sort of 'asking for it', but it seems OK to use a fairly common
> technique if it solves this problem too.
> 
> Joe

PS - one final thought. We don't really need to spec any of this per se,
IMO. We can mention that per-MAC or per-transportflow is fine, and that
we leave it up to the rbridge implementation to decide which to support.
Again, so long as it's consistent within a single rbridge device it need
not be coordinated at all.

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

Date: Fri, 12 Aug 2005 15:42:17 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Summary 1 of load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1288

John Kristoff wrote:
> On Fri, 12 Aug 2005 16:29:09 +0100
> Mike Hughes <[email-masked]> wrote:
> 
> 
>>>From my operational perspective, MAC-based load-balancing just
>>
>>>*isn't* good
>>
>>enough, especially if you're dealing with a reasonable volume of
>>pre-aggregated traffic. (I've already sent my gory details, and I know
>>I'm not alone - though willing to accept being in a minority.)
> 
> 
> Fair enough.  It just seems to me the added complexity of peeking into
> upper layers may be problematic, but we live in an increasingly complex
> network environment these days.  I think I could envision similar
> problems that Joe described in the diagram with MAC-based flow load
> sharing when having to peek at the upper layers.  For instance, call
> his dst a VPN box.
> 
> John

Yeah - at some level, the aggregation is obfuscated by other layers. The
goal is to avoid reordering transport, but if there's no transport
visible there's (by definition) nothing you can do.

Joe

Date: Fri, 12 Aug 2005 14:59:09 -0700
From: Joe Touch <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Summary 1 of load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1751

Joe Touch wrote:
> 
> 
> John Kristoff wrote:
> 
>>>On Thu, 11 Aug 2005 14:40:33 -0700
>>>Joe Touch <[email-masked]> wrote:
>>>
>>>
>>>
>>>>That's when it would be useful to peek into not only the IP, but also
>>>>transport headers to mux across the pair of paths without reordering
>>>>within a transport connection.
>>>
>>>
>>>>From an operational perspective I'd prefer Alex's suggestion to use
>>>MAC addresses as the flow hash for load balancing.  It seems much
>>>simpler and seems to solve most of the problem.  Separate tools or
>>>other protocols can be used to achieve more perfect load balancing
>>>if it is needed.
> 
> 
> Load balancing by looking at IP and TCP headers is already common and
> solves the problem at hand (avoiding reordering within a transport
> protocol).
> 
> MAC-based load balancing, besides not helping with the case I cited,
> also fails for systems with multiple NICs that stripe a single transport
> across multiple interfaces (e.g., channel bonding). Granted, they're
> sort of 'asking for it', but it seems OK to use a fairly common
> technique if it solves this problem too.
> 
> Joe

PS - one final thought. We don't really need to spec any of this per se,
IMO. We can mention that per-MAC or per-transportflow is fine, and that
we leave it up to the rbridge implementation to decide which to support.
Again, so long as it's consistent within a single rbridge device it need
not be coordinated at all.

Joe

Date: Fri, 12 Aug 2005 14:56:09 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Summary 1 of load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1350

John Kristoff wrote:
> On Thu, 11 Aug 2005 14:40:33 -0700
> Joe Touch <[email-masked]> wrote:
> 
> 
>>That's when it would be useful to peek into not only the IP, but also
>>transport headers to mux across the pair of paths without reordering
>>within a transport connection.
> 
> 
>>From an operational perspective I'd prefer Alex's suggestion to use
> MAC addresses as the flow hash for load balancing.  It seems much
> simpler and seems to solve most of the problem.  Separate tools or
> other protocols can be used to achieve more perfect load balancing
> if it is needed.

Load balancing by looking at IP and TCP headers is already common and
solves the problem at hand (avoiding reordering within a transport
protocol).

MAC-based load balancing, besides not helping with the case I cited,
also fails for systems with multiple NICs that stripe a single transport
across multiple interfaces (e.g., channel bonding). Granted, they're
sort of 'asking for it', but it seems OK to use a fairly common
technique if it solves this problem too.

Joe

Date: Fri, 12 Aug 2005 14:47:54 -0700
From: Joe Touch <[email-masked]>
To: Vishwas Manral <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, [email-masked]
Subject: Re: [rbridge] Summary 1 of load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3693

Vishwas Manral wrote:
> Hi,
> 
> There are two things that need to be considered: -
> 
> 1. When there are fragments we cannot get the Layer-4 information (flow
> reordering can happen - unless we keep states).

That's not new for rbridges. Again, it seems useful not to have rbridges
try to solve every problem under the sun, but rather only the ones it
creates ;-)

> 2. Not all packets may have layer-4 information; some could be
> applications running over Layer-2/ Layer-3.
> 
> Currently different switches can use different criteria for doing load
> balancing. However if the criteria is a tag in the header it becomes
> easier and more consistent (like flow id). 

That just moves the problem to tag assignment, which may reduce
complexity for inner (non ingress/egress) rbridges, but does so at the
expense of a larger shim header.

It does not matter if different switches use different criteria for load
balancing, though - it matters only that each switch is consistent.
That's sufficient to avoid reordering throughout.

> I am not sure if we want to define a criterion for load balancing; we
> can however have a field in the header for the same (and let the ingress
> node decide the criteria, which could be configurable).

I still do not see the particular utility of reinventing MPLS-ish tags
in the shim header; if you want MPLS, you can use that. If not, then let
the interior rbridges decide how they want to handle load balancing
themselves. None of the peeking we're talking about is extraordinarily
complex.

Joe

> Thanks,
> Vishwas
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Alia Atlas
> Sent: Thursday, August 11, 2005 11:43 PM
> To: [email-masked]; Developing a hybrid router/bridge.
> Cc: Joe Touch
> Subject: [rbridge] Summary 1 of load-balancing rbridges
> 
> As per Radia's request, here's my best effort at a summarization.
> 
> The introduction of rbridges implies that rbridges will need to do
> load-balancing among equal-cost paths.  To avoid reordering at Layer
> 4, it is very desirable (even necessary) to have the rbridges able to
> identify the micro-flows.  There are 3 possible ways of doing this
> that were discussed.
> 
> (1) Each rbridge peeks under the rbridge shim header & encapsulated
> MAC frame to the (potentially) IP packet underneath.  If there is an
> IP packet, then an identification as to the micro-flow is made and the
> frame is forwarded based on the micro-flow.  Behavior if there isn't
> an IP packet hasn't been discussed.
> 
> (2) The ingress rbridge determines the micro-flow and marks the frame
> with a micro-flow tag in some way.  Interior (or midpoint) rbridges
> can use this tag to identify the micro-flow instead of having to peek
> underneath the rbridge shim header.  This is an optimization of (1)
> that reduces the complexity of interior rbridges at the cost of
> additional header size.
> 
> (3)Each egress rbridge could have a number of aliases.  The ingress
> rbridge identifies a micro-flow & forwards the frame to a particular
> alias, indicating a path.  There are some issues here with number of
> paths,  handling addresses connected to multiple egress rbridges, etc.
> 
> Option (2) seems promising, but whether it is the correct trade-off
> versus (1) needs more discussion and input.  Please comment.  :-)
> 
> Alia
> 

Date: Fri, 12 Aug 2005 10:55:54 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] questions on optimizing multicast
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2429

Ganesh CS wrote:
> Hi Radia,
> I have the following questions on optimizing multicast
> 
> 1. Currently 224.0.0.1 is used to reach all the routers in the local 
> segment and 224.0.0.2 is used to reach all hosts in the local segment. 
> With rbridges will the behaviour be retained ?

Yes. Note that on an rbridge, like any L2, the default would be that
both map to broadcast ;-)

> Because I find it 
> increasingly difficult to accomplish this using Rbridges. Roughly we may 
> have to build '2n' multicast distribution trees for 'n' subnets. Are we 
> going to provide equivalent functionality ?

There ought to be exactly two such trees for each vlan. I don't see how
this applies to subnets unless they're mapped to vlans.

> 2. Currently when an IGMP is initiated by a node it will reach all 
> routers in the same subnet. We looking at something similar i.e. till an 
> rbridge is reached kind-of behaviour in case of mixed (rbridge + legacy 
> bridge) environments. Right ?

Yes.

> 3. Do we account for the actual distance between rbridges in case of 
> mixed bridge environments before selecting a designated multicast 
> forwarding rbridge for a set of nodes ?

Internally, the rbridge can run any multicast protocol, and use that to
make the decision of which rbridge to forward for a set of nodes.

> 4. On cross-VLAN delivery, there is a issue of multicast scoping vs 
> efficient multicast delivery. If at all we require scoping then we 
> should go for VLAN based delivery and if scoping is not at all important 
> typically for a high volume multicast streams like video streams 
> efficient multicast delivery should be the goal. Is VLAN based scoping 
> really useful in rbridge scenarios ? What are the other mechanisms for 
> scoping that we propose ? One I could see is the ttl based scoping.

Keep in mind that an rbridge campus is a single LAN; AFAIK, there is no
scoping inside a single LAN. I

> 5. How do we coexist with IP multicast routing domains ?

INSIDE rbridges may run multicast routing, but to the outside they look
like an L2. I'm not sure how to map your question to that context...

Joe

Date: Fri, 12 Aug 2005 10:38:35 -0700
From: Alia Atlas <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1255

Hi Vishwas,

On 8/11/05, Vishwas Manral <[email-masked]> wrote:
> Hi Alia,
> 
> > If we're willing to require new hardware at every hop for
> > processing incoming frames and outgoing frames (within the
> > campus as well as to/from hosts), then it's not an issue.
> The current hardware (if you mean ASIC's) will not work as desired
> anyway because of issues I have brought up earlier.

Which ones?  I agree that none of this lets bridges handle link
aggregation where the bridges & link-aggregate are between two
rbridges.
 
> A simple thing like VLAN itself is decided based on deeper packet
> inspection (can be at each hop) and that will break with a new header
> coming in (mind you a VLAN aware network, need not necessarily be
> sending VLAN tags).

As I understand it, this is only needed for the multicast/broadcast
case, because in the unicast case, the packet is adddressed to the
egress rbridge.

> Only when we already have a VLAN tag and no deeper packet inspection is
> ever required (it is done on most switching ASIC's) will the Rbridge
> scenario work with existing hardware.

I agree that deep packet inspection is done on most switching ASICs
today - but this is will introduce a need to look deeper with some
variability.

Alia

Date: Fri, 12 Aug 2005 12:21:32 -0500
From: John Kristoff <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Summary 1 of load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 730

On Fri, 12 Aug 2005 16:29:09 +0100
Mike Hughes <[email-masked]> wrote:

> >From my operational perspective, MAC-based load-balancing just
> >*isn't* good
> enough, especially if you're dealing with a reasonable volume of
> pre-aggregated traffic. (I've already sent my gory details, and I know
> I'm not alone - though willing to accept being in a minority.)

Fair enough.  It just seems to me the added complexity of peeking into
upper layers may be problematic, but we live in an increasingly complex
network environment these days.  I think I could envision similar
problems that Joe described in the diagram with MAC-based flow load
sharing when having to peek at the upper layers.  For instance, call
his dst a VPN box.

John

Date: Fri, 12 Aug 2005 16:29:09 +0100
From: Mike Hughes <[email-masked]>
To: [email-masked]
Subject: Re: [rbridge] Summary 1 of load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1070

--On 12 August 2005 09:43 -0500 John Kristoff <[email-masked]> wrote:

> From an operational perspective I'd prefer Alex's suggestion to use
> MAC addresses as the flow hash for load balancing. 

>From my operational perspective, MAC-based load-balancing just *isn't* good
enough, especially if you're dealing with a reasonable volume of
pre-aggregated traffic. (I've already sent my gory details, and I know I'm
not alone - though willing to accept being in a minority.)

> Separate tools or other protocols can be used to achieve more perfect load
> balancing if it is needed.

If rbridge will be doing MAC-based load-balancing across equal cost paths,
and nothing more intelligent than that, then an "on/off" control knob needs
to be provided for in the specification.

Otherwise, don't do it at all, and leave it to other protocols - if a job
is worth doing, let's do it well.

Cheers,
Mike
-- 
Mike Hughes     Chief Technical Officer  London Internet Exchange
[email-masked]   http://www.linx.net/
     "Only one thing in life is certain: init is Process #1"

Date: Fri, 12 Aug 2005 09:43:55 -0500
From: John Kristoff <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Summary 1 of load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 538

On Thu, 11 Aug 2005 14:40:33 -0700
Joe Touch <[email-masked]> wrote:

> That's when it would be useful to peek into not only the IP, but also
> transport headers to mux across the pair of paths without reordering
> within a transport connection.

>From an operational perspective I'd prefer Alex's suggestion to use
MAC addresses as the flow hash for load balancing.  It seems much
simpler and seems to solve most of the problem.  Separate tools or
other protocols can be used to achieve more perfect load balancing
if it is needed.

John

Date: Fri, 12 Aug 2005 18:22:19 +0530
From: Ganesh CS <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] questions on optimizing multicast
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1446

Hi Radia,
I have the following questions on optimizing multicast

1. Currently 224.0.0.1 is used to reach all the routers in the local 
segment and 224.0.0.2 is used to reach all hosts in the local segment. 
With rbridges will the behaviour be retained ? Because I find it 
increasingly difficult to accomplish this using Rbridges. Roughly we may 
have to build '2n' multicast distribution trees for 'n' subnets. Are we 
going to provide equivalent functionality ?

2. Currently when an IGMP is initiated by a node it will reach all 
routers in the same subnet. We looking at something similar i.e. till an 
rbridge is reached kind-of behaviour in case of mixed (rbridge + legacy 
bridge) environments. Right ?

3. Do we account for the actual distance between rbridges in case of 
mixed bridge environments before selecting a designated multicast 
forwarding rbridge for a set of nodes ?

4. On cross-VLAN delivery, there is a issue of multicast scoping vs 
efficient multicast delivery. If at all we require scoping then we 
should go for VLAN based delivery and if scoping is not at all important 
typically for a high volume multicast streams like video streams 
efficient multicast delivery should be the goal. Is VLAN based scoping 
really useful in rbridge scenarios ? What are the other mechanisms for 
scoping that we propose ? One I could see is the ttl based scoping.

5. How do we coexist with IP multicast routing domains ?

-Ganesh

Content-class: urn:content-classes:message
Date: Thu, 11 Aug 2005 21:28:16 -0700
From: "Vishwas Manral" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Cc: Joe Touch <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2530

Hi Alia,

> If we're willing to require new hardware at every hop for 
> processing incoming frames and outgoing frames (within the 
> campus as well as to/from hosts), then it's not an issue.
The current hardware (if you mean ASIC's) will not work as desired
anyway because of issues I have brought up earlier. 

A simple thing like VLAN itself is decided based on deeper packet
inspection (can be at each hop) and that will break with a new header
coming in (mind you a VLAN aware network, need not necessarily be
sending VLAN tags).

Only when we already have a VLAN tag and no deeper packet inspection is
ever required (it is done on most switching ASIC's) will the Rbridge
scenario work with existing hardware.

Thanks,
Vishwas
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alia Atlas
Sent: Friday, August 12, 2005 1:57 AM
To: Developing a hybrid router/bridge.
Cc: Joe Touch
Subject: Re: [rbridge] load-balancing rbridges

On 8/11/05, Russ White <[email-masked]> wrote:
> 
> Or do we just say: "The ingress edge rbridge should compute a 32 bit
> hash across some locally determined set of fields, and send that in
the
> shim header?" I suppose it's possible to put the field in, and mark it
> for a specific purpose, but not actually specify how to choose which
> link to use based on it, or what specific hash to use to fill it in
(?).

This is what I was picturing.  I.e. the ingress does the intelligent
packet-crawling & puts a hash (of whatever size agreed) in the header.
 Then rbridges could use that hash instead of crawling through the
packet.

> Now, on the other hand, we're concerned about the forwarding asics in
> these bridges, and whether or not they could handle doiong the hashes
> locally. I think that depends on the type of equipment we're thinking
> will actually be playing the part of an rbridge. Most routers today
can
> look at least back to the port numbers to do hashes for load sharing,
so
> the current asics used in routers can do this sort of thing. Does that
> make it any less of an issue?

Certainly current routers can do it - and, if Alex's suggestion that
just considering the original src/dest MAC is enough, they could be
enhanced look at that as well.  But we're not talking routers - but
bridges and they may have different cost points.

If we're willing to require new hardware at every hop for processing
incoming frames and outgoing frames (within the campus as well as
to/from hosts), then it's not an issue.

Alia

Content-class: urn:content-classes:message
Date: Thu, 11 Aug 2005 21:13:43 -0700
From: "Vishwas Manral" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>, <[email-masked]>
Cc: Joe Touch <[email-masked]>
Subject: Re: [rbridge] Summary 1 of load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2441

Hi,

There are two things that need to be considered: -

1. When there are fragments we cannot get the Layer-4 information (flow
reordering can happen - unless we keep states).
2. Not all packets may have layer-4 information; some could be
applications running over Layer-2/ Layer-3.

Currently different switches can use different criteria for doing load
balancing. However if the criteria is a tag in the header it becomes
easier and more consistent (like flow id). 

I am not sure if we want to define a criterion for load balancing; we
can however have a field in the header for the same (and let the ingress
node decide the criteria, which could be configurable).

Thanks,
Vishwas
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alia Atlas
Sent: Thursday, August 11, 2005 11:43 PM
To: [email-masked]; Developing a hybrid router/bridge.
Cc: Joe Touch
Subject: [rbridge] Summary 1 of load-balancing rbridges

As per Radia's request, here's my best effort at a summarization.

The introduction of rbridges implies that rbridges will need to do
load-balancing among equal-cost paths.  To avoid reordering at Layer
4, it is very desirable (even necessary) to have the rbridges able to
identify the micro-flows.  There are 3 possible ways of doing this
that were discussed.

(1) Each rbridge peeks under the rbridge shim header & encapsulated
MAC frame to the (potentially) IP packet underneath.  If there is an
IP packet, then an identification as to the micro-flow is made and the
frame is forwarded based on the micro-flow.  Behavior if there isn't
an IP packet hasn't been discussed.

(2) The ingress rbridge determines the micro-flow and marks the frame
with a micro-flow tag in some way.  Interior (or midpoint) rbridges
can use this tag to identify the micro-flow instead of having to peek
underneath the rbridge shim header.  This is an optimization of (1)
that reduces the complexity of interior rbridges at the cost of
additional header size.

(3)Each egress rbridge could have a number of aliases.  The ingress
rbridge identifies a micro-flow & forwards the frame to a particular
alias, indicating a path.  There are some issues here with number of
paths,  handling addresses connected to multiple egress rbridges, etc.

Option (2) seems promising, but whether it is the correct trade-off
versus (1) needs more discussion and input.  Please comment.  :-)

Alia

Date: Thu, 11 Aug 2005 15:19:54 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1441

Bill Sommerfeld wrote:
> On Thu, 2005-08-11 at 17:43, Joe Touch wrote:
> 
>>>Incidentally, this second scenario appears to assume that the same MAC
>>>address can be connected to multiple rbridges.  Is this realistic?  I
>>>think I can see it for a bridge that is connected to both & has hosts
>>>behind the bridge.
>>
>>This doesn't make sense to me either. IMO, the spanning tree on the
>>right side (outside the campus) would dictate that only one of C or D
>>would be considered the egress for the destination.
> 
> Maybe I'm misunderstanding the topology diagrams but I'd hope that there
> would be some way for a host to be "multihomed" into an rbridge-based
> network in a way which provided for load-balancing.
> (perhaps the host would need to implement a "stub" rbridge?)

Rbridges provide additional internal bandwidth via multipath routing,
but outside the campus they're limited to existing ethernet bridging
capabilities.

AFAIK, there's no way to multihome a single ethernet MAC on a single L2
subnet to use two different bridges as part of the path - that violates
spanning tree (presuming spanning tree, of course).

Joe

From: Bill Sommerfeld <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Date: Thu, 11 Aug 2005 18:07:45 -0400
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 764

On Thu, 2005-08-11 at 17:43, Joe Touch wrote:
> > Incidentally, this second scenario appears to assume that the same MAC
> > address can be connected to multiple rbridges.  Is this realistic?  I
> > think I can see it for a bridge that is connected to both & has hosts
> > behind the bridge.
> 
> This doesn't make sense to me either. IMO, the spanning tree on the
> right side (outside the campus) would dictate that only one of C or D
> would be considered the egress for the destination.

Maybe I'm misunderstanding the topology diagrams but I'd hope that there
would be some way for a host to be "multihomed" into an rbridge-based
network in a way which provided for load-balancing.
(perhaps the host would need to implement a "stub" rbridge?)

						- Bill

Date: Thu, 11 Aug 2005 14:44:41 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1010

Alia Atlas wrote:
> On 8/11/05, Spencer Dawkins <[email-masked]> wrote:
> 
>> Sorry, still synchronizing - what we're talking about is introducing
>>additional misordering, right?
>> 
>> I wouldn't ask, but I have gotten sucked into some link layers that try to
>>deliver in-order, which ALSO tortures TCP because of apparent round-trip
>>variation while the receiver waits for a retransmission to forward in
>>order...
> 
> 
> Yes, just concerned about introducing additional misordering!  The
> other hadn't even occurred to me.

There are many reasons not to multipath TCP inside a link, if possible:

	- reordering
	- inconsistent RTTs
	- incosistent loss/collision rates
	- inconsistent BW

Joe

Date: Thu, 11 Aug 2005 14:43:29 -0700
From: Joe Touch <[email-masked]>
To: Alia Atlas <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 831

Alia Atlas wrote:
...
>>A---B---C---+
>>        |   +--(destination
>>        D---+
...
> Incidentally, this second scenario appears to assume that the same MAC
> address can be connected to multiple rbridges.  Is this realistic?  I
> think I can see it for a bridge that is connected to both & has hosts
> behind the bridge.

This doesn't make sense to me either. IMO, the spanning tree on the
right side (outside the campus) would dictate that only one of C or D
would be considered the egress for the destination.

Joe

Date: Thu, 11 Aug 2005 14:40:33 -0700
From: Joe Touch <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, [email-masked]
Subject: Re: [rbridge] Summary 1 of load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1256

Alex Zinin wrote:
> Alia,
> 
>  When I looked at it a couple of months ago, it seemed possible to hash
>  based on the original src+dst MAC addresses. This makes it L3/4-agnostic
>  and still gives sufficient traffic dispersion.

That won't help allow internal dispersion of flows between two hosts,
which may be useful to allow higher cross-section bandwidth.

I.e., consider a 100mbps flow that goes

                   a---b
                  /     \
   src--ingres---c       d---egress---dst
                  \     /
                   e---f

If the links a---b and e---f are needed by other cross-campus traffic,
the sum of a---b/e---f may be the only way that the src--dst pair can
achieve 100mbps.

However, all flows between them will be between the same src/dst MAC.

That's when it would be useful to peek into not only the IP, but also
transport headers to mux across the pair of paths without reordering
within a transport connection.

Joe

Date: Thu, 11 Aug 2005 14:36:12 -0700
From: Joe Touch <[email-masked]>
To: Russ White <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, [email-masked]
Subject: Re: [rbridge] Summary 1 of load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3234

Russ White wrote:
> 
> 
>>>The introduction of rbridges implies that rbridges will need to do
>>>load-balancing among equal-cost paths.  To avoid reordering at Layer
>>>4, it is very desirable (even necessary) to have the rbridges able to
>>>identify the micro-flows.  There are 3 possible ways of doing this
>>>that were discussed.
> 
> 
> There are actually two different issues with load sharing:
> 
> A) There are two equal cost paths through the rbridges backbone to any 
> given exit point along the edge).
> 
> B) A specific destination MAC address is reachable through two exit 
> points, both with equal cost, through the rbridge cloud.
> 
> A needs to be addressed. B doesn't, as it's an issue the ingress rbridge 
> should be hanlding.
> 
> 
>>>(1) Each rbridge peeks under the rbridge shim header & encapsulated
>>>MAC frame to the (potentially) IP packet underneath.  If there is an
>>>IP packet, then an identification as to the micro-flow is made and the
>>>frame is forwarded based on the micro-flow.  Behavior if there isn't
>>>an IP packet hasn't been discussed.
>>>
>>>(2) The ingress rbridge determines the micro-flow and marks the frame
>>>with a micro-flow tag in some way.  Interior (or midpoint) rbridges
>>>can use this tag to identify the micro-flow instead of having to peek
>>>underneath the rbridge shim header.  This is an optimization of (1)
>>>that reduces the complexity of interior rbridges at the cost of
>>>additional header size.
> 
> 
> 1 is the correct solution, I think. In fact, I would say this is 
> "implementation dependant," and the only language the draft actually 
> needs is something like:
> 
> If an rbridge loads shares over two different paths to reach a single 
> exit rbridge, it MUST do so in a way that prevents redordering of 
> packets within a flow. This MAY be done by examining a larger part of 
> the header of the packet within the shim header to correctly segregate 
> multiple flows.

I actually prefer this solution. It leaves the shim shorter, and I don't
see a real need to simplify this part of the operation of the internal
rbridges.

> I think that would about cover it, really. It doesn't matter if every 
> rbridge in the network does the separation in a different way, as long 
> as each one uses the same mechanism consistently.
> 
> :-)
> 
> Russ
> 
> 
> 
>>>(3)Each egress rbridge could have a number of aliases.  The ingress
>>>rbridge identifies a micro-flow & forwards the frame to a particular
>>>alias, indicating a path.  There are some issues here with number of
>>>paths,  handling addresses connected to multiple egress rbridges, etc.
>>>
>>>Option (2) seems promising, but whether it is the correct trade-off
>>>versus (1) needs more discussion and input.  Please comment.  :-)
>>>
>>>Alia
>>>_______________________________________________
>>>rbridge mailing list
>>>[email-masked]
>>>http://www.postel.org/mailman/listinfo/rbridge
> 
> 

Date: Thu, 11 Aug 2005 13:38:14 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] slides from IETF63 posted to website
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 442

Available at:

	http://www.postel.org/rbridge/trill-ietf63

these are linked off the main rbridge site:

	http://www.postel.org/rbridge

Joe

Date: Thu, 11 Aug 2005 13:27:25 -0700
From: Alia Atlas <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Cc: Joe Touch <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1537

On 8/11/05, Russ White <[email-masked]> wrote:
> 
> Or do we just say: "The ingress edge rbridge should compute a 32 bit
> hash across some locally determined set of fields, and send that in the
> shim header?" I suppose it's possible to put the field in, and mark it
> for a specific purpose, but not actually specify how to choose which
> link to use based on it, or what specific hash to use to fill it in (?).

This is what I was picturing.  I.e. the ingress does the intelligent
packet-crawling & puts a hash (of whatever size agreed) in the header.
 Then rbridges could use that hash instead of crawling through the
packet.

> Now, on the other hand, we're concerned about the forwarding asics in
> these bridges, and whether or not they could handle doiong the hashes
> locally. I think that depends on the type of equipment we're thinking
> will actually be playing the part of an rbridge. Most routers today can
> look at least back to the port numbers to do hashes for load sharing, so
> the current asics used in routers can do this sort of thing. Does that
> make it any less of an issue?

Certainly current routers can do it - and, if Alex's suggestion that
just considering the original src/dest MAC is enough, they could be
enhanced look at that as well.  But we're not talking routers - but
bridges and they may have different cost points.

If we're willing to require new hardware at every hop for processing
incoming frames and outgoing frames (within the campus as well as
to/from hosts), then it's not an issue.

Alia

Date: Thu, 11 Aug 2005 13:20:15 -0700
From: Alia Atlas <[email-masked]>
To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 512

On 8/11/05, Spencer Dawkins <[email-masked]> wrote:
>  Sorry, still synchronizing - what we're talking about is introducing
> additional misordering, right?
>  
>  I wouldn't ask, but I have gotten sucked into some link layers that try to
> deliver in-order, which ALSO tortures TCP because of apparent round-trip
> variation while the receiver waits for a retransmission to forward in
> order...

Yes, just concerned about introducing additional misordering!  The
other hadn't even occurred to me.

Alia

Date: Thu, 11 Aug 2005 15:46:43 -0400
From: Russ White <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Cc: Joe Touch <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4488

> I think that we do care about out of order packets.

Yes, I do, too.

> Incidentally, this second scenario appears to assume that the same MAC
> address can be connected to multiple rbridges.  Is this realistic?  I
> think I can see it for a bridge that is connected to both & has hosts
> behind the bridge.

I don't know, I just threw the case up to clarify (I hope).

>>I'm not certain we need any additional information in the shim header to
>>handle this (?). We do need to be careful about out of order packets,
>>though, I think. I know most layer 3 switching mechanisms rely on per
>>flow information to channel all information in a single flow along the
>>same path, while channeling other flows along other paths. That's also
>>possible here, if you allow the entry rbridge to peek at the layer 3
>>information, or even by just sorting out based on destination layer 2
>>address beyond the exit point, as long as you assume some sort of
>>"correct" or "well ordered" destination address spread on the
>>destination network.
> 
> It's worrying about the out of order packets that is the issue.  The
> question is whether every rbridge in the path has to peek at the layer
> 3 information - or whether it can be done once at the ingress & the
> results noted.  I believe that there are three advantages with the
> latter.
> 
> First, it reduces the complexity of the behavior requried by the
> interior.  Second, I believe that there is existing hardware that
> could possibly properly load-balance based on the shim header (if it
> looked like an MPLS shim), without forwarding path modifications. 
> (This isn't to claim that no hw changes would be necessary for
> multicast/broadcast...)
> 
> Third, having the ingress compute the hash opens the possibilities for
> intelligent hash generation and interaction with applications.  For
> instance, imagine that some flows care about in-order & some don't -
> or not as much.  An ingress rbridge could be configured to recognize
> the latter and use different hash values, to improve the throughput. 
> Even if the flow does care about mis-ordering, the ingress rbridge
> could be configured to explicitly ensure that certain flows don't have
> hash collisions.
> 
> In other words, one could put more intelligence at the edge to enable
> smarter behaviors and simplify the interior complexity.

Certainly--but if you put the hash at the ingress side, then you've 
essentially limited the ability of a specific implementation to hash 
differently for different load sharing characteristics. For instance, 
suppose that in one environment, you want to load share based on just 
the destination mac address, but in others, you might need to go deeper. 
Do you specify to always go deeper, and always eat the cost at the 
ingress rbridge, even though different devices might or might not need 
these capabilities?

To give a specific example--if you say you should always load share 
based on the destination ip address, then what if all the packets are 
destinted to a single server, from all sorts of different hosts? So, you 
add the source ip address into the hash, making the hash more expensive 
at the ingress edge. But now, add a NAT on the destination end, and you 
have to add in the destination port. Add a NAT on the source end, and 
you have to add in the source port. At what point does this stop?

Or do we just say: "The ingress edge rbridge should compute a 32 bit 
hash across some locally determined set of fields, and send that in the 
shim header?" I suppose it's possible to put the field in, and mark it 
for a specific purpose, but not actually specify how to choose which 
link to use based on it, or what specific hash to use to fill it in (?).

Now, on the other hand, we're concerned about the forwarding asics in 
these bridges, and whether or not they could handle doiong the hashes 
locally. I think that depends on the type of equipment we're thinking 
will actually be playing the part of an rbridge. Most routers today can 
look at least back to the port numbers to do hashes for load sharing, so 
the current asics used in routers can do this sort of thing. Does that 
make it any less of an issue?

:-)

Russ

- -- 
[email-masked] CCIE <>< Grace Alone

Date: Thu, 11 Aug 2005 14:38:19 -0500
From: Spencer Dawkins <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1390

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Alia Atlas wrote:<br>
<blockquote cite="[email-masked]"
 type="cite">
  <pre wrap="">Hi Russ,

On 8/11/05, Russ White <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a> wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Here, we have two different paths from the entry rbridge to the exit
rbridge. It's easy enough for B to compute two different paths to D, and
load share between those two paths--in fact, it doesn't much matter how
B goes about doing this, in terms of flow, etc, unless we want to worry
about out of order packets (which we might). This is a completely
different problem from this:
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I think that we do care about out of order packets.</pre>
</blockquote>
Sorry, still synchronizing - what we're talking about is introducing
additional misordering, right?<br>
<br>
I wouldn't ask, but I have gotten sucked into some link layers that try
to deliver in-order, which ALSO tortures TCP because of apparent
round-trip variation while the receiver waits for a retransmission to
forward in order...<br>
<br>
Spencer<br>
</body>
</html>

Date: Thu, 11 Aug 2005 11:57:06 -0700
From: Alex Zinin <[email-masked]>
To: Alia Atlas <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Summary 1 of load-balancing rbridges
Reply-To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1947

Alia,

 When I looked at it a couple of months ago, it seemed possible to hash
 based on the original src+dst MAC addresses. This makes it L3/4-agnostic
 and still gives sufficient traffic dispersion.

-- 
Alex
http://www.psg.com/~zinin

Thursday, August 11, 2005, 11:12:50 AM, Alia Atlas wrote:
> As per Radia's request, here's my best effort at a summarization.

> The introduction of rbridges implies that rbridges will need to do
> load-balancing among equal-cost paths.  To avoid reordering at Layer
> 4, it is very desirable (even necessary) to have the rbridges able to
> identify the micro-flows.  There are 3 possible ways of doing this
> that were discussed.

> (1) Each rbridge peeks under the rbridge shim header & encapsulated
> MAC frame to the (potentially) IP packet underneath.  If there is an
> IP packet, then an identification as to the micro-flow is made and the
> frame is forwarded based on the micro-flow.  Behavior if there isn't
> an IP packet hasn't been discussed.

> (2) The ingress rbridge determines the micro-flow and marks the frame
> with a micro-flow tag in some way.  Interior (or midpoint) rbridges
> can use this tag to identify the micro-flow instead of having to peek
> underneath the rbridge shim header.  This is an optimization of (1)
> that reduces the complexity of interior rbridges at the cost of
> additional header size.

> (3)Each egress rbridge could have a number of aliases.  The ingress
> rbridge identifies a micro-flow & forwards the frame to a particular
> alias, indicating a path.  There are some issues here with number of
> paths,  handling addresses connected to multiple egress rbridges, etc.

> Option (2) seems promising, but whether it is the correct trade-off
> versus (1) needs more discussion and input.  Please comment.  :-)

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

Date: Thu, 11 Aug 2005 11:50:59 -0700
From: Alia Atlas <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Cc: Joe Touch <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4056

Hi Russ,

On 8/11/05, Russ White <[email-masked]> wrote:
> Okay, I hate to do this, but I think we need to back up a bit, and make
> certain we understand the problems and complexities here. :-) Suppose we
> have this:
> 
> 
> A---B---C---D---(destination)
>      +---E---+
> 
> Here, we have two different paths from the entry rbridge to the exit
> rbridge. It's easy enough for B to compute two different paths to D, and
> load share between those two paths--in fact, it doesn't much matter how
> B goes about doing this, in terms of flow, etc, unless we want to worry
> about out of order packets (which we might). This is a completely
> different problem from this:

I think that we do care about out of order packets.
 
> A---B---C---+
>          |   +--(destination
>          D---+
> 
> Which is that there are two paths to the destination, but B isn't aware
> of this. It seems like the solution proposed is for A to build a hash
> and include it in the shim header, so that B will forward some amount of
> traffic over the link to C, and some amount to D, load sharing the
> traffic. This seems like it's not really needed (?), since A is actually
> going to be able to encap the traffic to C or D directly, so A could
> just change the destination shim destination in the header on every
> other packet (or based on flows) so the traffic takes different paths
> through B to reach the destination.

Whether A computes a hash and includes it in the shim header is
orthogonal to the two cases that you've described.

In the latter case, A must be the ingress rbridge.  A will have 2
next-hops; the first will be given an egress rbridge of C and the
second will be given an egress rbridge of D.  A will load-balance
among them.  To B, these will look like frames to separate
destinations.

Incidentally, this second scenario appears to assume that the same MAC
address can be connected to multiple rbridges.  Is this realistic?  I
think I can see it for a bridge that is connected to both & has hosts
behind the bridge.

> Does this make sense, or did I lose it (it's been known to happen, I
> know....)? :-)
> 
> I'm not certain we need any additional information in the shim header to
> handle this (?). We do need to be careful about out of order packets,
> though, I think. I know most layer 3 switching mechanisms rely on per
> flow information to channel all information in a single flow along the
> same path, while channeling other flows along other paths. That's also
> possible here, if you allow the entry rbridge to peek at the layer 3
> information, or even by just sorting out based on destination layer 2
> address beyond the exit point, as long as you assume some sort of
> "correct" or "well ordered" destination address spread on the
> destination network.

It's worrying about the out of order packets that is the issue.  The
question is whether every rbridge in the path has to peek at the layer
3 information - or whether it can be done once at the ingress & the
results noted.  I believe that there are three advantages with the
latter.

First, it reduces the complexity of the behavior requried by the
interior.  Second, I believe that there is existing hardware that
could possibly properly load-balance based on the shim header (if it
looked like an MPLS shim), without forwarding path modifications. 
(This isn't to claim that no hw changes would be necessary for
multicast/broadcast...)

Third, having the ingress compute the hash opens the possibilities for
intelligent hash generation and interaction with applications.  For
instance, imagine that some flows care about in-order & some don't -
or not as much.  An ingress rbridge could be configured to recognize
the latter and use different hash values, to improve the throughput. 
Even if the flow does care about mis-ordering, the ingress rbridge
could be configured to explicitly ensure that certain flows don't have
hash collisions.

In other words, one could put more intelligence at the edge to enable
smarter behaviors and simplify the interior complexity.

Alia

Date: Thu, 11 Aug 2005 14:47:12 -0400
From: Russ White <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Summary 1 of load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2932

> The introduction of rbridges implies that rbridges will need to do
> load-balancing among equal-cost paths.  To avoid reordering at Layer
> 4, it is very desirable (even necessary) to have the rbridges able to
> identify the micro-flows.  There are 3 possible ways of doing this
> that were discussed.

There are actually two different issues with load sharing:

A) There are two equal cost paths through the rbridges backbone to any 
given exit point along the edge).

B) A specific destination MAC address is reachable through two exit 
points, both with equal cost, through the rbridge cloud.

A needs to be addressed. B doesn't, as it's an issue the ingress rbridge 
should be hanlding.

> (1) Each rbridge peeks under the rbridge shim header & encapsulated
> MAC frame to the (potentially) IP packet underneath.  If there is an
> IP packet, then an identification as to the micro-flow is made and the
> frame is forwarded based on the micro-flow.  Behavior if there isn't
> an IP packet hasn't been discussed.
> 
> (2) The ingress rbridge determines the micro-flow and marks the frame
> with a micro-flow tag in some way.  Interior (or midpoint) rbridges
> can use this tag to identify the micro-flow instead of having to peek
> underneath the rbridge shim header.  This is an optimization of (1)
> that reduces the complexity of interior rbridges at the cost of
> additional header size.

1 is the correct solution, I think. In fact, I would say this is 
"implementation dependant," and the only language the draft actually 
needs is something like:

If an rbridge loads shares over two different paths to reach a single 
exit rbridge, it MUST do so in a way that prevents redordering of 
packets within a flow. This MAY be done by examining a larger part of 
the header of the packet within the shim header to correctly segregate 
multiple flows.

I think that would about cover it, really. It doesn't matter if every 
rbridge in the network does the separation in a different way, as long 
as each one uses the same mechanism consistently.

:-)

Russ

> 
> (3)Each egress rbridge could have a number of aliases.  The ingress
> rbridge identifies a micro-flow & forwards the frame to a particular
> alias, indicating a path.  There are some issues here with number of
> paths,  handling addresses connected to multiple egress rbridges, etc.
> 
> Option (2) seems promising, but whether it is the correct trade-off
> versus (1) needs more discussion and input.  Please comment.  :-)
> 
> Alia
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://www.postel.org/mailman/listinfo/rbridge

- -- 
[email-masked] CCIE <>< Grace Alone

Date: Thu, 11 Aug 2005 11:16:14 -0700
From: Alia Atlas <[email-masked]>
To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Cc: Joe Touch <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1380

On 8/10/05, Radia Perlman <[email-masked]> wrote:
> MPLS though allows multiple paths to be set up between A and B (where
> "A" is presumably a router, or something that is MPLS-aware), and
> allows A to decide which path to send it on. A has complete control. Once
> it selects the MPLS path, the packet's journey is completely determined.

MPLS actually has 2 models.  In the first LDP model, MPLS behaves just
like IP; each router does the load-balancing among the equal-cost
paths itself.  In the second TE model, the ingress explicitly creates
paths (LSPs) and then can load-balance among those paths.
 
> So, I'm not sure whether I'm being helpful here because I'm having trouble
> understanding this thread (as I said, I need Joe or Alia to summarize),
> but what I'm saying is that there are two ways of doing path splitting;
> one where someone close to the source determines the remaining path
> (which requires something like MPLS), and the other where each
> router along the way independently chooses among different paths.
> You *might* be able to have an upstream router add advice to the header
> for downstream routers to choose which path to use, but if you're
> going to do that, it seems better to just use MPLS.

The trick with MPLS TE is that the head-end explicitly sets up the
paths ahead of time.  Do we want to go there?  I didn't think so.

Alia

Date: Thu, 11 Aug 2005 11:12:50 -0700
From: Alia Atlas <[email-masked]>
To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Cc: Joe Touch <[email-masked]>
Subject: [rbridge] Summary 1 of load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1459

As per Radia's request, here's my best effort at a summarization.

The introduction of rbridges implies that rbridges will need to do
load-balancing among equal-cost paths.  To avoid reordering at Layer
4, it is very desirable (even necessary) to have the rbridges able to
identify the micro-flows.  There are 3 possible ways of doing this
that were discussed.

(1) Each rbridge peeks under the rbridge shim header & encapsulated
MAC frame to the (potentially) IP packet underneath.  If there is an
IP packet, then an identification as to the micro-flow is made and the
frame is forwarded based on the micro-flow.  Behavior if there isn't
an IP packet hasn't been discussed.

(2) The ingress rbridge determines the micro-flow and marks the frame
with a micro-flow tag in some way.  Interior (or midpoint) rbridges
can use this tag to identify the micro-flow instead of having to peek
underneath the rbridge shim header.  This is an optimization of (1)
that reduces the complexity of interior rbridges at the cost of
additional header size.

(3)Each egress rbridge could have a number of aliases.  The ingress
rbridge identifies a micro-flow & forwards the frame to a particular
alias, indicating a path.  There are some issues here with number of
paths,  handling addresses connected to multiple egress rbridges, etc.

Option (2) seems promising, but whether it is the correct trade-off
versus (1) needs more discussion and input.  Please comment.  :-)

Alia

Date: Thu, 11 Aug 2005 11:22:36 -0400
From: Russ White <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Cc: Joe Touch <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2740

> So then the question is confined to how does an rbridge do
> load-balancing.  It seems like there are two possibilities that we're
> discussing.  Either the mid-point rbridge needs to be able to peek
> past the shim header, the encapsulated MAC addresses, and find the IP
> header, determine if it is an IP header, and then compute some hash on
> that, or the ingress rbridge needs to do the same and somehow indicate
> its hash downstream.

Okay, I hate to do this, but I think we need to back up a bit, and make 
certain we understand the problems and complexities here. :-) Suppose we 
have this:

A---B---C---D---(destination)
     +---E---+

Here, we have two different paths from the entry rbridge to the exit 
rbridge. It's easy enough for B to compute two different paths to D, and 
load share between those two paths--in fact, it doesn't much matter how 
B goes about doing this, in terms of flow, etc, unless we want to worry 
about out of order packets (which we might). This is a completely 
different problem from this:

A---B---C---+
         |   +--(destination
         D---+

Which is that there are two paths to the destination, but B isn't aware 
of this. It seems like the solution proposed is for A to build a hash 
and include it in the shim header, so that B will forward some amount of 
traffic over the link to C, and some amount to D, load sharing the 
traffic. This seems like it's not really needed (?), since A is actually 
going to be able to encap the traffic to C or D directly, so A could 
just change the destination shim destination in the header on every 
other packet (or based on flows) so the traffic takes different paths 
through B to reach the destination.

Does this make sense, or did I lose it (it's been known to happen, I 
know....)? :-)

I'm not certain we need any additional information in the shim header to 
handle this (?). We do need to be careful about out of order packets, 
though, I think. I know most layer 3 switching mechanisms rely on per 
flow information to channel all information in a single flow along the 
same path, while channeling other flows along other paths. That's also 
possible here, if you allow the entry rbridge to peek at the layer 3 
information, or even by just sorting out based on destination layer 2 
address beyond the exit point, as long as you assume some sort of 
"correct" or "well ordered" destination address spread on the 
destination network.

:-)

Russ

- -- 
[email-masked] CCIE <>< Grace Alone

Date: Thu, 11 Aug 2005 10:28:55 +0100
From: Mike Hughes <[email-masked]>
To: [email-masked]
Subject: [rbridge] load balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2558

Hi folks,

Still catching up on what's been going on with rbridge, and I missed Paris
because of Summer hols. As someone who runs a network for where rbridges
would be an ideal solution to a raft of architectural nags, I'm starting to
follow things with interest.

Thinking about load balancing, I think we've already asserted the need to
prevent evils like packet re-ordering for a traffic flow across the
topology.

When running my plain old ethernet campus network (around Docklands in
London, for those who don't know), I came across issues (5 years ago)
trying to do even the most basic loadsharing across a point-to-point GE
link agg. Circuits in a link-agg group would become over-subscribed, while
others remained heavily under utilised. 

This was mostly because vendors were not peeking deeply enough into the
frame/packet to create a worthwhile hash. They were often just doing L2
dest, ingress port (aagh!) or L2 src/dest hashing - and variants of this
such as partial L2 src/dest or ingress port/L2 dest.

In my network, it's a relatively small number of end stations sourcing a
large amount of traffic - around 200 stations sourcing over 30G of traffic
today - there was a need to look deeper in the packet to make a workable
hash, because of the restricted "gene pool" at L2.

After enough beating up from myself (and some other IX operators, and
probably others elsewhere that I never met), all the larger 10GE switch
vendors are now doing better hashing, usually based on the L3/4 header
information as well. This often works for them, in their architectures,
because it's still only one CAM cycle for them - because of the (unused, in
our case) L3 functionality built into the boxes, they are reading the L3
info, but usually doing nothing with it if the box is working L2-only.

In short, I'm agreeing with those who say that you need to look inside the
payload header to generate the hash for ECMP sharing. This should give you
a reasonable balance of traffic, and keep flows running along the same path
through the network. That hash should be done by the ingress rbridge, and
not touched by the intermediate nodes in the topology, unless there is a
topology change while the frame is transiting the network.

I think you've got to "peek" down into the payload, because of the
likelihood of a limited gene pool at the L2 MAC and rbridge MAC/shim layers.

Thanks,
Mike
-- 
Mike Hughes     Chief Technical Officer  London Internet Exchange
[email-masked]   http://www.linx.net/
     "Only one thing in life is certain: init is Process #1"

Content-class: urn:content-classes:message
Date: Wed, 10 Aug 2005 23:15:43 -0700
From: "Vishwas Manral" <[email-masked]>
To: <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Cc: Joe Touch <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3711

Hi,

When we do Link aggregation (LACP), we already to load-balancing between
Ethernet links (though this is between about parallel links - which
would be one link to STP currently).

As Radia said in current implementations, we do it on a flow basis. Load
balancing criteria currently used are source address, destination
address, and address pairs, TCP, UDP ports and even five-tuple
based(there is a default criteria based on layer-2 alone, if for example
we have fragments and cannot get the port numbers).

Thanks,
Vishwas
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: Thursday, August 11, 2005 11:13 AM
To: Developing a hybrid router/bridge.
Cc: Joe Touch
Subject: Re: [rbridge] load-balancing rbridges

I'm travelling, so don't have too much time for
email, and notice this very long thread.
I suspect more people than just me would appreciate if it one of you
would summarize the conclusions of this thread so far.

In skimming...some comments...
traditional bridges and traditional IP routers forward based solely
on destination address. However, routers can keep multiple paths to
the destination, and choose between them based on some other criteria.

One story I sometimes tell is that, fresh out of school, I could
throw around queing theory and prove that you'd get better network
utilization if you did path-splitting (presumably, round-robin).
Then Dave Clark pointed out that this makes life hard for layer 4...
packets get arbitrarily out of order, it's hard to measure round
trip delay, it's hard to figure out MTU size, etc. So then I
switched to advocating, if you keep multiple paths, to deterministically
choose the path so that the same flow will always go the same way.
I think that's how routers tend to be implemented today...each
router can independently do some sort of hash based on source address,
perhaps ports, perhaps TOS information, and use the hash to make
a selection from the equal (or almost-equal) cost paths.

Bridges really can't load-split, unless you
do something (like what has been suggested and possibly deployed)
of having different spanning trees for different types of packets, where
all the bridges know somehow which type of packet, and therefore, which
spanning tree, the packet belongs on.

MPLS though allows multiple paths to be set up between A and B (where
"A" is presumably a router, or something that is MPLS-aware), and
allows A to decide which path to send it on. A has complete control.
Once
it selects the MPLS path, the packet's journey is completely determined.

So, I'm not sure whether I'm being helpful here because I'm having
trouble
understanding this thread (as I said, I need Joe or Alia to summarize),
but what I'm saying is that there are two ways of doing path splitting;
one where someone close to the source determines the remaining path
(which requires something like MPLS), and the other where each
router along the way independently chooses among different paths.
You *might* be able to have an upstream router add advice to the header
for downstream routers to choose which path to use, but if you're
going to do that, it seems better to just use MPLS.

I might be completely off-base on this thread, in which case ignore my
comment, but please, if one of you would be willing to summarize the
thread, I and others will be quite grateful.

Oh, and if you do, can you make the subject line "Summary 1 of
load-balancing bridges"
(then if there is another flurry of messages, someone can add a "summary
2" note, with the theory that if a thread has a "summary" note, you can
catch up by starting at the most recent "summary" note.

Thanks,
Radia

Date: Wed, 10 Aug 2005 22:43:17 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Cc: Joe Touch <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2920

I'm travelling, so don't have too much time for
email, and notice this very long thread.
I suspect more people than just me would appreciate if it one of you
would summarize the conclusions of this thread so far.

In skimming...some comments...
traditional bridges and traditional IP routers forward based solely
on destination address. However, routers can keep multiple paths to
the destination, and choose between them based on some other criteria.

One story I sometimes tell is that, fresh out of school, I could
throw around queing theory and prove that you'd get better network
utilization if you did path-splitting (presumably, round-robin).
Then Dave Clark pointed out that this makes life hard for layer 4...
packets get arbitrarily out of order, it's hard to measure round
trip delay, it's hard to figure out MTU size, etc. So then I
switched to advocating, if you keep multiple paths, to deterministically
choose the path so that the same flow will always go the same way.
I think that's how routers tend to be implemented today...each
router can independently do some sort of hash based on source address,
perhaps ports, perhaps TOS information, and use the hash to make
a selection from the equal (or almost-equal) cost paths.

Bridges really can't load-split, unless you
do something (like what has been suggested and possibly deployed)
of having different spanning trees for different types of packets, where
all the bridges know somehow which type of packet, and therefore, which
spanning tree, the packet belongs on.

MPLS though allows multiple paths to be set up between A and B (where
"A" is presumably a router, or something that is MPLS-aware), and
allows A to decide which path to send it on. A has complete control. Once
it selects the MPLS path, the packet's journey is completely determined.

So, I'm not sure whether I'm being helpful here because I'm having trouble
understanding this thread (as I said, I need Joe or Alia to summarize),
but what I'm saying is that there are two ways of doing path splitting;
one where someone close to the source determines the remaining path
(which requires something like MPLS), and the other where each
router along the way independently chooses among different paths.
You *might* be able to have an upstream router add advice to the header
for downstream routers to choose which path to use, but if you're
going to do that, it seems better to just use MPLS.

I might be completely off-base on this thread, in which case ignore my
comment, but please, if one of you would be willing to summarize the
thread, I and others will be quite grateful.

Oh, and if you do, can you make the subject line "Summary 1 of
load-balancing bridges"
(then if there is another flurry of messages, someone can add a "summary
2" note, with the theory that if a thread has a "summary" note, you can
catch up by starting at the most recent "summary" note.

Thanks,

Radia

Date: Wed, 10 Aug 2005 16:39:11 -0700
From: Alia Atlas <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2913

On 8/10/05, Joe Touch <[email-masked]> wrote:
> >>IMO, the goal is to reuse existing solutions as much as possible here...
> >
> >
> > Yes, I agree.  The problem is that no hardware is used to digging that
> > far into the packet, as far as I know.
> >
> > In the back of my mind is the following.  First, assume that the shim
> > header has the structure of an MPLS shim header.  Second, assume that
> > the egress rbridge is represented by an MPLS label.  (For now, let's
> > not worry about the label distribution pieces yet or the
> > multicast/broadcast where the ingress rbridge is needed.)
> >
> > Third, what is underneath the shim header is not an IP packet & will
> > not be identified as one.
> 
> But anything we can't parse we can't assign to a specific flow, unless
> we send all such things to a single default path. Otherwise those
> packets will be reordered.

I am assuming that the ingress is capable of doing more parsing.  For
instance, the ingress gets the frame before encapsulation & can use
current peeking technology to look inside it.

> > So, for hardware that supports, say, MPLS
> > pseudo-wires, the frame would be forwarded based on a hash of the MPLS
> > label stack.  This implies that the ingress rbridge could put a hash
> > as the inner label (under the egress rbridge label) & the good
> > load-balancing could happen.
> 
> The only flows you will have a hash for are those that the ingress can
> parse, i.e., those with an inner IP/transport header. If the ingress can
> parse them sufficiently to create a hash, then so can the interior
> rbridge nodes. The only difference is that the interior nodes need to go
> past the shim header, but that's just an offset.

First, the question is whether one is trading off the interior
complexity for the edge.  It's certainly possible for the interior to
have to dig further down, and maybe that's necessary for the
broadcast/multicast, but if it is avoidable, that might be good.

Getting past the shim header may or may not be completely trivial.  It
depends on the forwarding path architecture.  For instance, once could
store most of the frame & only pass the beginning to the hardware that
makes a forwarding decision.

> > Of course, this assumes that the egress rbridge can pop off the 2
> > labels and that the inner label isn't actually ever used for
> > forwarding, but that seems somewhat reasonable to me.
> >
> > Thoughts?
> 
> I'm not sure what it buys to do the hash only at the ingress vs. at the
> interior nodes. Both have the same amount of info. It doesn't seem to
> hurt anything; it trades edge complexity for interior (which is good)
> but costs bandwidth by making the shim larger (which is bad). Seems like
> a toss-up to me...

For bw, we're talking an extra 32 bits.  I think of it as more a
question of complexity in implementation for the interior nodes & how
much functionality can be preserved.

Alia

Date: Wed, 10 Aug 2005 16:10:51 -0700
From: Joe Touch <[email-masked]>
To: Alia Atlas <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3689

Alia Atlas wrote:
> On 8/10/05, Joe Touch <[email-masked]> wrote:
> 
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>
>>
>>Alia Atlas wrote:
>>...
>>
>>>>>I agree.  I think I'd prefer something based on the hashing; then the
>>>>>question is whether one needs independent hashing or whether there's
>>>>>an advantage to doing it at the ingress.  Doing it at the ingress
>>>>>could give a bit of control (maybe some flows don't care about
>>>>>re-ordering) and might limit the required logic to the non-campus
>>>>>facing ports.
>>>>
>>>>It also makes some of the interior rbridge logic simpler; note that the
>>>>ingress/egress complexity is different than the interior rbridge
>>>>complexity already.
>>>
>>>Ok.  Did we just converge?  :-)
>>>
>>>Alia
>>
>>Subject to "this is an optimization", I think so. But since it's an
>>optimization, I haven't given it very deep thought.
> 
> 
> Sure :-) 
>  
> 
>>I was hoping the interior of the system would do 'multipath routing to
>>an egress' the same way that IP networks can/do. Which is why peeking
>>inside the IP header at interior rbridges might be more appropriate,
>>come to think of it. But I don't have enough experience with that - it
>>might be useful for others with multipath routing experience to chime in.
> 
> 
> I've got a fair amount of router forwarding path experience; I don't
> have as much on the ethernet bridging side.  More comments are always
> useful :-)
> 
> 
>>IMO, the goal is to reuse existing solutions as much as possible here...
> 
> 
> Yes, I agree.  The problem is that no hardware is used to digging that
> far into the packet, as far as I know.
> 
> In the back of my mind is the following.  First, assume that the shim
> header has the structure of an MPLS shim header.  Second, assume that
> the egress rbridge is represented by an MPLS label.  (For now, let's
> not worry about the label distribution pieces yet or the
> multicast/broadcast where the ingress rbridge is needed.)
> 
> Third, what is underneath the shim header is not an IP packet & will
> not be identified as one.

But anything we can't parse we can't assign to a specific flow, unless
we send all such things to a single default path. Otherwise those
packets will be reordered.

> So, for hardware that supports, say, MPLS
> pseudo-wires, the frame would be forwarded based on a hash of the MPLS
> label stack.  This implies that the ingress rbridge could put a hash
> as the inner label (under the egress rbridge label) & the good
> load-balancing could happen.

The only flows you will have a hash for are those that the ingress can
parse, i.e., those with an inner IP/transport header. If the ingress can
parse them sufficiently to create a hash, then so can the interior
rbridge nodes. The only difference is that the interior nodes need to go
past the shim header, but that's just an offset.

> Of course, this assumes that the egress rbridge can pop off the 2
> labels and that the inner label isn't actually ever used for
> forwarding, but that seems somewhat reasonable to me.
> 
> Thoughts?

I'm not sure what it buys to do the hash only at the ingress vs. at the
interior nodes. Both have the same amount of info. It doesn't seem to
hurt anything; it trades edge complexity for interior (which is good)
but costs bandwidth by making the shim larger (which is bad). Seems like
a toss-up to me...

Joe

> Alia

Date: Wed, 10 Aug 2005 16:01:54 -0700
From: Alia Atlas <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2473

On 8/10/05, Joe Touch <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Alia Atlas wrote:
> ...
> >>>I agree.  I think I'd prefer something based on the hashing; then the
> >>>question is whether one needs independent hashing or whether there's
> >>>an advantage to doing it at the ingress.  Doing it at the ingress
> >>>could give a bit of control (maybe some flows don't care about
> >>>re-ordering) and might limit the required logic to the non-campus
> >>>facing ports.
> >>
> >>It also makes some of the interior rbridge logic simpler; note that the
> >>ingress/egress complexity is different than the interior rbridge
> >>complexity already.
> >
> > Ok.  Did we just converge?  :-)
> >
> > Alia
> 
> Subject to "this is an optimization", I think so. But since it's an
> optimization, I haven't given it very deep thought.

Sure :-) 
 
> I was hoping the interior of the system would do 'multipath routing to
> an egress' the same way that IP networks can/do. Which is why peeking
> inside the IP header at interior rbridges might be more appropriate,
> come to think of it. But I don't have enough experience with that - it
> might be useful for others with multipath routing experience to chime in.

I've got a fair amount of router forwarding path experience; I don't
have as much on the ethernet bridging side.  More comments are always
useful :-)

> IMO, the goal is to reuse existing solutions as much as possible here...

Yes, I agree.  The problem is that no hardware is used to digging that
far into the packet, as far as I know.

In the back of my mind is the following.  First, assume that the shim
header has the structure of an MPLS shim header.  Second, assume that
the egress rbridge is represented by an MPLS label.  (For now, let's
not worry about the label distribution pieces yet or the
multicast/broadcast where the ingress rbridge is needed.)

Third, what is underneath the shim header is not an IP packet & will
not be identified as one.  So, for hardware that supports, say, MPLS
pseudo-wires, the frame would be forwarded based on a hash of the MPLS
label stack.  This implies that the ingress rbridge could put a hash
as the inner label (under the egress rbridge label) & the good
load-balancing could happen.

Of course, this assumes that the egress rbridge can pop off the 2
labels and that the inner label isn't actually ever used for
forwarding, but that seems somewhat reasonable to me.

Thoughts?

Alia

Date: Wed, 10 Aug 2005 15:50:13 -0700
From: Joe Touch <[email-masked]>
To: Alia Atlas <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1463

Alia Atlas wrote:
...
>>>I agree.  I think I'd prefer something based on the hashing; then the
>>>question is whether one needs independent hashing or whether there's
>>>an advantage to doing it at the ingress.  Doing it at the ingress
>>>could give a bit of control (maybe some flows don't care about
>>>re-ordering) and might limit the required logic to the non-campus
>>>facing ports.
>>
>>It also makes some of the interior rbridge logic simpler; note that the
>>ingress/egress complexity is different than the interior rbridge
>>complexity already.
> 
> Ok.  Did we just converge?  :-)  
> 
> Alia

Subject to "this is an optimization", I think so. But since it's an
optimization, I haven't given it very deep thought.

I was hoping the interior of the system would do 'multipath routing to
an egress' the same way that IP networks can/do. Which is why peeking
inside the IP header at interior rbridges might be more appropriate,
come to think of it. But I don't have enough experience with that - it
might be useful for others with multipath routing experience to chime in.

IMO, the goal is to reuse existing solutions as much as possible here...

Joe

Date: Wed, 10 Aug 2005 15:43:34 -0700
From: Alia Atlas <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2663

On 8/10/05, Joe Touch <[email-masked]> wrote:
> > I guess I am picturing a relatively standard SPF algorithm.  All
> > aliases advertised by an rbridge would have the same destination
> > sink-tree.
> 
> But they ought to have different next-hops at some point inside the
> campus, or there wouldn't be alternate paths. The different next-hops
> show up as different forwarding entries.

The sink-tree looks the same for all aliases.  It's not really quite a
tree, because an rbridge can be connected by multiple links (those
being the ecmp points).
 
> > As a midpoint rbridge, how would I decide which path to
> > use for which alias?  Do I randomly sprinkle the aliases among the
> > paths?
> 
> If you have only one outgoing nexthop, both alises would forward there
> and there would be no multipath. If you have multiple next-hops, you
> would assign one to each of the aliases and enter both into your
> forwarding table.

This seems to me to require storing some state about the assignment of
next-hops to aliases for when new aliases are learned and when the
topology changes.  I agree that it is possible, but it seems somewhat
messy to me.

> > Right.  What I'm missing is the logic in the SPF algorithm that
> > detemines what the forwarding entries should be.  Also, this increases
> > the forwarding entry space necessary as a consequence of the
> > complexity of the campus and the number of aliases...
> 
> Yes, but the complexity is there anyway. Either way there needs to be
> one entry per egress/path pair, i.e., for multiple nexthops to an
> egress, there need to be multiple entries anyway.

The number of aliases isn't tuned to the different number of next-hops
at a particular midpoint rbridge.  Also, there's a difference between
increasing the addresses known and the size of the resulting
forwarding result.  One grows your look-up structure while the other
is merely more memory.  Also, the former requires the resources from
the whole campus.  In the latter case, each rbridge can make decisions
about what degree and number of ecmp next-hops to support.
 
> > I agree.  I think I'd prefer something based on the hashing; then the
> > question is whether one needs independent hashing or whether there's
> > an advantage to doing it at the ingress.  Doing it at the ingress
> > could give a bit of control (maybe some flows don't care about
> > re-ordering) and might limit the required logic to the non-campus
> > facing ports.
> 
> It also makes some of the interior rbridge logic simpler; note that the
> ingress/egress complexity is different than the interior rbridge
> complexity already.

Ok.  Did we just converge?  :-)  

Alia

Date: Wed, 10 Aug 2005 15:29:56 -0700
From: Joe Touch <[email-masked]>
To: Alia Atlas <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5411

Alia Atlas wrote:
> On 8/10/05, Joe Touch <[email-masked]> wrote:
> 
> 
>>>>>I would be concerned about using alternate addresses; this implies
>>>>>knowledge on the number of different equal-cost paths available at
>>>>>each point in the campus.
>>>>
>>>>We can - and probably need to - assign different addresses for each
>>>>interface on an egress. We could certainly assign different ones if
>>>>desired, i.e., as aliases. When multiple equal-cost paths exist, the
>>>>entries can be split out in the forwarding table. The ingress already
>>>>needs to know which egress rbridge to pick; if there are aliases, it can
>>>>select them on a per-flow basis.
>>>
>>>Why do we need to assign different addresses for each interface on an
>>>egress??  Wouldn't the egress rbridge receive the frame, remove the
>>>encapsulation, and then decide which local interface to forward the
>>>frame on based upon the remaining frame?
>>
>>I'm speaking of multiple interfaces on the campus-side of the egress, or
>>aliases to the single interface on the campus-side. The addresses can
>>then used for path differentiation in the routing algorithm.
>>
>>
>>>I'm confused by your suggestions for the per-path aliases; doesn't
>>>that require the the midpoint rbridge know what path is intended for a
>>>particular alias?
>>
>>Yes - that would mean that different aliases would have different paths.
>>That's one version of the solution that could work.
> 
> I guess I am picturing a relatively standard SPF algorithm.  All
> aliases advertised by an rbridge would have the same destination
> sink-tree. 

But they ought to have different next-hops at some point inside the
campus, or there wouldn't be alternate paths. The different next-hops
show up as different forwarding entries.

> As a midpoint rbridge, how would I decide which path to
> use for which alias?  Do I randomly sprinkle the aliases among the
> paths?

If you have only one outgoing nexthop, both alises would forward there
and there would be no multipath. If you have multiple next-hops, you
would assign one to each of the aliases and enter both into your
forwarding table.

>>>The midpoint rbridge will still receive a frame
>>>and need to decide which of the multiple equal-cost paths it needs to
>>>be sent upon.  Could you clarify with an example?
>>
>>I'm expecting that it could have different forwarding entries for the
>>different aliases for the egress. The net effect is to use the egress
>>address as a both the egress and the flow ID.
> 
> Right.  What I'm missing is the logic in the SPF algorithm that
> detemines what the forwarding entries should be.  Also, this increases
> the forwarding entry space necessary as a consequence of the
> complexity of the campus and the number of aliases...

Yes, but the complexity is there anyway. Either way there needs to be
one entry per egress/path pair, i.e., for multiple nexthops to an
egress, there need to be multiple entries anyway.

>>>>This doesn't depend on equal cost paths at every decision point in the
>>>>campus, at least AFAICT.
>>>>
>>>>
>>>>
>>>>>Possibly the ingress rbridge could compute a hash value that is then
>>>>>forwarded as part of the shim header & is then used as input along the
>>>>>way.  For instance, with MPLS, if the packet underneath the MPLS shim
>>>>>header is not IP, then some equipment can do a hash on the label stack
>>>>>for load-balancing (draft-ietf-mpls-ecmp-bcp-01.txt).
>>>>>
>>>>>Alia-
>>>>
>>>>The hard part is what the hash would depend on - IP address, transport
>>>>port, etc.?  We might consider that, though, if it's supported for MPLS.
>>>>Or we can have the rbridges peek at the headers beyond the shim; as you
>>>>note, it won't matter for conventional bridges inside the rbridge (which
>>>>wouldn't look even inside the shim) anyway.
>>>
>>>Well, what the hash depends on doesn't necessarily have to be
>>>specified.  I believe there's a BCP about this for IP forwarding; I
>>>believe that recommends using the IP src/dest and UDP/TCP ports (if
>>>available).  This is generally supported (at least to the IP src/dest
>>>level) for IP and for MPLS.
>>>
>>>I think that isolating the complexity of doing the hash to the ingress
>>>rbridge might be preferable.  It depends on the forwarding path & how
>>>much knowing the ethertype=rbridge & therefore being able to avoid
>>>this helps.
>>>
>>>Alia
>>
>>And the complexity of the routing algorithm that can separate the
>>aliases at rbridge forwarding tables inside the campus as well. It may
>>be cheaper to just have them peek and keep flows separate themselves.
> 
> I agree.  I think I'd prefer something based on the hashing; then the
> question is whether one needs independent hashing or whether there's
> an advantage to doing it at the ingress.  Doing it at the ingress
> could give a bit of control (maybe some flows don't care about
> re-ordering) and might limit the required logic to the non-campus
> facing ports.

It also makes some of the interior rbridge logic simpler; note that the
ingress/egress complexity is different than the interior rbridge
complexity already.

Joe

Date: Wed, 10 Aug 2005 15:20:38 -0700
From: Alia Atlas <[email-masked]>
To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Cc: Joe Touch <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1232

On 8/10/05, Spencer Dawkins <[email-masked]> wrote:
> Alia Atlas wrote:
> 
> >
> >
> >Well, what the hash depends on doesn't necessarily have to be
> >specified.  I believe there's a BCP about this for IP forwarding; I
> >believe that recommends using the IP src/dest and UDP/TCP ports (if
> >available).  This is generally supported (at least to the IP src/dest
> >level) for IP and for MPLS.
> >
> >I think that isolating the complexity of doing the hash to the ingress
> >rbridge might be preferable.  It depends on the forwarding path & how
> >much knowing the ethertype=rbridge & therefore being able to avoid
> >this helps.
> >
> >Alia
> >
> 
> I'm still catching up on RBRIDGE, but one point here is that it's a
> sender's decision which path gets used (based on using one path,
> selecting based on hashes, or phases of the moon), and the receiver has
> to be able to accept packets on any path - did I get this right?

Certainly the receiver has to be able to accept packets on any path. 
As to the sender determining the path, well, for some flexibility in
determining, yes.  The sender at least gets to determine the flow
(either explicitly by a hash or such or implicitly by including the
relevant packet).

Alia

Date: Wed, 10 Aug 2005 15:18:09 -0700
From: Alia Atlas <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4309

On 8/10/05, Joe Touch <[email-masked]> wrote:

> >>>I would be concerned about using alternate addresses; this implies
> >>>knowledge on the number of different equal-cost paths available at
> >>>each point in the campus.
> >>
> >>We can - and probably need to - assign different addresses for each
> >>interface on an egress. We could certainly assign different ones if
> >>desired, i.e., as aliases. When multiple equal-cost paths exist, the
> >>entries can be split out in the forwarding table. The ingress already
> >>needs to know which egress rbridge to pick; if there are aliases, it can
> >>select them on a per-flow basis.
> >
> > Why do we need to assign different addresses for each interface on an
> > egress??  Wouldn't the egress rbridge receive the frame, remove the
> > encapsulation, and then decide which local interface to forward the
> > frame on based upon the remaining frame?
> 
> I'm speaking of multiple interfaces on the campus-side of the egress, or
> aliases to the single interface on the campus-side. The addresses can
> then used for path differentiation in the routing algorithm.
> 
> > I'm confused by your suggestions for the per-path aliases; doesn't
> > that require the the midpoint rbridge know what path is intended for a
> > particular alias?
> 
> Yes - that would mean that different aliases would have different paths.
> That's one version of the solution that could work.

I guess I am picturing a relatively standard SPF algorithm.  All
aliases advertised by an rbridge would have the same destination
sink-tree.  As a midpoint rbridge, how would I decide which path to
use for which alias?  Do I randomly sprinkle the aliases among the
paths?
 
> > The midpoint rbridge will still receive a frame
> > and need to decide which of the multiple equal-cost paths it needs to
> > be sent upon.  Could you clarify with an example?
> 
> I'm expecting that it could have different forwarding entries for the
> different aliases for the egress. The net effect is to use the egress
> address as a both the egress and the flow ID.

Right.  What I'm missing is the logic in the SPF algorithm that
detemines what the forwarding entries should be.  Also, this increases
the forwarding entry space necessary as a consequence of the
complexity of the campus and the number of aliases...

> >>This doesn't depend on equal cost paths at every decision point in the
> >>campus, at least AFAICT.
> >>
> >>
> >>>Possibly the ingress rbridge could compute a hash value that is then
> >>>forwarded as part of the shim header & is then used as input along the
> >>>way.  For instance, with MPLS, if the packet underneath the MPLS shim
> >>>header is not IP, then some equipment can do a hash on the label stack
> >>>for load-balancing (draft-ietf-mpls-ecmp-bcp-01.txt).
> >>>
> >>>Alia-
> >>
> >>The hard part is what the hash would depend on - IP address, transport
> >>port, etc.?  We might consider that, though, if it's supported for MPLS.
> >>Or we can have the rbridges peek at the headers beyond the shim; as you
> >>note, it won't matter for conventional bridges inside the rbridge (which
> >>wouldn't look even inside the shim) anyway.
> >
> > Well, what the hash depends on doesn't necessarily have to be
> > specified.  I believe there's a BCP about this for IP forwarding; I
> > believe that recommends using the IP src/dest and UDP/TCP ports (if
> > available).  This is generally supported (at least to the IP src/dest
> > level) for IP and for MPLS.
> >
> > I think that isolating the complexity of doing the hash to the ingress
> > rbridge might be preferable.  It depends on the forwarding path & how
> > much knowing the ethertype=rbridge & therefore being able to avoid
> > this helps.
> >
> > Alia
> 
> And the complexity of the routing algorithm that can separate the
> aliases at rbridge forwarding tables inside the campus as well. It may
> be cheaper to just have them peek and keep flows separate themselves.

I agree.  I think I'd prefer something based on the hashing; then the
question is whether one needs independent hashing or whether there's
an advantage to doing it at the ingress.  Doing it at the ingress
could give a bit of control (maybe some flows don't care about
re-ordering) and might limit the required logic to the non-campus
facing ports.

Alia

Date: Wed, 10 Aug 2005 15:03:47 -0700
From: Joe Touch <[email-masked]>
To: [email-masked]
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1350

Spencer Dawkins wrote:
> Alia Atlas wrote:
> 
>>
>>
>> Well, what the hash depends on doesn't necessarily have to be
>> specified.  I believe there's a BCP about this for IP forwarding; I
>> believe that recommends using the IP src/dest and UDP/TCP ports (if
>> available).  This is generally supported (at least to the IP src/dest
>> level) for IP and for MPLS.
>>
>> I think that isolating the complexity of doing the hash to the ingress
>> rbridge might be preferable.  It depends on the forwarding path & how
>> much knowing the ethertype=rbridge & therefore being able to avoid
>> this helps.
>>
>> Alia
>>
> 
> I'm still catching up on RBRIDGE, but one point here is that it's a
> sender's decision which path gets used (based on using one path,
> selecting based on hashes, or phases of the moon), and the receiver has
> to be able to accept packets on any path - did I get this right?

IMO, yes.

The only refinement I'd make to your summary is your use of 'the sender':

	the sender = source switching node

i.e., not the E2E source

Joe

Date: Wed, 10 Aug 2005 16:48:33 -0500
From: Spencer Dawkins <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Cc: Joe Touch <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 853

Alia Atlas wrote:

>
>
>Well, what the hash depends on doesn't necessarily have to be
>specified.  I believe there's a BCP about this for IP forwarding; I
>believe that recommends using the IP src/dest and UDP/TCP ports (if
>available).  This is generally supported (at least to the IP src/dest
>level) for IP and for MPLS.
>
>I think that isolating the complexity of doing the hash to the ingress
>rbridge might be preferable.  It depends on the forwarding path & how
>much knowing the ethertype=rbridge & therefore being able to avoid
>this helps.
>
>Alia
>

I'm still catching up on RBRIDGE, but one point here is that it's a 
sender's decision which path gets used (based on using one path, 
selecting based on hashes, or phases of the moon), and the receiver has 
to be able to accept packets on any path - did I get this right?

Thanks,

Spencer

Date: Wed, 10 Aug 2005 14:20:29 -0700
From: Joe Touch <[email-masked]>
To: Alia Atlas <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5301

Alia Atlas wrote:
> On 8/10/05, Joe Touch <[email-masked]> wrote:
> 
>>Alia Atlas wrote:
>>
>>>On 8/10/05, Joe Touch <[email-masked]> wrote:
>>>
>>>
>>>>Alia Atlas <[email-masked]> wrote:
>>>>
>>>>
>>>>>Joe,
>>>>>
>>>>>What about peeking into the L3 header in order to do load-balancing?
>>>>>This is common for doing load-balancing for ECMP.  As I understand it,
>>>>>an rbridge can have several equal-cost paths to the egress rbridge
>>>>>indicated by the frame.  Presumably, the same concerns about
>>>>>re-ordering micro-flows apply here as for IP.
>>>>>
>>>>>Alia
>>>>
>>>>Agreed; we could use alternate addresses for a single egress, where each
>>>>used a different path, to achieve this. I.e., the 'peeking' would be at
>>>>the ingress only, at least that's my impression.
>>>>
>>>>We want to avoid peeking elsewhere if possible, especially because it
>>>>won't occur on conventional bridges inside the campus due to the
>>>>inclusion of the shim header. The rbridges inside are intended to have
>>>>enough information from just the shim header to operate, but may also
>>>>peek ahead, though.
>>>
>>>Would a convential bridge have multiple paths to select between?
>>
>>I would expect not, since it should be using the sole spanning tree.
> 
> 
> So then the question is confined to how does an rbridge do
> load-balancing.  It seems like there are two possibilities that we're
> discussing.  Either the mid-point rbridge needs to be able to peek
> past the shim header, the encapsulated MAC addresses, and find the IP
> header, determine if it is an IP header, and then compute some hash on
> that, or the ingress rbridge needs to do the same and somehow indicate
> its hash downstream.

Yes, those are the two alternatives IMO.

>>>I would be concerned about using alternate addresses; this implies
>>>knowledge on the number of different equal-cost paths available at
>>>each point in the campus.
>>
>>We can - and probably need to - assign different addresses for each
>>interface on an egress. We could certainly assign different ones if
>>desired, i.e., as aliases. When multiple equal-cost paths exist, the
>>entries can be split out in the forwarding table. The ingress already
>>needs to know which egress rbridge to pick; if there are aliases, it can
>>select them on a per-flow basis.
> 
> Why do we need to assign different addresses for each interface on an
> egress??  Wouldn't the egress rbridge receive the frame, remove the
> encapsulation, and then decide which local interface to forward the
> frame on based upon the remaining frame?

I'm speaking of multiple interfaces on the campus-side of the egress, or
aliases to the single interface on the campus-side. The addresses can
then used for path differentiation in the routing algorithm.

> I'm confused by your suggestions for the per-path aliases; doesn't
> that require the the midpoint rbridge know what path is intended for a
> particular alias?

Yes - that would mean that different aliases would have different paths.
That's one version of the solution that could work.

> The midpoint rbridge will still receive a frame
> and need to decide which of the multiple equal-cost paths it needs to
> be sent upon.  Could you clarify with an example?

I'm expecting that it could have different forwarding entries for the
different aliases for the egress. The net effect is to use the egress
address as a both the egress and the flow ID.

>>This doesn't depend on equal cost paths at every decision point in the
>>campus, at least AFAICT.
>>
>>
>>>Possibly the ingress rbridge could compute a hash value that is then
>>>forwarded as part of the shim header & is then used as input along the
>>>way.  For instance, with MPLS, if the packet underneath the MPLS shim
>>>header is not IP, then some equipment can do a hash on the label stack
>>>for load-balancing (draft-ietf-mpls-ecmp-bcp-01.txt).
>>>
>>>Alia-
>>
>>The hard part is what the hash would depend on - IP address, transport
>>port, etc.?  We might consider that, though, if it's supported for MPLS.
>>Or we can have the rbridges peek at the headers beyond the shim; as you
>>note, it won't matter for conventional bridges inside the rbridge (which
>>wouldn't look even inside the shim) anyway.
> 
> Well, what the hash depends on doesn't necessarily have to be
> specified.  I believe there's a BCP about this for IP forwarding; I
> believe that recommends using the IP src/dest and UDP/TCP ports (if
> available).  This is generally supported (at least to the IP src/dest
> level) for IP and for MPLS.
> 
> I think that isolating the complexity of doing the hash to the ingress
> rbridge might be preferable.  It depends on the forwarding path & how
> much knowing the ethertype=rbridge & therefore being able to avoid
> this helps.
> 
> Alia

And the complexity of the routing algorithm that can separate the
aliases at rbridge forwarding tables inside the campus as well. It may
be cheaper to just have them peek and keep flows separate themselves.

Joe

Date: Wed, 10 Aug 2005 14:09:18 -0700
From: Alia Atlas <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4133

On 8/10/05, Joe Touch <[email-masked]> wrote:
> Alia Atlas wrote:
> > On 8/10/05, Joe Touch <[email-masked]> wrote:
> >
> >>Alia Atlas <[email-masked]> wrote:
> >>
> >>>Joe,
> >>>
> >>>What about peeking into the L3 header in order to do load-balancing?
> >>>This is common for doing load-balancing for ECMP.  As I understand it,
> >>>an rbridge can have several equal-cost paths to the egress rbridge
> >>>indicated by the frame.  Presumably, the same concerns about
> >>>re-ordering micro-flows apply here as for IP.
> >>>
> >>>Alia
> >>
> >>Agreed; we could use alternate addresses for a single egress, where each
> >>used a different path, to achieve this. I.e., the 'peeking' would be at
> >>the ingress only, at least that's my impression.
> >>
> >>We want to avoid peeking elsewhere if possible, especially because it
> >>won't occur on conventional bridges inside the campus due to the
> >>inclusion of the shim header. The rbridges inside are intended to have
> >>enough information from just the shim header to operate, but may also
> >>peek ahead, though.
> >
> > Would a convential bridge have multiple paths to select between?
> 
> I would expect not, since it should be using the sole spanning tree.

So then the question is confined to how does an rbridge do
load-balancing.  It seems like there are two possibilities that we're
discussing.  Either the mid-point rbridge needs to be able to peek
past the shim header, the encapsulated MAC addresses, and find the IP
header, determine if it is an IP header, and then compute some hash on
that, or the ingress rbridge needs to do the same and somehow indicate
its hash downstream.
 
> > I would be concerned about using alternate addresses; this implies
> > knowledge on the number of different equal-cost paths available at
> > each point in the campus.
> 
> We can - and probably need to - assign different addresses for each
> interface on an egress. We could certainly assign different ones if
> desired, i.e., as aliases. When multiple equal-cost paths exist, the
> entries can be split out in the forwarding table. The ingress already
> needs to know which egress rbridge to pick; if there are aliases, it can
> select them on a per-flow basis.

Why do we need to assign different addresses for each interface on an
egress??  Wouldn't the egress rbridge receive the frame, remove the
encapsulation, and then decide which local interface to forward the
frame on based upon the remaining frame?

I'm confused by your suggestions for the per-path aliases; doesn't
that require the the midpoint rbridge know what path is intended for a
particular alias?   The midpoint rbridge will still receive a frame
and need to decide which of the multiple equal-cost paths it needs to
be sent upon.  Could you clarify with an example?

> This doesn't depend on equal cost paths at every decision point in the
> campus, at least AFAICT.
> 
> > Possibly the ingress rbridge could compute a hash value that is then
> > forwarded as part of the shim header & is then used as input along the
> > way.  For instance, with MPLS, if the packet underneath the MPLS shim
> > header is not IP, then some equipment can do a hash on the label stack
> > for load-balancing (draft-ietf-mpls-ecmp-bcp-01.txt).
> >
> > Alia-
> 
> The hard part is what the hash would depend on - IP address, transport
> port, etc.?  We might consider that, though, if it's supported for MPLS.
> Or we can have the rbridges peek at the headers beyond the shim; as you
> note, it won't matter for conventional bridges inside the rbridge (which
> wouldn't look even inside the shim) anyway.

Well, what the hash depends on doesn't necessarily have to be
specified.  I believe there's a BCP about this for IP forwarding; I
believe that recommends using the IP src/dest and UDP/TCP ports (if
available).  This is generally supported (at least to the IP src/dest
level) for IP and for MPLS.

I think that isolating the complexity of doing the hash to the ingress
rbridge might be preferable.  It depends on the forwarding path & how
much knowing the ethertype=rbridge & therefore being able to avoid
this helps.

Alia

Date: Wed, 10 Aug 2005 13:46:05 -0700
From: Joe Touch <[email-masked]>
To: Alia Atlas <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2763

Alia Atlas wrote:
> On 8/10/05, Joe Touch <[email-masked]> wrote:
> 
>>Alia Atlas <[email-masked]> wrote:
>>
>>>Joe,
>>>
>>>What about peeking into the L3 header in order to do load-balancing?
>>>This is common for doing load-balancing for ECMP.  As I understand it,
>>>an rbridge can have several equal-cost paths to the egress rbridge
>>>indicated by the frame.  Presumably, the same concerns about
>>>re-ordering micro-flows apply here as for IP.
>>>
>>>Alia
>>
>>Agreed; we could use alternate addresses for a single egress, where each
>>used a different path, to achieve this. I.e., the 'peeking' would be at
>>the ingress only, at least that's my impression.
>>
>>We want to avoid peeking elsewhere if possible, especially because it
>>won't occur on conventional bridges inside the campus due to the
>>inclusion of the shim header. The rbridges inside are intended to have
>>enough information from just the shim header to operate, but may also
>>peek ahead, though.
> 
> Would a convential bridge have multiple paths to select between?  

I would expect not, since it should be using the sole spanning tree.

> I would be concerned about using alternate addresses; this implies
> knowledge on the number of different equal-cost paths available at
> each point in the campus.

We can - and probably need to - assign different addresses for each
interface on an egress. We could certainly assign different ones if
desired, i.e., as aliases. When multiple equal-cost paths exist, the
entries can be split out in the forwarding table. The ingress already
needs to know which egress rbridge to pick; if there are aliases, it can
select them on a per-flow basis.

This doesn't depend on equal cost paths at every decision point in the
campus, at least AFAICT.

> Possibly the ingress rbridge could compute a hash value that is then
> forwarded as part of the shim header & is then used as input along the
> way.  For instance, with MPLS, if the packet underneath the MPLS shim
> header is not IP, then some equipment can do a hash on the label stack
> for load-balancing (draft-ietf-mpls-ecmp-bcp-01.txt).
> 
> Alia-

The hard part is what the hash would depend on - IP address, transport
port, etc.?  We might consider that, though, if it's supported for MPLS.
Or we can have the rbridges peek at the headers beyond the shim; as you
note, it won't matter for conventional bridges inside the rbridge (which
wouldn't look even inside the shim) anyway.

Joe

Date: Wed, 10 Aug 2005 11:20:20 -0700
From: Alia Atlas <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] load-balancing rbridges
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1531

On 8/10/05, Joe Touch <[email-masked]> wrote:
> Alia Atlas <[email-masked]> wrote:
> >
> > Joe,
> >
> > What about peeking into the L3 header in order to do load-balancing?
> > This is common for doing load-balancing for ECMP.  As I understand it,
> > an rbridge can have several equal-cost paths to the egress rbridge
> > indicated by the frame.  Presumably, the same concerns about
> > re-ordering micro-flows apply here as for IP.
> >
> > Alia
> 
> Agreed; we could use alternate addresses for a single egress, where each
> used a different path, to achieve this. I.e., the 'peeking' would be at
> the ingress only, at least that's my impression.
> 
> We want to avoid peeking elsewhere if possible, especially because it
> won't occur on conventional bridges inside the campus due to the
> inclusion of the shim header. The rbridges inside are intended to have
> enough information from just the shim header to operate, but may also
> peek ahead, though.

Would a convential bridge have multiple paths to select between?  
I would be concerned about using alternate addresses; this implies
knowledge on the number of different equal-cost paths available at
each point in the campus.

Possibly the ingress rbridge could compute a hash value that is then
forwarded as part of the shim header & is then used as input along the
way.  For instance, with MPLS, if the packet underneath the MPLS shim
header is not IP, then some equipment can do a hash on the label stack
for load-balancing (draft-ietf-mpls-ecmp-bcp-01.txt).

Alia

Date: Wed, 10 Aug 2005 11:04:54 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Auto-discard notification
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1186

Alia Atlas <[email-masked]> wrote:

> 
> Joe,
> 
> What about peeking into the L3 header in order to do load-balancing? 
> This is common for doing load-balancing for ECMP.  As I understand it,
> an rbridge can have several equal-cost paths to the egress rbridge
> indicated by the frame.  Presumably, the same concerns about
> re-ordering micro-flows apply here as for IP.
> 
> Alia

Agreed; we could use alternate addresses for a single egress, where each
used a different path, to achieve this. I.e., the 'peeking' would be at
the ingress only, at least that's my impression.

We want to avoid peeking elsewhere if possible, especially because it
won't occur on conventional bridges inside the campus due to the
inclusion of the shim header. The rbridges inside are intended to have
enough information from just the shim header to operate, but may also
peek ahead, though.

Joe

Date: Wed, 10 Aug 2005 06:19:17 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Doubts about Rbridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 12016

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

Vishwas,

Inside the rbridge, for traffic entering the rbridge via ingress/egress,
the only switching decisions being made are between rbridge ingress and
egress.

As a result, the only 'ethertype' that is relevant is the rbridge shim.

Inside the rbridge, there is no need for L2-style 'peeking' into L3
headers to do optimizations; that would be done at the ingress to direct
traffic to different egresses or multicast trees.

Joe

Vishwas Manral wrote:
> Hi Joe,
>=20
> I miss the point regarding the "Type" field not required. "EtherType" f=
ield in the Ethernet header is used to tell the type of packet above Ethe=
rnet.
>=20
> When traversing an rbridge we loose the information of the packet above=
, because we replace the etherType by the rbridge type. How will we know =
what is the etherType when a packet inner header (after the shim header) =
needs to be looked into (L3 switching needs to be done).=20
>=20
> Thanks,
> Vishwas
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On=
 Behalf Of Joe Touch
> Sent: Tuesday, August 09, 2005 9:54 PM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Doubts about Rbridge
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
>=20
>=20
> Vishwas Manral wrote:
>=20
>>Hi Radia,
>>
>>Would "Protocol VLAN's" work with rbridges? With the etherType
>>pointing to the Rbridge and not the protocol above I think it would not=
=2E\
>=20
>=20
> The different VLANs would need to be identified at the rbridge ingress,=

> and mapped to different rbridge egress IDs, which would then map to
> different forwarding tables accordingly.
>=20
> Inside the rbridge, the rbridge forwarding takes over. Keep in mind tha=
t
> looking inside an rbridge is (and should be) like looking inside a
> bridge. Bridges inside the campus would no longer see the protocol vlan=

> tags or any other vlan tags per se - they'd just see the rbridge tags,
> which is all they should see.
>=20
> Note that protocol vlans or other vlans can work inside the campus
> between other bridges, but aren't really participating in the rbridge
> internal forwarding structure.
>=20
>=20
>>Besides is there a reason to not have a "type" field in the shim header=
?
>=20
>=20
> The only reason to have it is because it's needed; the only reason to
> need it would be if rbridges would forward differently on their basis,
> or expect bridges inside the campus to to so. However, as per above, th=
e
> rbridge replaces the vlan/protocol ID structure with its own set of
> addresses which are sufficient for its forwarding.
>=20
> Joe
>=20
>=20
>>Thanks,
>>Vishwas
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On=
 Behalf Of Vishwas Manral
>>Sent: Tuesday, August 09, 2005 10:49 AM
>>To: Developing a hybrid router/bridge.
>>Subject: [rbridge] Doubts about Rbridge
>>
>>Hi Radia,
>>
>>(PS: I am changing the subject line)=20
>>The existing bridges (switches) already do IGMP snooping, to limit mult=
icast traffic. That scenario would break.
>>
>>A lot of existing layer-2 devices do firewall functionality. Firewall f=
unctionality in the silicon may not work with Rbridges coming in.
>>
>>Maybe I am missing the point altogether.
>>
>>Thanks,
>>Vishwas
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On=
 Behalf Of Radia Perlman
>>Sent: Monday, August 08, 2005 9:58 PM
>>To: Developing a hybrid router/bridge.
>>Subject: Re: [rbridge] How many spanning trees?
>>
>>Re: Vishwas's question about encapsulation hiding the true nature of=20
>>packets from possible intervening
>>bridges (since the subject line would be otherwise misleading).
>>
>>Are all these things written down someplace? I find it frustrating to=20
>>design around undocumented
>>proprietary behavior (such as NATs). But anyway...
>>
>>I'd think firewalling wouldn't be that much of a problem. We wouldn't=20
>>need a basic bridge in the core
>>to be doing firewall...that could/should be done by an RBridge. Except =

>>if there were a basic bridge between
>>the endnodes and the first RBridge, which is a natural place to
>>put a firewall---then the basic bridge would see packets exactly as=20
>>today and
>>be able to do the same firewalling with no problem.
>>
>>As for IGMP...it would be the RBridges doing the IGMP snooping. For a=20
>>basic bridge in the
>>core, it would indeed not recognize an IGMP packet, but that's the=20
>>behavior we want. It would
>>just think it was forwarding vanilla multicast...it would be the=20
>>RBridges deciding what IP multicast
>>packets should be forwarded across which links, and intervening bridges=
=20
>>should just forward.
>>
>>Can think of any other bridge idiosyncrasies we should think about?
>>
>>Thanks,
>>
>>Radia
>>
>>Vishwas Manral wrote:
>>
>>
>>
>>>Hi Radia,
>>>
>>>I had a few doubts about mixed environments where we want rbridge coex=
isting properly with normal bridges/ switches.
>>>
>>>The rbridge document aims to add a new shim header after the layer-2 h=
eader. The draft states that "A packet in transit must look to ordinary b=
ridges like an ordinary layer 2 packet." However switches (in the silicon=
 itself) these days are more intelligent and do deep packet processing (f=
or example for a basic firewall functionality/ IGMP snooping etc). As the=
 new ether Type would be unidentifiable, this would result in a wrong beh=
avior (example a basic filtering for wrong IP header length check would f=
ail here). However the rbridge protocol defined in such a case will not w=
ork properly.
>>>
>>>I know of existing switches which do both of the above. Do let me know=
 where I am missing the point?
>>>
>>>Thanks,
>>>Vishwas
>>>-----Original Message-----
>>>From: [email-masked] [mailto:[email-masked]] O=
n Behalf Of Radia Perlman
>>>Sent: Tuesday, June 28, 2005 10:14 PM
>>>To: Developing a hybrid router/bridge.
>>>Subject: Re: [rbridge] How many spanning trees?
>>>
>>>You are right that paths will not be the same from A to B as from B to=
 A=20
>>>with an A-rooted tree (towards B)
>>>vs a B-rooted tree (towards A), at least if we do a straightforward=20
>>>calculation of spanning trees. I think trying
>>>to accomplish symmetric routes might
>>>require source/destination pair route computation. So hopefully we won=
't=20
>>>require symmetric routes.
>>>
>>>Radia
>>>
>>>
>>>
>>>Guillermo Ib=E1=F1ez wrote:
>>>
>>>
>>>
>>>
>>>
>>>>Guillermo Ib=E1=F1ez wrote:
>>>>This is my feedback on the "how many spanning trees" issue.
>>>>
>>>>
>>>>Radia Perlman wrote:
>>>>
>>>>
>>>>
>>>> =20
>>>>
>>>>
>>>>
>>>>>It would be nice to get opinions on remaining issues, and I think ea=
ch
>>>>>issue should be in a different email thread, so I'm starting one.
>>>>>
>>>>>How many spanning
>>>>>trees should RBridges compute? Given the link state database, they c=
an=20
>>>>>calculate
>>>>>as many as we want without further protocol messages. The possibilit=
ies are:
>>>>>
>>>>>a) one spanning tree: This is simplest, obviously.=20
>>>>>
>>>>>=20
>>>>>
>>>>>   =20
>>>>>
>>>>
>>>>The poor performance in the core for multicast is an important argume=
nt=20
>>>>against it. Other possibilities should exist, at least as an option.
>>>>
>>>>
>>>>
>>>> =20
>>>>
>>>>
>>>>
>>>>>b) one per VLAN: How it would work:each RBridge announces, in its li=
nk state info, which VLANs that
>>>>>RBridge is attached to.  To calculate a spanning tree for VLAN A, th=
e=20
>>>>>RBridges=20
>>>>>(all of them...not just those attached to VLAN A) choose the RBridge=
,=20
>>>>>RA, that
>>>>>has the lowest ID, AND that is attached to VLAN A. A spanning tree i=
s=20
>>>>>calculated
>>>>>with RA as root. THat spanning tree is pruned so that only branches =
that=20
>>>>>reach
>>>>>other VLAN A links survive.
>>>>>
>>>>>Why bother: If only a few links are VLAN A, then this allows more=20
>>>>>optimal delivery
>>>>>of multicast/unknown frames within the VLAN A broadcast domain.
>>>>>
>>>>>
>>>>>=20
>>>>>
>>>>>   =20
>>>>>
>>>>
>>>>It seems that with this implementation  compatibility (interoperabili=
ty)=20
>>>>with bridges running Multiple Spanning Tree Protocol (MSTP) is=20
>>>>excluded.  If bridges running MSTP exist  in the campus network, they=
=20
>>>>must be confined in one or several MST regions with their specific=20
>>>>VLAN-to-spanning tree instance mappings and,  like happens with STP o=
r=20
>>>>RSTP, the trees will end at the region boundary with an rbridge. This=
=20
>>>>means that there could coexist "regions" running MSTP with their own =

>>>>VLANs and multiple spanning trees inside the region, these regions=20
>>>>inserted between rbridges that use another type (range or IDs) of VLA=
Ns.=20
>>>>My understanding is then that the only VLANs capable of traversing th=
e=20
>>>>campus end-to-end would be the VLANs handled by Rbridges, as the othe=
r=20
>>>>would be stopped by Rbridges if they are not known by them.=20
>>>>
>>>>c) one per RBridge
>>>>
>>>>
>>>>
>>>> =20
>>>>
>>>>
>>>>
>>>>>Why bother: for IP multicasts, if RBridges do IGMP snooping, then th=
is=20
>>>>>allows
>>>>>optimal delivery from source to the receivers of a particular multic=
ast.
>>>>>
>>>>>Another reason is that it minimizes out of order delivery of packets=
 in the
>>>>>case when S it talking to D, and initially D is unknown by the RBrid=
ges=20
>>>>>and packets
>>>>>have to be sent over a spanning tree rather than on the shortest pat=
h=20
>>>>>=20
>>>>>
>>>>>   =20
>>>>>
>>>>
>>>>>from S to D.
>>>>
>>>>
>>>> =20
>>>>
>>>>
>>>>
>>>>>=20
>>>>>
>>>>>   =20
>>>>>
>>>>
>>>>One tree per bridge is very efficient together with IGMP snooping,=20
>>>>assuming a core of rbridges. The plus point is that in this case the =

>>>>multiple trees can also perform routing of unicast traffic, if used=20
>>>>together with the MAC address learning mechanism. In other words:=20
>>>>assuming a core formed by rbridges,  using an spaning tree per rbridg=
e=20
>>>>may be enough to perform all the routing via minimum paths. This=20
>>>>requires that the  address learning mechanism works over the trees (t=
he=20
>>>>trees coincide in opposite directions A to B and B to A, a tricky iss=
ue=20
>>>>when path costs can be equal).  So it seems that there is some=20
>>>>overlapping or overkillling using multiple spanning trees for=20
>>>>broadcast/multicast and Dijkstra routing for unicast and simplificati=
ons=20
>>>>are  possible.
>>>>
>>>>
>>>>
>>>> =20
>>>>
>>>>
>>>>
>>>>>********
>>>>>I personally don't have strong opinions on this. If only a miniscule=
=20
>>>>>amount of
>>>>>the traffic is multicast/unknown, then one spanning tree seems good =

>>>>>enough. If
>>>>>there's high volume IP-derived multicast applications, then perhaps =
one per
>>>>>RBridge would be worth it.
>>>>>
>>>>>So I guess I'd be inclined to either just have one spanning tree, or=
 one per
>>>>>ingress RBridge.
>>>>>
>>>>>And if we did one per ingress RBridge, would it be worth computing a=
ll=20
>>>>>those trees
>>>>>in advance just in case, or only computing one when necessary?
>>>>>
>>>>>Radia
>>>>>
>>>>>   =20
>>>>>
>=20
>=20
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://www.postel.org/mailman/listinfo/rbridge

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

--------------enig8B9E9E617FE2B5BCD3F68661--

Content-class: urn:content-classes:message
Date: Tue, 9 Aug 2005 23:52:26 -0700
From: "Vishwas Manral" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] VLANs and type field
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2714

Hi Radia/ Joe,

I got the use of the "type" field. The original packet is still saved so
is the type field in the header.

Thanks,
Vishwas
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: Tuesday, August 09, 2005 11:09 PM
To: Developing a hybrid router/bridge.
Subject: [rbridge] VLANs and type field

Re: Vishwas's question about VLANs (I'm changing the subject line to be 
more explicit), and the "protocol type"
question later

If I understand your question...

 >>Vishwas Manral wrote:

>>Would "Protocol VLAN's" work with rbridges? With the etherType
pointing to the Rbridge >>and not the protocol above I think it would
not.

It is our intent that VLANs work with RBridges. The way it would work is

that the VLAN tag
would be in the inner header, and ignored by the intermediate RBridges 
while the packet is in
transit. So there would be a core infrastructure that can forward any 
packet from any VLAN, but
the links upon which endnodes reside would be configured (as they are 
today) with VLAN numbers.
The first RBridge, if it is configured to add a VLAN tag of "VLAN A" to 
a packet from port p, will
add the VLAN tag to the inner header (just like a bridge would do 
today), and then look up the
egress RBridge, put the ID of the egress RBridge in the shim header, and

then put on the encapsulation
header.

Intermediate bridges would not see this as a VLAN packet...just an 
ordinary packet delivered hop by hop to
each RBridge.

The final RBridge would remove the VLAN tag before sending it to the 
final endnode (just as a bridge would do
today).

If there were a bridge between the source endnode and the first RBridge,

and that bridge is configured to
insert a VLAN tag, then that bridge would do exactly as it does today, 
and the first RBridge would
not add a VLAN tag, but would still add the shim and encapsulation
header.

In this way packets can transit any intermediate RBridge-RBridge link 
regardless of which VLAN the inner
packet is marked with. And I think that is the behavior that is wanted.

The RBridges have to ensure that a VLAN A packet is not delivered to an 
endnode on a link marked as not
allowing VLAN A traffic, but it's OK to transit such a link provided 
that endnodes don't see the packet (which
they wouldn't if it has the encapsulation header.
*******************

As for the other question...

 >Vishwas Manral wrote:

>>Besides is there a reason to not have a "type" field in the shim
header?

Not sure why that would be needed. What would you want to use that for?
The
type of the original packet is preserved already (with the original
frame, inside
the shim header).

Radia

Content-class: urn:content-classes:message
Date: Tue, 9 Aug 2005 23:14:14 -0700
From: "Vishwas Manral" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Doubts about Rbridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 10119

Hi Joe,

I miss the point regarding the "Type" field not required. "EtherType" field in the Ethernet header is used to tell the type of packet above Ethernet.

When traversing an rbridge we loose the information of the packet above, because we replace the etherType by the rbridge type. How will we know what is the etherType when a packet inner header (after the shim header) needs to be looked into (L3 switching needs to be done). 

Thanks,
Vishwas
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joe Touch
Sent: Tuesday, August 09, 2005 9:54 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Doubts about Rbridge

Vishwas Manral wrote:
> Hi Radia,
> 
> Would "Protocol VLAN's" work with rbridges? With the etherType
> pointing to the Rbridge and not the protocol above I think it would not.\

The different VLANs would need to be identified at the rbridge ingress,
and mapped to different rbridge egress IDs, which would then map to
different forwarding tables accordingly.

Inside the rbridge, the rbridge forwarding takes over. Keep in mind that
looking inside an rbridge is (and should be) like looking inside a
bridge. Bridges inside the campus would no longer see the protocol vlan
tags or any other vlan tags per se - they'd just see the rbridge tags,
which is all they should see.

Note that protocol vlans or other vlans can work inside the campus
between other bridges, but aren't really participating in the rbridge
internal forwarding structure.

> Besides is there a reason to not have a "type" field in the shim header?

The only reason to have it is because it's needed; the only reason to
need it would be if rbridges would forward differently on their basis,
or expect bridges inside the campus to to so. However, as per above, the
rbridge replaces the vlan/protocol ID structure with its own set of
addresses which are sufficient for its forwarding.

Joe

> 
> Thanks,
> Vishwas
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Vishwas Manral
> Sent: Tuesday, August 09, 2005 10:49 AM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] Doubts about Rbridge
> 
> Hi Radia,
> 
> (PS: I am changing the subject line) 
> The existing bridges (switches) already do IGMP snooping, to limit multicast traffic. That scenario would break.
> 
> A lot of existing layer-2 devices do firewall functionality. Firewall functionality in the silicon may not work with Rbridges coming in.
> 
> Maybe I am missing the point altogether.
> 
> Thanks,
> Vishwas
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Monday, August 08, 2005 9:58 PM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] How many spanning trees?
> 
> Re: Vishwas's question about encapsulation hiding the true nature of 
> packets from possible intervening
> bridges (since the subject line would be otherwise misleading).
> 
> Are all these things written down someplace? I find it frustrating to 
> design around undocumented
> proprietary behavior (such as NATs). But anyway...
> 
> I'd think firewalling wouldn't be that much of a problem. We wouldn't 
> need a basic bridge in the core
> to be doing firewall...that could/should be done by an RBridge. Except 
> if there were a basic bridge between
> the endnodes and the first RBridge, which is a natural place to
> put a firewall---then the basic bridge would see packets exactly as 
> today and
> be able to do the same firewalling with no problem.
> 
> As for IGMP...it would be the RBridges doing the IGMP snooping. For a 
> basic bridge in the
> core, it would indeed not recognize an IGMP packet, but that's the 
> behavior we want. It would
> just think it was forwarding vanilla multicast...it would be the 
> RBridges deciding what IP multicast
> packets should be forwarded across which links, and intervening bridges 
> should just forward.
> 
> Can think of any other bridge idiosyncrasies we should think about?
> 
> Thanks,
> 
> Radia
> 
> Vishwas Manral wrote:
> 
> 
>>Hi Radia,
>>
>>I had a few doubts about mixed environments where we want rbridge coexisting properly with normal bridges/ switches.
>>
>>The rbridge document aims to add a new shim header after the layer-2 header. The draft states that "A packet in transit must look to ordinary bridges like an ordinary layer 2 packet." However switches (in the silicon itself) these days are more intelligent and do deep packet processing (for example for a basic firewall functionality/ IGMP snooping etc). As the new ether Type would be unidentifiable, this would result in a wrong behavior (example a basic filtering for wrong IP header length check would fail here). However the rbridge protocol defined in such a case will not work properly.
>>
>>I know of existing switches which do both of the above. Do let me know where I am missing the point?
>>
>>Thanks,
>>Vishwas
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On Behalf Of Radia Perlman
>>Sent: Tuesday, June 28, 2005 10:14 PM
>>To: Developing a hybrid router/bridge.
>>Subject: Re: [rbridge] How many spanning trees?
>>
>>You are right that paths will not be the same from A to B as from B to A 
>>with an A-rooted tree (towards B)
>>vs a B-rooted tree (towards A), at least if we do a straightforward 
>>calculation of spanning trees. I think trying
>>to accomplish symmetric routes might
>>require source/destination pair route computation. So hopefully we won't 
>>require symmetric routes.
>>
>>Radia
>>
>>
>>
>>Guillermo Ib??ez wrote:
>>
>> 
>>
>>
>>>Guillermo Ib??ez wrote:
>>>This is my feedback on the "how many spanning trees" issue.
>>>
>>>
>>>Radia Perlman wrote:
>>>
>>>
>>>
>>>   
>>>
>>>
>>>>It would be nice to get opinions on remaining issues, and I think each
>>>>issue should be in a different email thread, so I'm starting one.
>>>>
>>>>How many spanning
>>>>trees should RBridges compute? Given the link state database, they can 
>>>>calculate
>>>>as many as we want without further protocol messages. The possibilities are:
>>>>
>>>>a) one spanning tree: This is simplest, obviously. 
>>>>
>>>>  
>>>>
>>>>     
>>>>
>>>
>>>The poor performance in the core for multicast is an important argument 
>>>against it. Other possibilities should exist, at least as an option.
>>>
>>>
>>>
>>>   
>>>
>>>
>>>>b) one per VLAN: How it would work:each RBridge announces, in its link state info, which VLANs that
>>>>RBridge is attached to.  To calculate a spanning tree for VLAN A, the 
>>>>RBridges 
>>>>(all of them...not just those attached to VLAN A) choose the RBridge, 
>>>>RA, that
>>>>has the lowest ID, AND that is attached to VLAN A. A spanning tree is 
>>>>calculated
>>>>with RA as root. THat spanning tree is pruned so that only branches that 
>>>>reach
>>>>other VLAN A links survive.
>>>>
>>>>Why bother: If only a few links are VLAN A, then this allows more 
>>>>optimal delivery
>>>>of multicast/unknown frames within the VLAN A broadcast domain.
>>>>
>>>>
>>>>  
>>>>
>>>>     
>>>>
>>>
>>>It seems that with this implementation  compatibility (interoperability) 
>>>with bridges running Multiple Spanning Tree Protocol (MSTP) is 
>>>excluded.  If bridges running MSTP exist  in the campus network, they 
>>>must be confined in one or several MST regions with their specific 
>>>VLAN-to-spanning tree instance mappings and,  like happens with STP or 
>>>RSTP, the trees will end at the region boundary with an rbridge. This 
>>>means that there could coexist "regions" running MSTP with their own 
>>>VLANs and multiple spanning trees inside the region, these regions 
>>>inserted between rbridges that use another type (range or IDs) of VLANs. 
>>>My understanding is then that the only VLANs capable of traversing the 
>>>campus end-to-end would be the VLANs handled by Rbridges, as the other 
>>>would be stopped by Rbridges if they are not known by them. 
>>>
>>>c) one per RBridge
>>>
>>>
>>>
>>>   
>>>
>>>
>>>>Why bother: for IP multicasts, if RBridges do IGMP snooping, then this 
>>>>allows
>>>>optimal delivery from source to the receivers of a particular multicast.
>>>>
>>>>Another reason is that it minimizes out of order delivery of packets in the
>>>>case when S it talking to D, and initially D is unknown by the RBridges 
>>>>and packets
>>>>have to be sent over a spanning tree rather than on the shortest path 
>>>>  
>>>>
>>>>     
>>>>
>>>
>>>>from S to D.
>>>
>>>
>>>   
>>>
>>>
>>>>  
>>>>
>>>>     
>>>>
>>>
>>>One tree per bridge is very efficient together with IGMP snooping, 
>>>assuming a core of rbridges. The plus point is that in this case the 
>>>multiple trees can also perform routing of unicast traffic, if used 
>>>together with the MAC address learning mechanism. In other words: 
>>>assuming a core formed by rbridges,  using an spaning tree per rbridge 
>>>may be enough to perform all the routing via minimum paths. This 
>>>requires that the  address learning mechanism works over the trees (the 
>>>trees coincide in opposite directions A to B and B to A, a tricky issue 
>>>when path costs can be equal).  So it seems that there is some 
>>>overlapping or overkillling using multiple spanning trees for 
>>>broadcast/multicast and Dijkstra routing for unicast and simplifications 
>>>are  possible.
>>>
>>>
>>>
>>>   
>>>
>>>
>>>>********
>>>>I personally don't have strong opinions on this. If only a miniscule 
>>>>amount of
>>>>the traffic is multicast/unknown, then one spanning tree seems good 
>>>>enough. If
>>>>there's high volume IP-derived multicast applications, then perhaps one per
>>>>RBridge would be worth it.
>>>>
>>>>So I guess I'd be inclined to either just have one spanning tree, or one per
>>>>ingress RBridge.
>>>>
>>>>And if we did one per ingress RBridge, would it be worth computing all 
>>>>those trees
>>>>in advance just in case, or only computing one when necessary?
>>>>
>>>>Radia
>>>>
>>>>     
>>>>

Content-class: urn:content-classes:message
Date: Tue, 9 Aug 2005 13:40:58 -0700
From: "Ghanwani, Anoop" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] VLANs and type field
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 285

> Intermediate bridges would not see this as a VLAN packet...just an 
> ordinary packet delivered hop by hop to
> each RBridge.

Just to clarify, does this mean that all Q-bridges interconnecting
rbridges would essentially be in the same VLAN (i.e. a single
broadcast domain)?

Anoop

Date: Tue, 09 Aug 2005 10:39:09 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] VLANs and type field
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2334

Re: Vishwas's question about VLANs (I'm changing the subject line to be 
more explicit), and the "protocol type"
question later

If I understand your question...

 >>Vishwas Manral wrote:

>>Would "Protocol VLAN's" work with rbridges? With the etherType pointing to the Rbridge >>and not the protocol above I think it would not.

It is our intent that VLANs work with RBridges. The way it would work is 
that the VLAN tag
would be in the inner header, and ignored by the intermediate RBridges 
while the packet is in
transit. So there would be a core infrastructure that can forward any 
packet from any VLAN, but
the links upon which endnodes reside would be configured (as they are 
today) with VLAN numbers.
The first RBridge, if it is configured to add a VLAN tag of "VLAN A" to 
a packet from port p, will
add the VLAN tag to the inner header (just like a bridge would do 
today), and then look up the
egress RBridge, put the ID of the egress RBridge in the shim header, and 
then put on the encapsulation
header.

Intermediate bridges would not see this as a VLAN packet...just an 
ordinary packet delivered hop by hop to
each RBridge.

The final RBridge would remove the VLAN tag before sending it to the 
final endnode (just as a bridge would do
today).

If there were a bridge between the source endnode and the first RBridge, 
and that bridge is configured to
insert a VLAN tag, then that bridge would do exactly as it does today, 
and the first RBridge would
not add a VLAN tag, but would still add the shim and encapsulation header.

In this way packets can transit any intermediate RBridge-RBridge link 
regardless of which VLAN the inner
packet is marked with. And I think that is the behavior that is wanted.

The RBridges have to ensure that a VLAN A packet is not delivered to an 
endnode on a link marked as not
allowing VLAN A traffic, but it's OK to transit such a link provided 
that endnodes don't see the packet (which
they wouldn't if it has the encapsulation header.
*******************

As for the other question...

 >Vishwas Manral wrote:

>>Besides is there a reason to not have a "type" field in the shim header?

Not sure why that would be needed. What would you want to use that for? The
type of the original packet is preserved already (with the original frame, inside
the shim header).

Radia

Date: Tue, 09 Aug 2005 09:30:16 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Doubts about Rbridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 8996

Vishwas Manral wrote:
> Hi Radia,
> 
> (PS: I am changing the subject line) 
> The existing bridges (switches) already do IGMP snooping, to limit multicast traffic. That scenario would break.

The inside of the rbridge would limit multicast in other ways, e.g.,
using different trees for each mcast group and limiting tree
participation at the ingress/egress nodes. Inside the rbridge, however,
there would be no IGMP header to examine anymore, because it's not
necessary.

> A lot of existing layer-2 devices do firewall functionality. Firewall functionality in the silicon may not work with Rbridges coming in.

Definitely. Anyone putting a firewall inside an rbridge campus would
have problems - but that seems correct.

> Maybe I am missing the point altogether.

Two concepts may help:

	1) IMO, an rbridge campus should act like a single bridge device
	to the outside world

	2) an rbridge campus should be more efficient than replacing it
	with a set of conventional bridges

Most of your questions are answered, IMO, by considering #1 rather than #2.

Joe

> 
> Thanks,
> Vishwas
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Monday, August 08, 2005 9:58 PM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] How many spanning trees?
> 
> Re: Vishwas's question about encapsulation hiding the true nature of 
> packets from possible intervening
> bridges (since the subject line would be otherwise misleading).
> 
> Are all these things written down someplace? I find it frustrating to 
> design around undocumented
> proprietary behavior (such as NATs). But anyway...
> 
> I'd think firewalling wouldn't be that much of a problem. We wouldn't 
> need a basic bridge in the core
> to be doing firewall...that could/should be done by an RBridge. Except 
> if there were a basic bridge between
> the endnodes and the first RBridge, which is a natural place to
> put a firewall---then the basic bridge would see packets exactly as 
> today and
> be able to do the same firewalling with no problem.
> 
> As for IGMP...it would be the RBridges doing the IGMP snooping. For a 
> basic bridge in the
> core, it would indeed not recognize an IGMP packet, but that's the 
> behavior we want. It would
> just think it was forwarding vanilla multicast...it would be the 
> RBridges deciding what IP multicast
> packets should be forwarded across which links, and intervening bridges 
> should just forward.
> 
> Can think of any other bridge idiosyncrasies we should think about?
> 
> Thanks,
> 
> Radia
> 
> Vishwas Manral wrote:
> 
> 
>>Hi Radia,
>>
>>I had a few doubts about mixed environments where we want rbridge coexisting properly with normal bridges/ switches.
>>
>>The rbridge document aims to add a new shim header after the layer-2 header. The draft states that "A packet in transit must look to ordinary bridges like an ordinary layer 2 packet." However switches (in the silicon itself) these days are more intelligent and do deep packet processing (for example for a basic firewall functionality/ IGMP snooping etc). As the new ether Type would be unidentifiable, this would result in a wrong behavior (example a basic filtering for wrong IP header length check would fail here). However the rbridge protocol defined in such a case will not work properly.
>>
>>I know of existing switches which do both of the above. Do let me know where I am missing the point?
>>
>>Thanks,
>>Vishwas
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On Behalf Of Radia Perlman
>>Sent: Tuesday, June 28, 2005 10:14 PM
>>To: Developing a hybrid router/bridge.
>>Subject: Re: [rbridge] How many spanning trees?
>>
>>You are right that paths will not be the same from A to B as from B to A 
>>with an A-rooted tree (towards B)
>>vs a B-rooted tree (towards A), at least if we do a straightforward 
>>calculation of spanning trees. I think trying
>>to accomplish symmetric routes might
>>require source/destination pair route computation. So hopefully we won't 
>>require symmetric routes.
>>
>>Radia
>>
>>
>>
>>Guillermo Ib??ez wrote:
>>
>> 
>>
>>
>>>Guillermo Ib??ez wrote:
>>>This is my feedback on the "how many spanning trees" issue.
>>>
>>>
>>>Radia Perlman wrote:
>>>
>>>
>>>
>>>   
>>>
>>>
>>>>It would be nice to get opinions on remaining issues, and I think each
>>>>issue should be in a different email thread, so I'm starting one.
>>>>
>>>>How many spanning
>>>>trees should RBridges compute? Given the link state database, they can 
>>>>calculate
>>>>as many as we want without further protocol messages. The possibilities are:
>>>>
>>>>a) one spanning tree: This is simplest, obviously. 
>>>>
>>>>  
>>>>
>>>>     
>>>>
>>>
>>>The poor performance in the core for multicast is an important argument 
>>>against it. Other possibilities should exist, at least as an option.
>>>
>>>
>>>
>>>   
>>>
>>>
>>>>b) one per VLAN: How it would work:each RBridge announces, in its link state info, which VLANs that
>>>>RBridge is attached to.  To calculate a spanning tree for VLAN A, the 
>>>>RBridges 
>>>>(all of them...not just those attached to VLAN A) choose the RBridge, 
>>>>RA, that
>>>>has the lowest ID, AND that is attached to VLAN A. A spanning tree is 
>>>>calculated
>>>>with RA as root. THat spanning tree is pruned so that only branches that 
>>>>reach
>>>>other VLAN A links survive.
>>>>
>>>>Why bother: If only a few links are VLAN A, then this allows more 
>>>>optimal delivery
>>>>of multicast/unknown frames within the VLAN A broadcast domain.
>>>>
>>>>
>>>>  
>>>>
>>>>     
>>>>
>>>
>>>It seems that with this implementation  compatibility (interoperability) 
>>>with bridges running Multiple Spanning Tree Protocol (MSTP) is 
>>>excluded.  If bridges running MSTP exist  in the campus network, they 
>>>must be confined in one or several MST regions with their specific 
>>>VLAN-to-spanning tree instance mappings and,  like happens with STP or 
>>>RSTP, the trees will end at the region boundary with an rbridge. This 
>>>means that there could coexist "regions" running MSTP with their own 
>>>VLANs and multiple spanning trees inside the region, these regions 
>>>inserted between rbridges that use another type (range or IDs) of VLANs. 
>>>My understanding is then that the only VLANs capable of traversing the 
>>>campus end-to-end would be the VLANs handled by Rbridges, as the other 
>>>would be stopped by Rbridges if they are not known by them. 
>>>
>>>c) one per RBridge
>>>
>>>
>>>
>>>   
>>>
>>>
>>>>Why bother: for IP multicasts, if RBridges do IGMP snooping, then this 
>>>>allows
>>>>optimal delivery from source to the receivers of a particular multicast.
>>>>
>>>>Another reason is that it minimizes out of order delivery of packets in the
>>>>case when S it talking to D, and initially D is unknown by the RBridges 
>>>>and packets
>>>>have to be sent over a spanning tree rather than on the shortest path 
>>>>  
>>>>
>>>>     
>>>>
>>>
>>>>from S to D.
>>>
>>>
>>>   
>>>
>>>
>>>>  
>>>>
>>>>     
>>>>
>>>
>>>One tree per bridge is very efficient together with IGMP snooping, 
>>>assuming a core of rbridges. The plus point is that in this case the 
>>>multiple trees can also perform routing of unicast traffic, if used 
>>>together with the MAC address learning mechanism. In other words: 
>>>assuming a core formed by rbridges,  using an spaning tree per rbridge 
>>>may be enough to perform all the routing via minimum paths. This 
>>>requires that the  address learning mechanism works over the trees (the 
>>>trees coincide in opposite directions A to B and B to A, a tricky issue 
>>>when path costs can be equal).  So it seems that there is some 
>>>overlapping or overkillling using multiple spanning trees for 
>>>broadcast/multicast and Dijkstra routing for unicast and simplifications 
>>>are  possible.
>>>
>>>
>>>
>>>   
>>>
>>>
>>>>********
>>>>I personally don't have strong opinions on this. If only a miniscule 
>>>>amount of
>>>>the traffic is multicast/unknown, then one spanning tree seems good 
>>>>enough. If
>>>>there's high volume IP-derived multicast applications, then perhaps one per
>>>>RBridge would be worth it.
>>>>
>>>>So I guess I'd be inclined to either just have one spanning tree, or one per
>>>>ingress RBridge.
>>>>
>>>>And if we did one per ingress RBridge, would it be worth computing all 
>>>>those trees
>>>>in advance just in case, or only computing one when necessary?
>>>>
>>>>Radia
>>>>
>>>>     
>>>>
> 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://www.postel.org/mailman/listinfo/rbridge

Date: Tue, 09 Aug 2005 09:23:40 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Doubts about Rbridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 9976

Vishwas Manral wrote:
> Hi Radia,
> 
> Would "Protocol VLAN's" work with rbridges? With the etherType
> pointing to the Rbridge and not the protocol above I think it would not.\

The different VLANs would need to be identified at the rbridge ingress,
and mapped to different rbridge egress IDs, which would then map to
different forwarding tables accordingly.

Inside the rbridge, the rbridge forwarding takes over. Keep in mind that
looking inside an rbridge is (and should be) like looking inside a
bridge. Bridges inside the campus would no longer see the protocol vlan
tags or any other vlan tags per se - they'd just see the rbridge tags,
which is all they should see.

Note that protocol vlans or other vlans can work inside the campus
between other bridges, but aren't really participating in the rbridge
internal forwarding structure.

> Besides is there a reason to not have a "type" field in the shim header?

The only reason to have it is because it's needed; the only reason to
need it would be if rbridges would forward differently on their basis,
or expect bridges inside the campus to to so. However, as per above, the
rbridge replaces the vlan/protocol ID structure with its own set of
addresses which are sufficient for its forwarding.

Joe

> 
> Thanks,
> Vishwas
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Vishwas Manral
> Sent: Tuesday, August 09, 2005 10:49 AM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] Doubts about Rbridge
> 
> Hi Radia,
> 
> (PS: I am changing the subject line) 
> The existing bridges (switches) already do IGMP snooping, to limit multicast traffic. That scenario would break.
> 
> A lot of existing layer-2 devices do firewall functionality. Firewall functionality in the silicon may not work with Rbridges coming in.
> 
> Maybe I am missing the point altogether.
> 
> Thanks,
> Vishwas
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Monday, August 08, 2005 9:58 PM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] How many spanning trees?
> 
> Re: Vishwas's question about encapsulation hiding the true nature of 
> packets from possible intervening
> bridges (since the subject line would be otherwise misleading).
> 
> Are all these things written down someplace? I find it frustrating to 
> design around undocumented
> proprietary behavior (such as NATs). But anyway...
> 
> I'd think firewalling wouldn't be that much of a problem. We wouldn't 
> need a basic bridge in the core
> to be doing firewall...that could/should be done by an RBridge. Except 
> if there were a basic bridge between
> the endnodes and the first RBridge, which is a natural place to
> put a firewall---then the basic bridge would see packets exactly as 
> today and
> be able to do the same firewalling with no problem.
> 
> As for IGMP...it would be the RBridges doing the IGMP snooping. For a 
> basic bridge in the
> core, it would indeed not recognize an IGMP packet, but that's the 
> behavior we want. It would
> just think it was forwarding vanilla multicast...it would be the 
> RBridges deciding what IP multicast
> packets should be forwarded across which links, and intervening bridges 
> should just forward.
> 
> Can think of any other bridge idiosyncrasies we should think about?
> 
> Thanks,
> 
> Radia
> 
> Vishwas Manral wrote:
> 
> 
>>Hi Radia,
>>
>>I had a few doubts about mixed environments where we want rbridge coexisting properly with normal bridges/ switches.
>>
>>The rbridge document aims to add a new shim header after the layer-2 header. The draft states that "A packet in transit must look to ordinary bridges like an ordinary layer 2 packet." However switches (in the silicon itself) these days are more intelligent and do deep packet processing (for example for a basic firewall functionality/ IGMP snooping etc). As the new ether Type would be unidentifiable, this would result in a wrong behavior (example a basic filtering for wrong IP header length check would fail here). However the rbridge protocol defined in such a case will not work properly.
>>
>>I know of existing switches which do both of the above. Do let me know where I am missing the point?
>>
>>Thanks,
>>Vishwas
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On Behalf Of Radia Perlman
>>Sent: Tuesday, June 28, 2005 10:14 PM
>>To: Developing a hybrid router/bridge.
>>Subject: Re: [rbridge] How many spanning trees?
>>
>>You are right that paths will not be the same from A to B as from B to A 
>>with an A-rooted tree (towards B)
>>vs a B-rooted tree (towards A), at least if we do a straightforward 
>>calculation of spanning trees. I think trying
>>to accomplish symmetric routes might
>>require source/destination pair route computation. So hopefully we won't 
>>require symmetric routes.
>>
>>Radia
>>
>>
>>
>>Guillermo Ib??ez wrote:
>>
>> 
>>
>>
>>>Guillermo Ib??ez wrote:
>>>This is my feedback on the "how many spanning trees" issue.
>>>
>>>
>>>Radia Perlman wrote:
>>>
>>>
>>>
>>>   
>>>
>>>
>>>>It would be nice to get opinions on remaining issues, and I think each
>>>>issue should be in a different email thread, so I'm starting one.
>>>>
>>>>How many spanning
>>>>trees should RBridges compute? Given the link state database, they can 
>>>>calculate
>>>>as many as we want without further protocol messages. The possibilities are:
>>>>
>>>>a) one spanning tree: This is simplest, obviously. 
>>>>
>>>>  
>>>>
>>>>     
>>>>
>>>
>>>The poor performance in the core for multicast is an important argument 
>>>against it. Other possibilities should exist, at least as an option.
>>>
>>>
>>>
>>>   
>>>
>>>
>>>>b) one per VLAN: How it would work:each RBridge announces, in its link state info, which VLANs that
>>>>RBridge is attached to.  To calculate a spanning tree for VLAN A, the 
>>>>RBridges 
>>>>(all of them...not just those attached to VLAN A) choose the RBridge, 
>>>>RA, that
>>>>has the lowest ID, AND that is attached to VLAN A. A spanning tree is 
>>>>calculated
>>>>with RA as root. THat spanning tree is pruned so that only branches that 
>>>>reach
>>>>other VLAN A links survive.
>>>>
>>>>Why bother: If only a few links are VLAN A, then this allows more 
>>>>optimal delivery
>>>>of multicast/unknown frames within the VLAN A broadcast domain.
>>>>
>>>>
>>>>  
>>>>
>>>>     
>>>>
>>>
>>>It seems that with this implementation  compatibility (interoperability) 
>>>with bridges running Multiple Spanning Tree Protocol (MSTP) is 
>>>excluded.  If bridges running MSTP exist  in the campus network, they 
>>>must be confined in one or several MST regions with their specific 
>>>VLAN-to-spanning tree instance mappings and,  like happens with STP or 
>>>RSTP, the trees will end at the region boundary with an rbridge. This 
>>>means that there could coexist "regions" running MSTP with their own 
>>>VLANs and multiple spanning trees inside the region, these regions 
>>>inserted between rbridges that use another type (range or IDs) of VLANs. 
>>>My understanding is then that the only VLANs capable of traversing the 
>>>campus end-to-end would be the VLANs handled by Rbridges, as the other 
>>>would be stopped by Rbridges if they are not known by them. 
>>>
>>>c) one per RBridge
>>>
>>>
>>>
>>>   
>>>
>>>
>>>>Why bother: for IP multicasts, if RBridges do IGMP snooping, then this 
>>>>allows
>>>>optimal delivery from source to the receivers of a particular multicast.
>>>>
>>>>Another reason is that it minimizes out of order delivery of packets in the
>>>>case when S it talking to D, and initially D is unknown by the RBridges 
>>>>and packets
>>>>have to be sent over a spanning tree rather than on the shortest path 
>>>>  
>>>>
>>>>     
>>>>
>>>
>>>>from S to D.
>>>
>>>
>>>   
>>>
>>>
>>>>  
>>>>
>>>>     
>>>>
>>>
>>>One tree per bridge is very efficient together with IGMP snooping, 
>>>assuming a core of rbridges. The plus point is that in this case the 
>>>multiple trees can also perform routing of unicast traffic, if used 
>>>together with the MAC address learning mechanism. In other words: 
>>>assuming a core formed by rbridges,  using an spaning tree per rbridge 
>>>may be enough to perform all the routing via minimum paths. This 
>>>requires that the  address learning mechanism works over the trees (the 
>>>trees coincide in opposite directions A to B and B to A, a tricky issue 
>>>when path costs can be equal).  So it seems that there is some 
>>>overlapping or overkillling using multiple spanning trees for 
>>>broadcast/multicast and Dijkstra routing for unicast and simplifications 
>>>are  possible.
>>>
>>>
>>>
>>>   
>>>
>>>
>>>>********
>>>>I personally don't have strong opinions on this. If only a miniscule 
>>>>amount of
>>>>the traffic is multicast/unknown, then one spanning tree seems good 
>>>>enough. If
>>>>there's high volume IP-derived multicast applications, then perhaps one per
>>>>RBridge would be worth it.
>>>>
>>>>So I guess I'd be inclined to either just have one spanning tree, or one per
>>>>ingress RBridge.
>>>>
>>>>And if we did one per ingress RBridge, would it be worth computing all 
>>>>those trees
>>>>in advance just in case, or only computing one when necessary?
>>>>
>>>>Radia
>>>>
>>>>     
>>>>
> 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://www.postel.org/mailman/listinfo/rbridge
> 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://www.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Tue, 9 Aug 2005 04:22:46 -0700
From: "Vishwas Manral" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Doubts about Rbridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 8174

Hi Radia,

Would "Protocol VLAN's" work with rbridges? With the etherType pointing to the Rbridge and not the protocol above I think it would not.

Besides is there a reason to not have a "type" field in the shim header?

Thanks,
Vishwas
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Vishwas Manral
Sent: Tuesday, August 09, 2005 10:49 AM
To: Developing a hybrid router/bridge.
Subject: [rbridge] Doubts about Rbridge

Hi Radia,

(PS: I am changing the subject line) 
The existing bridges (switches) already do IGMP snooping, to limit multicast traffic. That scenario would break.

A lot of existing layer-2 devices do firewall functionality. Firewall functionality in the silicon may not work with Rbridges coming in.

Maybe I am missing the point altogether.

Thanks,
Vishwas
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Radia Perlman
Sent: Monday, August 08, 2005 9:58 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] How many spanning trees?

Re: Vishwas's question about encapsulation hiding the true nature of 
packets from possible intervening
bridges (since the subject line would be otherwise misleading).

Are all these things written down someplace? I find it frustrating to 
design around undocumented
proprietary behavior (such as NATs). But anyway...

I'd think firewalling wouldn't be that much of a problem. We wouldn't 
need a basic bridge in the core
to be doing firewall...that could/should be done by an RBridge. Except 
if there were a basic bridge between
the endnodes and the first RBridge, which is a natural place to
put a firewall---then the basic bridge would see packets exactly as 
today and
be able to do the same firewalling with no problem.

As for IGMP...it would be the RBridges doing the IGMP snooping. For a 
basic bridge in the
core, it would indeed not recognize an IGMP packet, but that's the 
behavior we want. It would
just think it was forwarding vanilla multicast...it would be the 
RBridges deciding what IP multicast
packets should be forwarded across which links, and intervening bridges 
should just forward.

Can think of any other bridge idiosyncrasies we should think about?

Thanks,

Radia

Vishwas Manral wrote:

>Hi Radia,
>
>I had a few doubts about mixed environments where we want rbridge coexisting properly with normal bridges/ switches.
>
>The rbridge document aims to add a new shim header after the layer-2 header. The draft states that "A packet in transit must look to ordinary bridges like an ordinary layer 2 packet." However switches (in the silicon itself) these days are more intelligent and do deep packet processing (for example for a basic firewall functionality/ IGMP snooping etc). As the new ether Type would be unidentifiable, this would result in a wrong behavior (example a basic filtering for wrong IP header length check would fail here). However the rbridge protocol defined in such a case will not work properly.
>
>I know of existing switches which do both of the above. Do let me know where I am missing the point?
>
>Thanks,
>Vishwas
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Radia Perlman
>Sent: Tuesday, June 28, 2005 10:14 PM
>To: Developing a hybrid router/bridge.
>Subject: Re: [rbridge] How many spanning trees?
>
>You are right that paths will not be the same from A to B as from B to A 
>with an A-rooted tree (towards B)
>vs a B-rooted tree (towards A), at least if we do a straightforward 
>calculation of spanning trees. I think trying
>to accomplish symmetric routes might
>require source/destination pair route computation. So hopefully we won't 
>require symmetric routes.
>
>Radia
>
>
>
>Guillermo Ib??ez wrote:
>
>  
>
>>Guillermo Ib??ez wrote:
>>This is my feedback on the "how many spanning trees" issue.
>>
>>
>>Radia Perlman wrote:
>>
>> 
>>
>>    
>>
>>>It would be nice to get opinions on remaining issues, and I think each
>>>issue should be in a different email thread, so I'm starting one.
>>>
>>>How many spanning
>>>trees should RBridges compute? Given the link state database, they can 
>>>calculate
>>>as many as we want without further protocol messages. The possibilities are:
>>>
>>>a) one spanning tree: This is simplest, obviously. 
>>>
>>>   
>>>
>>>      
>>>
>>The poor performance in the core for multicast is an important argument 
>>against it. Other possibilities should exist, at least as an option.
>>
>> 
>>
>>    
>>
>>>b) one per VLAN: How it would work:each RBridge announces, in its link state info, which VLANs that
>>>RBridge is attached to.  To calculate a spanning tree for VLAN A, the 
>>>RBridges 
>>>(all of them...not just those attached to VLAN A) choose the RBridge, 
>>>RA, that
>>>has the lowest ID, AND that is attached to VLAN A. A spanning tree is 
>>>calculated
>>>with RA as root. THat spanning tree is pruned so that only branches that 
>>>reach
>>>other VLAN A links survive.
>>>
>>>Why bother: If only a few links are VLAN A, then this allows more 
>>>optimal delivery
>>>of multicast/unknown frames within the VLAN A broadcast domain.
>>>
>>>
>>>   
>>>
>>>      
>>>
>>It seems that with this implementation  compatibility (interoperability) 
>>with bridges running Multiple Spanning Tree Protocol (MSTP) is 
>>excluded.  If bridges running MSTP exist  in the campus network, they 
>>must be confined in one or several MST regions with their specific 
>>VLAN-to-spanning tree instance mappings and,  like happens with STP or 
>>RSTP, the trees will end at the region boundary with an rbridge. This 
>>means that there could coexist "regions" running MSTP with their own 
>>VLANs and multiple spanning trees inside the region, these regions 
>>inserted between rbridges that use another type (range or IDs) of VLANs. 
>>My understanding is then that the only VLANs capable of traversing the 
>>campus end-to-end would be the VLANs handled by Rbridges, as the other 
>>would be stopped by Rbridges if they are not known by them. 
>>
>>c) one per RBridge
>>
>> 
>>
>>    
>>
>>>Why bother: for IP multicasts, if RBridges do IGMP snooping, then this 
>>>allows
>>>optimal delivery from source to the receivers of a particular multicast.
>>>
>>>Another reason is that it minimizes out of order delivery of packets in the
>>>case when S it talking to D, and initially D is unknown by the RBridges 
>>>and packets
>>>have to be sent over a spanning tree rather than on the shortest path 
>>>   
>>>
>>>      
>>>
>>>from S to D.
>> 
>>
>>    
>>
>>>   
>>>
>>>      
>>>
>>One tree per bridge is very efficient together with IGMP snooping, 
>>assuming a core of rbridges. The plus point is that in this case the 
>>multiple trees can also perform routing of unicast traffic, if used 
>>together with the MAC address learning mechanism. In other words: 
>>assuming a core formed by rbridges,  using an spaning tree per rbridge 
>>may be enough to perform all the routing via minimum paths. This 
>>requires that the  address learning mechanism works over the trees (the 
>>trees coincide in opposite directions A to B and B to A, a tricky issue 
>>when path costs can be equal).  So it seems that there is some 
>>overlapping or overkillling using multiple spanning trees for 
>>broadcast/multicast and Dijkstra routing for unicast and simplifications 
>>are  possible.
>>
>> 
>>
>>    
>>
>>>********
>>>I personally don't have strong opinions on this. If only a miniscule 
>>>amount of
>>>the traffic is multicast/unknown, then one spanning tree seems good 
>>>enough. If
>>>there's high volume IP-derived multicast applications, then perhaps one per
>>>RBridge would be worth it.
>>>
>>>So I guess I'd be inclined to either just have one spanning tree, or one per
>>>ingress RBridge.
>>>
>>>And if we did one per ingress RBridge, would it be worth computing all 
>>>those trees
>>>in advance just in case, or only computing one when necessary?
>>>
>>>Radia
>>>
>>>      
>>>

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

Content-class: urn:content-classes:message
Date: Mon, 8 Aug 2005 22:19:15 -0700
From: "Vishwas Manral" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Doubts about Rbridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 7555

Hi Radia,

(PS: I am changing the subject line) 
The existing bridges (switches) already do IGMP snooping, to limit multicast traffic. That scenario would break.

A lot of existing layer-2 devices do firewall functionality. Firewall functionality in the silicon may not work with Rbridges coming in.

Maybe I am missing the point altogether.

Thanks,
Vishwas
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Radia Perlman
Sent: Monday, August 08, 2005 9:58 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] How many spanning trees?

Re: Vishwas's question about encapsulation hiding the true nature of 
packets from possible intervening
bridges (since the subject line would be otherwise misleading).

Are all these things written down someplace? I find it frustrating to 
design around undocumented
proprietary behavior (such as NATs). But anyway...

I'd think firewalling wouldn't be that much of a problem. We wouldn't 
need a basic bridge in the core
to be doing firewall...that could/should be done by an RBridge. Except 
if there were a basic bridge between
the endnodes and the first RBridge, which is a natural place to
put a firewall---then the basic bridge would see packets exactly as 
today and
be able to do the same firewalling with no problem.

As for IGMP...it would be the RBridges doing the IGMP snooping. For a 
basic bridge in the
core, it would indeed not recognize an IGMP packet, but that's the 
behavior we want. It would
just think it was forwarding vanilla multicast...it would be the 
RBridges deciding what IP multicast
packets should be forwarded across which links, and intervening bridges 
should just forward.

Can think of any other bridge idiosyncrasies we should think about?

Thanks,

Radia

Vishwas Manral wrote:

>Hi Radia,
>
>I had a few doubts about mixed environments where we want rbridge coexisting properly with normal bridges/ switches.
>
>The rbridge document aims to add a new shim header after the layer-2 header. The draft states that "A packet in transit must look to ordinary bridges like an ordinary layer 2 packet." However switches (in the silicon itself) these days are more intelligent and do deep packet processing (for example for a basic firewall functionality/ IGMP snooping etc). As the new ether Type would be unidentifiable, this would result in a wrong behavior (example a basic filtering for wrong IP header length check would fail here). However the rbridge protocol defined in such a case will not work properly.
>
>I know of existing switches which do both of the above. Do let me know where I am missing the point?
>
>Thanks,
>Vishwas
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Radia Perlman
>Sent: Tuesday, June 28, 2005 10:14 PM
>To: Developing a hybrid router/bridge.
>Subject: Re: [rbridge] How many spanning trees?
>
>You are right that paths will not be the same from A to B as from B to A 
>with an A-rooted tree (towards B)
>vs a B-rooted tree (towards A), at least if we do a straightforward 
>calculation of spanning trees. I think trying
>to accomplish symmetric routes might
>require source/destination pair route computation. So hopefully we won't 
>require symmetric routes.
>
>Radia
>
>
>
>Guillermo Ib??ez wrote:
>
>  
>
>>Guillermo Ib??ez wrote:
>>This is my feedback on the "how many spanning trees" issue.
>>
>>
>>Radia Perlman wrote:
>>
>> 
>>
>>    
>>
>>>It would be nice to get opinions on remaining issues, and I think each
>>>issue should be in a different email thread, so I'm starting one.
>>>
>>>How many spanning
>>>trees should RBridges compute? Given the link state database, they can 
>>>calculate
>>>as many as we want without further protocol messages. The possibilities are:
>>>
>>>a) one spanning tree: This is simplest, obviously. 
>>>
>>>   
>>>
>>>      
>>>
>>The poor performance in the core for multicast is an important argument 
>>against it. Other possibilities should exist, at least as an option.
>>
>> 
>>
>>    
>>
>>>b) one per VLAN: How it would work:each RBridge announces, in its link state info, which VLANs that
>>>RBridge is attached to.  To calculate a spanning tree for VLAN A, the 
>>>RBridges 
>>>(all of them...not just those attached to VLAN A) choose the RBridge, 
>>>RA, that
>>>has the lowest ID, AND that is attached to VLAN A. A spanning tree is 
>>>calculated
>>>with RA as root. THat spanning tree is pruned so that only branches that 
>>>reach
>>>other VLAN A links survive.
>>>
>>>Why bother: If only a few links are VLAN A, then this allows more 
>>>optimal delivery
>>>of multicast/unknown frames within the VLAN A broadcast domain.
>>>
>>>
>>>   
>>>
>>>      
>>>
>>It seems that with this implementation  compatibility (interoperability) 
>>with bridges running Multiple Spanning Tree Protocol (MSTP) is 
>>excluded.  If bridges running MSTP exist  in the campus network, they 
>>must be confined in one or several MST regions with their specific 
>>VLAN-to-spanning tree instance mappings and,  like happens with STP or 
>>RSTP, the trees will end at the region boundary with an rbridge. This 
>>means that there could coexist "regions" running MSTP with their own 
>>VLANs and multiple spanning trees inside the region, these regions 
>>inserted between rbridges that use another type (range or IDs) of VLANs. 
>>My understanding is then that the only VLANs capable of traversing the 
>>campus end-to-end would be the VLANs handled by Rbridges, as the other 
>>would be stopped by Rbridges if they are not known by them. 
>>
>>c) one per RBridge
>>
>> 
>>
>>    
>>
>>>Why bother: for IP multicasts, if RBridges do IGMP snooping, then this 
>>>allows
>>>optimal delivery from source to the receivers of a particular multicast.
>>>
>>>Another reason is that it minimizes out of order delivery of packets in the
>>>case when S it talking to D, and initially D is unknown by the RBridges 
>>>and packets
>>>have to be sent over a spanning tree rather than on the shortest path 
>>>   
>>>
>>>      
>>>
>>>from S to D.
>> 
>>
>>    
>>
>>>   
>>>
>>>      
>>>
>>One tree per bridge is very efficient together with IGMP snooping, 
>>assuming a core of rbridges. The plus point is that in this case the 
>>multiple trees can also perform routing of unicast traffic, if used 
>>together with the MAC address learning mechanism. In other words: 
>>assuming a core formed by rbridges,  using an spaning tree per rbridge 
>>may be enough to perform all the routing via minimum paths. This 
>>requires that the  address learning mechanism works over the trees (the 
>>trees coincide in opposite directions A to B and B to A, a tricky issue 
>>when path costs can be equal).  So it seems that there is some 
>>overlapping or overkillling using multiple spanning trees for 
>>broadcast/multicast and Dijkstra routing for unicast and simplifications 
>>are  possible.
>>
>> 
>>
>>    
>>
>>>********
>>>I personally don't have strong opinions on this. If only a miniscule 
>>>amount of
>>>the traffic is multicast/unknown, then one spanning tree seems good 
>>>enough. If
>>>there's high volume IP-derived multicast applications, then perhaps one per
>>>RBridge would be worth it.
>>>
>>>So I guess I'd be inclined to either just have one spanning tree, or one per
>>>ingress RBridge.
>>>
>>>And if we did one per ingress RBridge, would it be worth computing all 
>>>those trees
>>>in advance just in case, or only computing one when necessary?
>>>
>>>Radia
>>>
>>>      
>>>

Date: Mon, 08 Aug 2005 18:18:06 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] How many spanning trees?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 7013

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

Vishwas Manral wrote:
> Hi Radia,
>=20
> I had a few doubts about mixed environments where we want rbridge
coexisting properly with normal bridges/ switches.
>=20
> The rbridge document aims to add a new shim header after the layer-2
> header. The draft states that "A packet in transit must look to ordinar=
y
> bridges like an ordinary layer 2 packet." However switches (in the
> silicon itself) these days are more intelligent and do deep packet
> processing (for example for a basic firewall functionality/ IGMP
> snooping etc). As the new ether Type would be unidentifiable, this woul=
d
> result in a wrong behavior (example a basic filtering for wrong IP
> header length check would fail here). However the rbridge protocol
> defined in such a case will not work properly.

Bridges should continue to bridge ethertypes that they do not know how
to parse a-priori, otherwise they are not ethernet bridge devices.

The rest of what you're describing are optional optimizations, which
indeed will not occur for rbridge'd packets inside the campus.

Joe

> I know of existing switches which do both of the above. Do let me
> know where I am missing the point?

> Thanks,
> Vishwas
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On=
 Behalf Of Radia Perlman
> Sent: Tuesday, June 28, 2005 10:14 PM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] How many spanning trees?
>=20
> You are right that paths will not be the same from A to B as from B to =
A=20
> with an A-rooted tree (towards B)
> vs a B-rooted tree (towards A), at least if we do a straightforward=20
> calculation of spanning trees. I think trying
> to accomplish symmetric routes might
> require source/destination pair route computation. So hopefully we won'=
t=20
> require symmetric routes.
>=20
> Radia
>=20
>=20
>=20
> Guillermo Ib=E1=F1ez wrote:
>=20
>=20
>>Guillermo Ib=E1=F1ez wrote:
>>This is my feedback on the "how many spanning trees" issue.
>>
>>
>>Radia Perlman wrote:
>>
>>=20
>>
>>
>>>It would be nice to get opinions on remaining issues, and I think each=

>>>issue should be in a different email thread, so I'm starting one.
>>>
>>>How many spanning
>>>trees should RBridges compute? Given the link state database, they can=
=20
>>>calculate
>>>as many as we want without further protocol messages. The possibilitie=
s are:
>>>
>>>a) one spanning tree: This is simplest, obviously.=20
>>>
>>>  =20
>>>
>>
>>The poor performance in the core for multicast is an important argument=
=20
>>against it. Other possibilities should exist, at least as an option.
>>
>>=20
>>
>>
>>>b) one per VLAN: How it would work:each RBridge announces, in its link=
 state info, which VLANs that
>>>RBridge is attached to.  To calculate a spanning tree for VLAN A, the =

>>>RBridges=20
>>>(all of them...not just those attached to VLAN A) choose the RBridge, =

>>>RA, that
>>>has the lowest ID, AND that is attached to VLAN A. A spanning tree is =

>>>calculated
>>>with RA as root. THat spanning tree is pruned so that only branches th=
at=20
>>>reach
>>>other VLAN A links survive.
>>>
>>>Why bother: If only a few links are VLAN A, then this allows more=20
>>>optimal delivery
>>>of multicast/unknown frames within the VLAN A broadcast domain.
>>>
>>>
>>>  =20
>>>
>>
>>It seems that with this implementation  compatibility (interoperability=
)=20
>>with bridges running Multiple Spanning Tree Protocol (MSTP) is=20
>>excluded.  If bridges running MSTP exist  in the campus network, they=20
>>must be confined in one or several MST regions with their specific=20
>>VLAN-to-spanning tree instance mappings and,  like happens with STP or =

>>RSTP, the trees will end at the region boundary with an rbridge. This=20
>>means that there could coexist "regions" running MSTP with their own=20
>>VLANs and multiple spanning trees inside the region, these regions=20
>>inserted between rbridges that use another type (range or IDs) of VLANs=
=2E=20
>>My understanding is then that the only VLANs capable of traversing the =

>>campus end-to-end would be the VLANs handled by Rbridges, as the other =

>>would be stopped by Rbridges if they are not known by them.=20
>>
>>c) one per RBridge
>>
>>=20
>>
>>
>>>Why bother: for IP multicasts, if RBridges do IGMP snooping, then this=
=20
>>>allows
>>>optimal delivery from source to the receivers of a particular multicas=
t.
>>>
>>>Another reason is that it minimizes out of order delivery of packets i=
n the
>>>case when S it talking to D, and initially D is unknown by the RBridge=
s=20
>>>and packets
>>>have to be sent over a spanning tree rather than on the shortest path =

>>>  =20
>>>
>>
>>>from S to D.
>>=20
>>
>>
>>>
>>>  =20
>>>
>>
>>One tree per bridge is very efficient together with IGMP snooping,=20
>>assuming a core of rbridges. The plus point is that in this case the=20
>>multiple trees can also perform routing of unicast traffic, if used=20
>>together with the MAC address learning mechanism. In other words:=20
>>assuming a core formed by rbridges,  using an spaning tree per rbridge =

>>may be enough to perform all the routing via minimum paths. This=20
>>requires that the  address learning mechanism works over the trees (the=
=20
>>trees coincide in opposite directions A to B and B to A, a tricky issue=
=20
>>when path costs can be equal).  So it seems that there is some=20
>>overlapping or overkillling using multiple spanning trees for=20
>>broadcast/multicast and Dijkstra routing for unicast and simplification=
s=20
>>are  possible.
>>
>>=20
>>
>>
>>>********
>>>I personally don't have strong opinions on this. If only a miniscule=20
>>>amount of
>>>the traffic is multicast/unknown, then one spanning tree seems good=20
>>>enough. If
>>>there's high volume IP-derived multicast applications, then perhaps on=
e per
>>>RBridge would be worth it.
>>>
>>>So I guess I'd be inclined to either just have one spanning tree, or o=
ne per
>>>ingress RBridge.
>>>
>>>And if we did one per ingress RBridge, would it be worth computing all=
=20
>>>those trees
>>>in advance just in case, or only computing one when necessary?
>>>
>>>Radia
>>>
>=20
>=20
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://www.postel.org/mailman/listinfo/rbridge

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

--------------enigD5CD9DB6C2C9A5EB78E3DCFB--

Date: Mon, 08 Aug 2005 09:28:29 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] How many spanning trees?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 7096

Re: Vishwas's question about encapsulation hiding the true nature of 
packets from possible intervening
bridges (since the subject line would be otherwise misleading).

Are all these things written down someplace? I find it frustrating to 
design around undocumented
proprietary behavior (such as NATs). But anyway...

I'd think firewalling wouldn't be that much of a problem. We wouldn't 
need a basic bridge in the core
to be doing firewall...that could/should be done by an RBridge. Except 
if there were a basic bridge between
the endnodes and the first RBridge, which is a natural place to
put a firewall---then the basic bridge would see packets exactly as 
today and
be able to do the same firewalling with no problem.

As for IGMP...it would be the RBridges doing the IGMP snooping. For a 
basic bridge in the
core, it would indeed not recognize an IGMP packet, but that's the 
behavior we want. It would
just think it was forwarding vanilla multicast...it would be the 
RBridges deciding what IP multicast
packets should be forwarded across which links, and intervening bridges 
should just forward.

Can think of any other bridge idiosyncrasies we should think about?

Thanks,

Radia

Vishwas Manral wrote:

>Hi Radia,
>
>I had a few doubts about mixed environments where we want rbridge coexisting properly with normal bridges/ switches.
>
>The rbridge document aims to add a new shim header after the layer-2 header. The draft states that "A packet in transit must look to ordinary bridges like an ordinary layer 2 packet." However switches (in the silicon itself) these days are more intelligent and do deep packet processing (for example for a basic firewall functionality/ IGMP snooping etc). As the new ether Type would be unidentifiable, this would result in a wrong behavior (example a basic filtering for wrong IP header length check would fail here). However the rbridge protocol defined in such a case will not work properly.
>
>I know of existing switches which do both of the above. Do let me know where I am missing the point?
>
>Thanks,
>Vishwas
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Radia Perlman
>Sent: Tuesday, June 28, 2005 10:14 PM
>To: Developing a hybrid router/bridge.
>Subject: Re: [rbridge] How many spanning trees?
>
>You are right that paths will not be the same from A to B as from B to A 
>with an A-rooted tree (towards B)
>vs a B-rooted tree (towards A), at least if we do a straightforward 
>calculation of spanning trees. I think trying
>to accomplish symmetric routes might
>require source/destination pair route computation. So hopefully we won't 
>require symmetric routes.
>
>Radia
>
>
>
>Guillermo Ib??ez wrote:
>
>  
>
>>Guillermo Ib??ez wrote:
>>This is my feedback on the "how many spanning trees" issue.
>>
>>
>>Radia Perlman wrote:
>>
>> 
>>
>>    
>>
>>>It would be nice to get opinions on remaining issues, and I think each
>>>issue should be in a different email thread, so I'm starting one.
>>>
>>>How many spanning
>>>trees should RBridges compute? Given the link state database, they can 
>>>calculate
>>>as many as we want without further protocol messages. The possibilities are:
>>>
>>>a) one spanning tree: This is simplest, obviously. 
>>>
>>>   
>>>
>>>      
>>>
>>The poor performance in the core for multicast is an important argument 
>>against it. Other possibilities should exist, at least as an option.
>>
>> 
>>
>>    
>>
>>>b) one per VLAN: How it would work:each RBridge announces, in its link state info, which VLANs that
>>>RBridge is attached to.  To calculate a spanning tree for VLAN A, the 
>>>RBridges 
>>>(all of them...not just those attached to VLAN A) choose the RBridge, 
>>>RA, that
>>>has the lowest ID, AND that is attached to VLAN A. A spanning tree is 
>>>calculated
>>>with RA as root. THat spanning tree is pruned so that only branches that 
>>>reach
>>>other VLAN A links survive.
>>>
>>>Why bother: If only a few links are VLAN A, then this allows more 
>>>optimal delivery
>>>of multicast/unknown frames within the VLAN A broadcast domain.
>>>
>>>
>>>   
>>>
>>>      
>>>
>>It seems that with this implementation  compatibility (interoperability) 
>>with bridges running Multiple Spanning Tree Protocol (MSTP) is 
>>excluded.  If bridges running MSTP exist  in the campus network, they 
>>must be confined in one or several MST regions with their specific 
>>VLAN-to-spanning tree instance mappings and,  like happens with STP or 
>>RSTP, the trees will end at the region boundary with an rbridge. This 
>>means that there could coexist "regions" running MSTP with their own 
>>VLANs and multiple spanning trees inside the region, these regions 
>>inserted between rbridges that use another type (range or IDs) of VLANs. 
>>My understanding is then that the only VLANs capable of traversing the 
>>campus end-to-end would be the VLANs handled by Rbridges, as the other 
>>would be stopped by Rbridges if they are not known by them. 
>>
>>c) one per RBridge
>>
>> 
>>
>>    
>>
>>>Why bother: for IP multicasts, if RBridges do IGMP snooping, then this 
>>>allows
>>>optimal delivery from source to the receivers of a particular multicast.
>>>
>>>Another reason is that it minimizes out of order delivery of packets in the
>>>case when S it talking to D, and initially D is unknown by the RBridges 
>>>and packets
>>>have to be sent over a spanning tree rather than on the shortest path 
>>>   
>>>
>>>      
>>>
>>>from S to D.
>> 
>>
>>    
>>
>>>   
>>>
>>>      
>>>
>>One tree per bridge is very efficient together with IGMP snooping, 
>>assuming a core of rbridges. The plus point is that in this case the 
>>multiple trees can also perform routing of unicast traffic, if used 
>>together with the MAC address learning mechanism. In other words: 
>>assuming a core formed by rbridges,  using an spaning tree per rbridge 
>>may be enough to perform all the routing via minimum paths. This 
>>requires that the  address learning mechanism works over the trees (the 
>>trees coincide in opposite directions A to B and B to A, a tricky issue 
>>when path costs can be equal).  So it seems that there is some 
>>overlapping or overkillling using multiple spanning trees for 
>>broadcast/multicast and Dijkstra routing for unicast and simplifications 
>>are  possible.
>>
>> 
>>
>>    
>>
>>>********
>>>I personally don't have strong opinions on this. If only a miniscule 
>>>amount of
>>>the traffic is multicast/unknown, then one spanning tree seems good 
>>>enough. If
>>>there's high volume IP-derived multicast applications, then perhaps one per
>>>RBridge would be worth it.
>>>
>>>So I guess I'd be inclined to either just have one spanning tree, or one per
>>>ingress RBridge.
>>>
>>>And if we did one per ingress RBridge, would it be worth computing all 
>>>those trees
>>>in advance just in case, or only computing one when necessary?
>>>
>>>Radia
>>>
>>>      
>>>
>
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>

Content-class: urn:content-classes:message
Date: Mon, 8 Aug 2005 05:40:01 -0700
From: "Vishwas Manral" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] How many spanning trees?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5485

Hi Radia,

I had a few doubts about mixed environments where we want rbridge coexisting properly with normal bridges/ switches.

The rbridge document aims to add a new shim header after the layer-2 header. The draft states that "A packet in transit must look to ordinary bridges like an ordinary layer 2 packet." However switches (in the silicon itself) these days are more intelligent and do deep packet processing (for example for a basic firewall functionality/ IGMP snooping etc). As the new ether Type would be unidentifiable, this would result in a wrong behavior (example a basic filtering for wrong IP header length check would fail here). However the rbridge protocol defined in such a case will not work properly.

I know of existing switches which do both of the above. Do let me know where I am missing the point?

Thanks,
Vishwas
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Radia Perlman
Sent: Tuesday, June 28, 2005 10:14 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] How many spanning trees?

You are right that paths will not be the same from A to B as from B to A 
with an A-rooted tree (towards B)
vs a B-rooted tree (towards A), at least if we do a straightforward 
calculation of spanning trees. I think trying
to accomplish symmetric routes might
require source/destination pair route computation. So hopefully we won't 
require symmetric routes.

Radia

Guillermo Ib??ez wrote:

>Guillermo Ib??ez wrote:
>This is my feedback on the "how many spanning trees" issue.
>
>
>Radia Perlman wrote:
>
>  
>
>>It would be nice to get opinions on remaining issues, and I think each
>>issue should be in a different email thread, so I'm starting one.
>>
>>How many spanning
>>trees should RBridges compute? Given the link state database, they can 
>>calculate
>>as many as we want without further protocol messages. The possibilities are:
>>
>>a) one spanning tree: This is simplest, obviously. 
>>
>>    
>>
>The poor performance in the core for multicast is an important argument 
>against it. Other possibilities should exist, at least as an option.
>
>  
>
>>b) one per VLAN: How it would work:each RBridge announces, in its link state info, which VLANs that
>>RBridge is attached to.  To calculate a spanning tree for VLAN A, the 
>>RBridges 
>>(all of them...not just those attached to VLAN A) choose the RBridge, 
>>RA, that
>>has the lowest ID, AND that is attached to VLAN A. A spanning tree is 
>>calculated
>>with RA as root. THat spanning tree is pruned so that only branches that 
>>reach
>>other VLAN A links survive.
>>
>>Why bother: If only a few links are VLAN A, then this allows more 
>>optimal delivery
>>of multicast/unknown frames within the VLAN A broadcast domain.
>> 
>>
>>    
>>
>
>It seems that with this implementation  compatibility (interoperability) 
>with bridges running Multiple Spanning Tree Protocol (MSTP) is 
>excluded.  If bridges running MSTP exist  in the campus network, they 
>must be confined in one or several MST regions with their specific 
>VLAN-to-spanning tree instance mappings and,  like happens with STP or 
>RSTP, the trees will end at the region boundary with an rbridge. This 
>means that there could coexist "regions" running MSTP with their own 
>VLANs and multiple spanning trees inside the region, these regions 
>inserted between rbridges that use another type (range or IDs) of VLANs. 
>My understanding is then that the only VLANs capable of traversing the 
>campus end-to-end would be the VLANs handled by Rbridges, as the other 
>would be stopped by Rbridges if they are not known by them. 
>
>c) one per RBridge
>
>  
>
>>Why bother: for IP multicasts, if RBridges do IGMP snooping, then this 
>>allows
>>optimal delivery from source to the receivers of a particular multicast.
>>
>>Another reason is that it minimizes out of order delivery of packets in the
>>case when S it talking to D, and initially D is unknown by the RBridges 
>>and packets
>>have to be sent over a spanning tree rather than on the shortest path 
>>    
>>
>>from S to D.
>  
>
>> 
>>
>>    
>>
>One tree per bridge is very efficient together with IGMP snooping, 
>assuming a core of rbridges. The plus point is that in this case the 
>multiple trees can also perform routing of unicast traffic, if used 
>together with the MAC address learning mechanism. In other words: 
>assuming a core formed by rbridges,  using an spaning tree per rbridge 
>may be enough to perform all the routing via minimum paths. This 
>requires that the  address learning mechanism works over the trees (the 
>trees coincide in opposite directions A to B and B to A, a tricky issue 
>when path costs can be equal).  So it seems that there is some 
>overlapping or overkillling using multiple spanning trees for 
>broadcast/multicast and Dijkstra routing for unicast and simplifications 
>are  possible.
>
>  
>
>>********
>>I personally don't have strong opinions on this. If only a miniscule 
>>amount of
>>the traffic is multicast/unknown, then one spanning tree seems good 
>>enough. If
>>there's high volume IP-derived multicast applications, then perhaps one per
>>RBridge would be worth it.
>>
>>So I guess I'd be inclined to either just have one spanning tree, or one per
>>ingress RBridge.
>>
>>And if we did one per ingress RBridge, would it be worth computing all 
>>those trees
>>in advance just in case, or only computing one when necessary?
>>
>>Radia
>>

Content-class: urn:content-classes:message
Date: Thu, 4 Aug 2005 03:34:00 -0700
From: "Vishwas Manral" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Private VLAN support
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5212

This is a multi-part message in MIME format.

------_=_NextPart_001_01C598E0.624BA546
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Radia,
=20
Here is the link to Private VLAN
http://www.ietf.org/internet-drafts/draft-sanjib-private-vlan-03.txt
=20
The question is do we intend to support backward compatibility with all =
features running on switches and actually deployed but not standardized?
=20
Thanks,
Vishwas
=20
=20

------_=_NextPart_001_01C598E0.624BA546
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C598E0.624BA546--

Content-class: urn:content-classes:message
Date: Tue, 2 Aug 2005 10:54:25 -0700
From: "Vishwas Manral" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Updated TRILL agenda
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 8312

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5978B.38B8A3BF
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
One small typo, the draft name is draft-perlman-rbridge-03.txt
=20
Thanks,
Vishwas

________________________________

From: [email-masked] on behalf of Erik Nordmark
Sent: Tue 8/2/2005 10:06 AM
To: Developing a hybrid router/bridge.
Subject: [rbridge] Updated TRILL agenda

Transparent Interconnection of Lots of Links (TRILL)

THURSDAY, August 4, 1030-1230
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
Room: Room 342

CHAIR: Erik Nordmark <[email-masked]>

AGENDA:

Introduction, Call for Scribes,         Nordmark        05 minutes
and Agenda Bashing

Deliverables status                     Nordmark        10 minutes
<http://www.ietf.org/html.charters/trill-charter.html>

Coordination with IEEE 802.1            Eastlake        10 minutes
Goal: Discuss options for review.

Problem statement and architecture      Nordmark        20 minutes
Goal: Discuss outline, find editor?

Requirements on routing protocols       Nordmark        15 minutes
Goal: Discuss outline, find editor?

Protocol document - open issues         Perlman         50 minutes
<draft-perlman-rbridge-rbridge-03.txt>
Goal: Enumerate and discuss open issues
       Accept as WG document?

=20

=20

------_=_NextPart_001_01C5978B.38B8A3BF
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C5978B.38B8A3BF--

Date: Tue, 02 Aug 2005 10:06:38 -0700
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Updated TRILL agenda
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 801

Transparent Interconnection of Lots of Links (TRILL)

THURSDAY, August 4, 1030-1230
==============================
Room: Room 342

CHAIR: Erik Nordmark <[email-masked]>

AGENDA:

Introduction, Call for Scribes,         Nordmark        05 minutes
and Agenda Bashing

Deliverables status			Nordmark	10 minutes
<http://www.ietf.org/html.charters/trill-charter.html>

Coordination with IEEE 802.1		Eastlake	10 minutes
Goal: Discuss options for review.

Problem statement and architecture	Nordmark	20 minutes
Goal: Discuss outline, find editor?

Requirements on routing protocols	Nordmark	15 minutes
Goal: Discuss outline, find editor?

Protocol document - open issues		Perlman		50 minutes
<draft-perlman-rbridge-rbridge-03.txt>
Goal: Enumerate and discuss open issues
       Accept as WG document?

Date: Tue, 02 Aug 2005 10:02:47 -0700
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] name of the mailing list?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 229

Loa Andersson wrote:
> since the working group name is trill, are there any plans to
> change the name of the mailing list?
> 
> [email-masked] would be good

I'll work with the secretariat to have such a thing setup.

    Erik

Date: Tue, 02 Aug 2005 09:42:23 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] name of the mailing list?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1158

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig54BE50948C4C4714209596E3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

This isn't the only IETF WG that has a name that doesn't match that of
the WG.

FYI, right now, I maintain the mailing list and web pages
(www.postel.org/rbridge).

Not that it's critical, but I also don't think it's possible to move
either the list of subscribers or the current archive.

Joe

Loa Andersson wrote:
> since the working group name is trill, are there any plans to
> change the name of the mailing list?
> 
> [email-masked] would be good
> 
> /Loa
> 

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

--------------enig54BE50948C4C4714209596E3--

Date: Tue, 02 Aug 2005 17:46:07 +0200
From: Loa Andersson <[email-masked]>
Organization: Acreo AB
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] name of the mailing list?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 425

since the working group name is trill, are there any plans to
change the name of the mailing list?

[email-masked] would be good

/Loa

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

From: Eastlake III Donald-LDE008 <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Date: Mon, 1 Aug 2005 09:11:27 -0400 
Subject: Re: [rbridge] Draft trill agenda
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1849

Basically, there are three mechanisms that I can think of for TRILL working with the IEEE 802.1 WG (or perhaps its Interworking Task Group which handles bridging).

	1. Liaisons: we could appoint a person as liaison to them and/or they could appoint a person as liaison to us.
	2. Document reviews: we occasionally send them a document and ask for comments and/or they send us a document for our comments.
	3. Joint teleconferences/meetings.

There is nothing mutually exclusive about these so we could combine them. They are roughly in order of increasing effort.

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Erik Nordmark
Sent: Monday, August 01, 2005 5:34 AM
To: [email-masked]
Subject: [rbridge] Draft trill agenda

Any agenda bashing on the list?
Note that the TRILL charter says we will work with IEEE 802.1 and L2VPN, but we don't have any specific items reflected in the meeting agenda on that yet.

    Erik

Transparent Interconnection of Lots of Links (TRILL)

THURSDAY, August 4, 1030-1230
==============================
Room: Room 342

CHAIR: Erik Nordmark <[email-masked]>

AGENDA:

Introduction, Call for Scribes,         Nordmark        05 minutes
and Agenda Bashing

Deliverables status			Nordmark	10 minutes
<http://www.ietf.org/html.charters/trill-charter.html>

Problem statement and architecture	Nordmark	20 minutes
Goal: Discuss outline, find editor?

Requirements on routing protocols	Nordmark	15 minutes
Goal: Discuss outline, find editor?

Protocol document - open issues		Perlman		50 minutes
<draft-perlman-rbridge-rbridge-03.txt>
Goal: Enumerate and discuss open issue
       Accept as WG document?

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

Date: Mon, 01 Aug 2005 02:34:29 -0700
From: Erik Nordmark <[email-masked]>
To: [email-masked]
Subject: [rbridge] Draft trill agenda
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 919

Any agenda bashing on the list?
Note that the TRILL charter says we will work with IEEE 802.1 and L2VPN, 
but we don't have any specific items reflected in the meeting agenda on 
that yet.

    Erik

Transparent Interconnection of Lots of Links (TRILL)

THURSDAY, August 4, 1030-1230
==============================
Room: Room 342

CHAIR: Erik Nordmark <[email-masked]>

AGENDA:

Introduction, Call for Scribes,         Nordmark        05 minutes
and Agenda Bashing

Deliverables status			Nordmark	10 minutes
<http://www.ietf.org/html.charters/trill-charter.html>

Problem statement and architecture	Nordmark	20 minutes
Goal: Discuss outline, find editor?

Requirements on routing protocols	Nordmark	15 minutes
Goal: Discuss outline, find editor?

Protocol document - open issues		Perlman		50 minutes
<draft-perlman-rbridge-rbridge-03.txt>
Goal: Enumerate and discuss open issue
       Accept as WG document?