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

[Silvano Gai]

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