[rbridge] draft WG minutes

[Eric.Gray at marconi.com (Gray, Eric)]

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: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org]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
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->