[rbridge] Learning endnode locations (was something like "encoding IS-IS encapsulation")

[Eric Gray (LO/EUS)]

Silvano,

	I would qualify this somewhat differently: I would say
"MUST be capable of MAC learning via data-frame examination
and MAY be configurable for learning from IS-IS advertisement
- either in addition to MAC learning, or in lieu of it.  The
default configuration is with MAC learning from data frames 
in operation (enabled)."

	The reason I would characterize it this way is that it
MAY be the case that there are applications for which learning
from data frames MUST be disabled.  Clearly this will not work
for bridges that only have this capability, but that would be
the choice a buyer makes...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:sgai at nuovasystems.com] 
> Sent: Monday, May 21, 2007 5:16 PM
> To: Radia Perlman; Eric Gray (LO/EUS)
> Cc: Rbridge at postel.org
> Subject: RE: [rbridge] Learning endnode locations (was 
> something like "encoding IS-IS encapsulation")
> Importance: High
> 
> I am in favor of "RBridge MUST learn from data frame and MAY 
> learn from
> IS-IS". I propose to defer the "MAY learn from IS-IS" part to 
> a separate
> draft, when we have some implementation experience.
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
> On
> > Behalf Of Radia Perlman
> > Sent: Monday, May 21, 2007 10:39 AM
> > To: Eric Gray (LO/EUS)
> > Cc: Rbridge at postel.org
> > Subject: [rbridge] Learning endnode locations (was something like
> > "encoding IS-IS encapsulation")
> > 
> > (Changing the subject line when answering Eric because Eric was
> > asking about something very different -- a major
> > change we've been assuming we
> > should be making and I want to make sure that the WG has a chance to
> > really understand what's going on and debate it). The 
> original subject
> > line
> > was about the bit twiddling encoding issue of whether we should use
> > a reserved bit, or a reserved nickname value, or whatever, 
> to signal,
> in
> > the TRILL
> > header, that the enclosed frame is a TRILL IS-IS frame. But 
> I'm again
> > reminding
> > people that we are proposing to change the preferred method of
> learning
> > endnodes
> > from explicit advertisement in IS-IS to learning from decapsulated
> data
> > packets.)
> > 
> > This issue really has nothing to do with VLANs, and so my 
> referring to
> it
> > as
> > "getting rid of the per-VLAN instance of IS-IS" is definitely
> confusing.
> > Sorry about that.
> > It was the per-VLAN instance of IS-IS link state packets in which
> > attached endnodes
> > were announced, which is why I was referring to the issue 
> as "getting
> > rid of the
> > per-VLAN instance of IS-IS".
> > 
> > So now that I've finished apologizing for confusing people, let me
> again
> > summarize
> > the pros and cons of how to learn endnode membership.
> > 
> > 1) if all RBridges advertise endnode membership with IS-IS, then it
> works
> > if
> > some RBridges learn from IS-IS and others learn from decapsulating
> data
> > packets
> > 2) if all RBridges learn from decapsulating data packets, then it
> works if
> > some RBridges choose to advertise some (or all) attached 
> endnodes with
> > IS-IS,
> > and some RBridges choose to listen to those advertisements.
> > 
> > What does not work is if some RBridges want to *only* learn 
> from IS-IS
> > advertisements,
> > and other RBridges do not advertise via IS-IS.
> > 
> > What are the arguments on each side?
> > 
> > a) IS-IS advertising takes bandwidth, but cuts down on unnecessary
> > flooding
> > b) learning from data is more scalable in terms of
> > memory at an RBridge because an RBridge RB1 only has to keep
> > track of the distant endnodes that are currently talking to endnodes
> on
> > RB1's links.
> > c) In some cases the Designated RBridge is very sure which endnodes
> are
> > attached,
> > because of an explicit layer 2 enrollment protocol, possibly even
> > cryptographically
> > authenticated. It is easier to secure this sort of 
> learning, since the
> > IS-IS announcement
> > can also be cryptographically authenticated, than receipt of a data
> > packet with
> > a given source address, since a rogue endnode can easily 
> send packets
> with
> > any source address
> > d) Learning from IS-IS has more of a "layer 3" flavor, so would be
> more
> > the
> > kind of thing layer 3 type people would design. Learning from data
> > packets has
> > more of a "layer 2" flavor. The only technical reason this is
> relevant,
> > I think, is
> > that some layer 3 devices may not be easily able to learn from the
> data
> > path.
> > e) Black holes might persist longer, if a distant RBridge, RB1 is
> confused
> > about the location of endnode E (perhaps because E moved). Which is
> why
> > I'd
> > like to also add an error message where the named egress 
> RBridge RB2)
> > can complain
> > to RB1 (which selected RB2 as egress for endnode E), that E is not
> > actually attached
> > to RB2, so RB1 should take (RB2, E) out of its cache.
> > f) The spec is simpler to understand, especially for "layer 2 type
> > people", if we
> > don't talk about the per-VLAN instance of endnode advertising.
> > 
> > My real opinion here is that either way is acceptable (learning from
> > IS-IS, or learning
> > from decapsulating data packets). Assuming we are making 
> learning from
> > data MUST,
> > then I'd like to also keep advertising endnodes via IS-IS a MAY, and
> > have it used for
> > definitively enrolled endnodes. And I'd like to add a "I'm not the
> right
> > egress RBridge for E"
> > message.
> > 
> > But what I don't want is to lose months agonizing over this 
> decision.
> We
> > should pick
> > one way and go with it. (where "one way" is which learning 
> method is a
> > MUST). It would
> > be great if there were some researchers who could give us some real
> > quantitative method
> > for making this decision. But beyond that, I'd go with whatever is
> most
> > convenient for
> > the people who are actually going to implement this.
> > 
> > So...now's the time to speak up.
> > 
> > Radia
> > 
> > 
> > 
> > 
> > Eric Gray (LO/EUS) wrote:
> > > Radia,
> > >
> > > 	I am not sure how you would specify behaviors that are based
> > > on the assumption that RBridges are specified for a single VLAN -
> > > with separate RBridge instances being used for separate VLANs - if
> > > (as you suggest) there are not separate IS-IS instances per-VLAN.
> > >
> > > 	How does that work?
> > >
> > > Thanks!
> > >
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > >
> > >
> > >> -----Original Message-----
> > >> From: rbridge-bounces at postel.org
> > >> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> > >> Sent: Saturday, May 19, 2007 12:08 AM
> > >> To: Rbridge at postel.org
> > >> Subject: [rbridge] How is an IS-IS packet differentiated from
> > >> layer 3 IS-IS, and TRILL-encapsulated data packets?
> > >>
> > >> Now that I'm editing the spec to be real specific here, I
> > >> need a sanity
> > >> check, or
> > >> advice from implementers about what would be most convenient for
> them.
> > >>
> > >> My assumption is that we are removing the per-VLAN instance of
> IS-IS
> > >> (which could
> > >> be added later on, for the purpose of distributing endnode
> > >> information
> > >> that is more
> > >> securely learned, say through a cryptographically
> > >> authenticated layer 2
> > >> enrollment
> > >> protocol). But we are requiring RBridges to learn 
> (ingress RBridge,
> > >> source MAC address)
> > >> from packets they are decapsulating onto their link.
> > >>
> > >> So we just have the core instance of IS-IS. We have to make
> > >> sure layer 3
> > >> IS-IS
> > >> packets (which might also be flowing across the campus
> > >> between routers)
> > >> don't
> > >> get confused with TRILL IS-IS. We also have to have 
> RBridges easily
> > >> distinguish
> > >> TRILL IS-IS Hellos and LSPs from ordinary encapsulated data
> packets.
> > >>
> > >> When a router generates an IS-IS packet, the destination
> > >> address will be
> > >> "all-level1-routers"
> > >> or "all-level-2 routers", or perhaps, a specific router (for
> > >> instance,
> > >> to send a PSNP).
> > >> The way this is recognized as an IS-IS packet is due to the
> > >> EThertype=IS-IS.
> > >>
> > >> RBridge, I believe, should not treat IS-IS packets
> > >> differently from any
> > >> other "data"
> > >> packets. If it's addressed to "all-level1-routers" or
> > >> "all-level2-routers" it would be
> > >> treated like any other multidestination packet, encapsulated,
> > >> and sent
> > >> along a distribution
> > >> tree. If it's unicast, it is treated like any other 
> unicast packet
> by
> > >> RBridges, assuming
> > >> the layer 2 address specified in the destination is known to
> > >> the ingress
> > >> RBridge.
> > >>
> > >> The question is---how are TRILL IS-IS packets encoded?
> > >>
> > >> Could we get a second Ethertype for this? I'm assuming not...
> > >>
> > >> I'm assuming we just have a single Ethertype for
> > >> "TRILL-encapsulated".
> > >> So we have
> > >> to use that.
> > >>
> > >> We could use a different multicast destination address for
> > >> "all-RBridges-for-IS-IS" vs
> > >> "all-RBridges" that is used for multicast data.
> > >>
> > >> Or we could have a bit in the TRILL header saying "this is an
> > >> IS-IS packet".
> > >>
> > >> We could in theory not use the TRILL header for IS-IS
> > >> packets, since in
> > >> theory
> > >> IS-IS does not need to be encapsulated (for layer 3 IS-IS it runs
> > >> directly over layer 2).
> > >> But then we'd need a separate Ethertype.
> > >>
> > >> So...if we are going to use the TRILL header, then how do we not
> get
> > >> confused
> > >> between TRILL IS-IS and layer 3 IS-IS?
> > >>
> > >> I guess we could assume that it's enough to have TRILL IS-IS
> > >> use "0" as
> > >> the area
> > >> address, and use IS-IS as the Ethertype in the inner header. For
> > >> TRILL-encapsulated
> > >> packets, we actually could choose some weirdo Ethertype (like
> > >> 0) in the
> > >> inner header.
> > >> But we still need to differentiate TRILL IS-IS from layer 3
> > >> IS-IS on the
> > >> first hop.
> > >>
> > >> This is probably something I should ask the IS-IS WG, since it
> really
> > >> depends on
> > >> idiosyncracies of the current IS-IS implementations.
> > >>
> > >> Radia
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> rbridge mailing list
> > >> rbridge at postel.org
> > >> http://mailman.postel.org/mailman/listinfo/rbridge
> > >>
> > >>
> > 
> > _______________________________________________
> > rbridge mailing list
> > rbridge at postel.org
> > http://mailman.postel.org/mailman/listinfo/rbridge
>