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

[Radia Perlman]

(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
>>
>>