[rbridge] WG Review: Transparent Interconnection of Lots of Links (trill)

[Radia.Perlman at sun.com (Radia Perlman)]

There's a difference between requiring IP addresses for manageability in 
a campus with
a flat address space (all one IP subnet), and requiring divvying up the 
IP space in
order to acquire link-specific IP addresses. The first can be done with 
DHCP, does
not require partitioning the IP space, and does not require changing 
addresses if
you move around. Avoiding the latter (configuring IP prefixes per link) 
does not
preclude the former (having switches acquire IP addresses for 
manageability).

Not that this changes the wording of the charter, but thought I should 
clarify.

Radia



W. Mark Townsley wrote:

>Adrian Farrel wrote:
>
>  
>
>> > In any case, given that ISIS is not mentioned in the TRILL charter, and
>> > presumably that we haven't actually made the choice of *which* routing
>> > protocol TRILL will use at the charter level, I agree that this reference
>> > should be removed.
>> 
>>OK, that makes sense. Thanks.
>> 
>>It occurs to me that a fundamental difference between CCAMP and TRILL 
>>may be that (at this stage) CCAMP assumes the existence of an IP-based 
>>control plane. TRILL will (presumably? possibly?)
>>    
>>
>
>I believe  "presumably," at least that is my understanding thus far. The idea 
>that there is at least one mode of operation that passes packets right "out of 
>the box" is fundamental. Certainly, an IP address needs to exist on the node for 
>it to be properly managed, but it seems that this is *after* its connection to 
>the network has started to cause big problems ;-)
>
> > determine that the
>  
>
>>routing protocol should be carried direct over the MAC layer. 
>>Nevertheless, we will probably want to flood the same or similar 
>>information about the links.
>>    
>>
>
>Yes, I think that this is the part that we should be sure to collaborate on. If 
>CCAMP has already provided extensions to routing protocols to flood MACs, we 
>should probably try and do it as similarly as possible for the poor coders out 
>there that will end up doing both, while ensuring we have the proper code-points 
>in place to avoid stepping on one another where it hurts.
>
>Thanks,
>
>- Mark
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>  
>