[rbridge] draft WG minutes

[erik.nordmark at sun.com (Erik Nordmark)]

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.

---