Subject: [rbridge] End station discovery/liveness detection

From: jaihyung at etri.re.kr (CHO, JAI HYUNG)
Date: Fri, 18 Mar 2005 17:45:32 +0900

Dear Joe Touch,

Thak you for your prompt response :-)

Joe wrote: 
>> 
>> oh.I see.. 
>> so, you argue that rbridge shouldn't prob end-station for liveness test 
>> or terminals shouldn't report status, but do link-status update 
>> as frequently as MAC entries appear in rbridge's MAC table, right? 
> 
>The last step does not follow from the first. The updates need to happen 
>relatively quickly when changes appear, but there may be delays to 
>aggregate changes and avoid routing storms that would be triggered by a 
>series of MAC changes. 
>

ok.. now we came back to the point that begins this mail thread. 
on Thu Mar 3 15:36:48 PST 2005, Alex Zinin started this discussion 
with following question.

"..MAC address info would account for the largest portion of information 
 distributed in the link-state routing protocol running in rbridges. Hence, 
 it's important to understand the change dynamics for it, as this will affect 
 how much information will be flooded around, and as a result affect 
 scalability of the technology. Without trying to pin it down here and now, I'd 
 like to understand what we can and can't get here."

so, my question is same. 
what are the characteristics of your "delayed update" approach? 
I think your proposal of "delay for aggregate changes" or other's "probing/reporting" 
are in-effect different optimization technique of simple dynamic link-state update. 
they both have pros and cons. I think it needs to be cleared before you guys 
move to next step. 

(% oh, by the way, Alex's text is not copywrited, isn't it? ;-)
 
>> Reading past discussion on this mail thread, it seems other 
>> people have little bit different idea. 
> 
>Yes, but they have not considered (IMO) the full impact of the 
>optimization on the L2 devices attached to an rbridge. Probing is fine 
>when L2 devices are directly attached, but when two rbridge campuses are 
>connected, or when L2 devices connect to conventional bridged subnets 
>then to an rbridge campus, such probing can cause broadcast storms on 
>the attached subnets. 
> 
>It seems dangerous and inappropriate for an rbridge to try to avoid 
>internal broadcasts by periodically issuing external broadcasts, but I 
>haven't see anyone who has proposed this optimization address the 
>situation I raised as a counterexample. 
>

that point will be noted as a weakness of probing technique, together 
with my point of unnecessary buildup of MAC info. 
to clear my position, I don't think both probing and delayed update 
are so good solution for scalability. rbridge needs a third approach.

>> ok... anyway, let's suppose in your way that link-status update 
>> will happen in that frequency, and see what problem you will face. 
>> I am wondering if you know how often terminals broadcast ARP 
>> and how frequently MAC entries are changing. 
> 
>I don't know, but also don't care. ;-) IMO, an rbridge could work if it 
>does as well as a bridge, and bridges do not do periodic liveness tests. 
>

MAC learning in bridge is performed in wire speed using CAM memory. 
However, link-status update and route calculation are complex procedure 
that have to be executed in control plane. the overhead can not be compared.

>> 
>> suppose that rbridges are spreading ARP in a systematic way that 
>> duplicates of ARPs are forwarded via SPF tree rooted at source rbridge. 
>> intermediate rbridges remember upstream node. 
>> 
>> when the destination terminal replies ARP reply, the rbridges install MAC 
>> forwarding state using the information contained in ARP message. 
> 
>You don't need to peek inside the ARP to figure anything out. The MAC 
>addresses at issue (that might have changed) are in the source address 
>of the ARP packet. 
>

I don't use ARP message as it is. I manipulate some values in ARP message. 
it requires ARP snooping by intermediate nodes.

>> the rbridge passes the ARP reply to upstream node, as a result, MAC forwarding 
>> path is established between source and destination terminal. 
> 
>OK - how does that work for the first ARP? The routing tables are empty. 
>So you distribute the arp via SPF - SPF isn't a broadcast tree. You need 
>to use broadcast on the first ARP, or it will never reach the dest. 
>

Good question !!! 
In my method, ARP messages carry a routing metric field that records 
path length the message has traversed. 
When a switch receives ARP request, it increments the metric value 
and spreads duplicates of the message blindly to all output links. 
Other switches that receive this ARP also repeat the same procedure. 
If a switch receives duplicates of ARP more than once, it repeats the copy and 
broadcast action ONLY WHEN the metric value (i.e. path length) is *SMALL*. 
As a result, only the message that has traversed via *shortest path* 
is accepted finally and propagate network.

For example in diagram below, switch S4 may receive ARP 
messages from S2 and S3. Whichever arrives first, S4 selects 
the one with smallest metric in the end. In the diagram, 
it is the ARP that S3 has passed to S4 (m=2). 

                       ARP(m=3) 
                [S1]-----------[S2] 
                  |                 | 
ARP(m=1)   |    ARP(m=2)    |    ARP(m=3) 
[Ta]----------[S3]-----------[S4]------------[Tb]

see http://www.ietf.org/internet-drafts/draft-jaihyung-ccamp-arpsignal-00.txt 
for detail. 

>The return ARP goes directly to the source of the original ARP. But you 
>didn't add anything to the routing tables yet, because you describe 
>doing this only for ARP replies. The return ARP has no way to get back! 
>

In my method, intermediate switches must record the upstream node 
that has passed ARP of the lowest metric value. 
ARP reply is returned hop-by-hop. When a switch receives ARP reply, 
the switch install MAC forwarding state and passes 
the ARP reply only to the upstream node of the lowest metric value. 
As a result, MAC forwarding path of shortest-path between source 
and destination is established. 
This routing method has been proven by simulation and published in 
several papers.

>> For your information, the goal of Pbridge is briefly stated in section 
>> 1.1 Scope of 802.1ad as following; 
> 
>You are forwarding proprietary specs of the IEEE. Please check copyright 
>issues before doing so again (it would be useful for this list not to 
>get into trouble with the IEEE)... 
>

thank you for reminding me. 
I'll be more careful when I excerpt other's.

>>>>In order to get favorable support from customer, you need a method of 
>>>>systematically organizing rbridged network consists of 100,000 of terminals. 
>>>>I can't think better method than IP subnetting of customer networks 
>>>>and interconnecting subnets by rbridge. 
>>> 
>>>I think you have that backwards; I would have rbridges of groups of 
>>>10,000 and IP routers between the groups. 
>> 
>> you misunderstand the nature of market requirement. 
>> it's not just a matter of scalability but matter of management and policy. 
>> network managers need a tool to group people and control 
>> privilege of accessing a group. 
> 
>Describe how that works on a set of learning bridges.

ok. it may not be easy in current design of rbridge, 
however in my method, 
the connectivity between terminals is established using ARP. 
therefore switches may control connectivity by filtering 
ARP messages according to policy. 
of course this filtering action is performed in control plane and 
data plane still works in L2. 
there are many types of policy implementable using the method. 
for example, network managers may group terminals into subnet. 
switches inside the subnet do not need to configure any subnet info. 
only the border switches of a subnet need this information to 
filter ARPs arriving from outside. 
It will effectively reduce broadcast storm and help to improve security. 

>> two, IEEE pbridge will scale better. 
>> three, processing overhead at that scale will seriously be heavy. 
> 
>If you think a pbridge is a better solution, why are you here? If we 
>change rbridge enough to make it look like a pbridge, we're done - just 
>go to the IEEE ;-) 
> 
>Joe 
>

to clear my position, I am NEVER a proponent of IEEE pbridge. 
I don't think IEEE pbridge will be so scalable. 
It also doesn't fit to NGN market requirement exactly. 
I'd rather think rbridge may have more potential if it make use of 
IP scalability and control well. 
Note that IP scalability is mostly achieved from flexible addressing structure 
that IETF has developed for many years of experience. 
If rbridge doesn't successfully employ this good features of routers, 
people will see rbridge just as another pbridge.
 
Thank you
 
Regards

Dr. Jaihyung Cho
ETRI, Korea
phone :       042) 860-5514
oversea: +82-42-860-5514
fax:         +82-42-861-5550

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 18 Mar 2005 07:13:59 -0800

> what are the characteristics of your "delayed update" approach? 

IMO, similar to that of a set of learning bridges. I want to make sure 
that an rbridge campus doesn't flood broadcasts [to discover new, 
otherwise silent nodes] into its access links just to reduce broadcasts 
internally.

> they both have pros and cons. I think it needs to be cleared before you guys 

I agree that however new nodes are discovered - via probing, snooping 
source MAC addresses, or peeking into ARP queries/replies - that the 
impact of these changes on the routing need to be considered, including 
the impact of aggregation and hysteresis of the routing updates.

> are so good solution for scalability. rbridge needs a third approach.

There are three current approaches that are not necessarily mutually 
exclusive, and all the pros and cons of each need to be addressed:

	- probing
	- snooping MAC sources (like current learning bridges)
	- snooping ARP content

Is there a fourth approach that this list does not cover?

> that have to be executed in control plane. the overhead can not be compared.

MAC learning also updates the spanning tree, which can be a complex 
control-plane procedure, and that is the correlary part of a learning 
bridge to the routing protocol updates.

> it requires ARP snooping by intermediate nodes.

I don't think anyone else has proposed manipulating ARP; that might or 
might not be 'on the table'.

> path length the message has traversed. 

ARPs are broadcast ;-) That's a lot of work...

> is accepted finally and propagate network.

Why are you using ARP for route distribution? Rbridge is intended (IMO) 
to see how we can use existing routing protocols inside. If there is a 
new one, it needs to be described in more detail than just an email, and 
proposed to the group as an alternative to existing routing...

> This routing method has been proven by simulation and published in 

Citations would help ;-) As would an ID proposing it as a standard, if 
it is being considered in this context.

> It will effectively reduce broadcast storm and help to improve security. 

Those two assertions don't necessarily relate to each other... ;-)

> people will see rbridge just as another pbridge.

Overall, it seems like you have a proposal for an alternative for how 
routing is done inside an rbridge. You need to document it as a protocol 
spec, and see what people think of it. It would be useful to consider 
how legacy systems will be supported (e.g., legacy bridges inside an 
rbridge campus!), as well as the pros and cons of the approach in your 
writeup. I look forward to evaluating the draft when it is available.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20050318/e774b674/signature.bin

Date: Fri, 18 Mar 2005 07:13:59 -0800
From: Joe Touch <[email-masked]>
To: "CHO, JAI HYUNG" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] End station discovery/liveness detection
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 11660

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigFC7464FF9C6C389000372FE1
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

> what are the characteristics of your "delayed update" approach? 

IMO, similar to that of a set of learning bridges. I want to make sure 
that an rbridge campus doesn't flood broadcasts [to discover new, 
otherwise silent nodes] into its access links just to reduce broadcasts 
internally.

> they both have pros and cons. I think it needs to be cleared before you guys 

I agree that however new nodes are discovered - via probing, snooping 
source MAC addresses, or peeking into ARP queries/replies - that the 
impact of these changes on the routing need to be considered, including 
the impact of aggregation and hysteresis of the routing updates.

> are so good solution for scalability. rbridge needs a third approach.

There are three current approaches that are not necessarily mutually 
exclusive, and all the pros and cons of each need to be addressed:

	- probing
	- snooping MAC sources (like current learning bridges)
	- snooping ARP content

Is there a fourth approach that this list does not cover?

> that have to be executed in control plane. the overhead can not be compared.

MAC learning also updates the spanning tree, which can be a complex 
control-plane procedure, and that is the correlary part of a learning 
bridge to the routing protocol updates.

> it requires ARP snooping by intermediate nodes.

I don't think anyone else has proposed manipulating ARP; that might or 
might not be 'on the table'.

> path length the message has traversed. 

ARPs are broadcast ;-) That's a lot of work...

> is accepted finally and propagate network.

Why are you using ARP for route distribution? Rbridge is intended (IMO) 
to see how we can use existing routing protocols inside. If there is a 
new one, it needs to be described in more detail than just an email, and 
proposed to the group as an alternative to existing routing...

> This routing method has been proven by simulation and published in 

Citations would help ;-) As would an ID proposing it as a standard, if 
it is being considered in this context.

> It will effectively reduce broadcast storm and help to improve security. 

Those two assertions don't necessarily relate to each other... ;-)

> people will see rbridge just as another pbridge.

Overall, it seems like you have a proposal for an alternative for how 
routing is done inside an rbridge. You need to document it as a protocol 
spec, and see what people think of it. It would be useful to consider 
how legacy systems will be supported (e.g., legacy bridges inside an 
rbridge campus!), as well as the pros and cons of the approach in your 
writeup. I look forward to evaluating the draft when it is available.

Joe

--------------enigFC7464FF9C6C389000372FE1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigFC7464FF9C6C389000372FE1--

priority: normal
From: "CHO, JAI HYUNG" <[email-masked]>
To: <[email-masked]>
Cc: 
Date: Fri, 18 Mar 2005 17:45:32 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Content-Class: urn:content-classes:message
Importance: normal
Subject: Re: [rbridge] End station discovery/liveness detection
Reply-To: "CHO, JAI HYUNG" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 8808

Dear Joe Touch,

so, my question is same. 

Good question !!! 

                       ARP(m=3) 
                [S1]-----------[S2] 
                  |                 | 

 
Thank you
 
Regards

Dr. Jaihyung Cho
ETRI, Korea
phone :       042) 860-5514
oversea: +82-42-860-5514
fax:         +82-42-861-5550 

Date: Thu, 17 Mar 2005 08:26:00 -0800
From: Joe Touch <[email-masked]>
To: "CHO, JAI HYUNG" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] End station discovery/liveness detection
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 17214

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigC303B6F71839B74E484DD819
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

CHO, JAI HYUNG wrote:
>  
> 
> Dear Joe Touch,
> 
> 
>>>>>1) ARP is sent actively to probe an inactive terminal and obtain MAC info, 
>>>>>right? 
>>>>
>>>>No. Not in general, and I haven't heard that proposed as a way to make 
>>>>the rbridge work.
>  
> oh, didn't you? 
> In chapter 4 section C of Radia's Infocom paper, it is clearly 
> stated that:
>  
> ". the DR (rbridge) can periodically issue ARP queries for D (destination), 
> to reassure itself that D still resides on its LAN"
>  
> maybe you wrote the rbridge draft without reading Radia's paper.
>  
> Also, if you read past thread of this discussion, you'll see Radia, Alex, 
> Russ are all discussing about some probing method.

So far I have heard it as a way to optimize rbridge's routing info, but 
not required to make it work. I should have been more specific with my 
statement, agreed.

Even so, I disagree that it is useful for optimization. Not all authors 
agree on every word of a doc sometimes ;-)

>>>>New MAC addresses are noticed by seeing packets enter the rbridge with 
>>>>new (MAC) source addresses, the same as with a learning bridge. 
>>>
>>>see following case; 
>>>
>>>+----------+ 
>>>|   rbridge   |---[Hub1]----[Hub2]----[ 100s of terminals ] 
>>>+----------+ 
>>>
>>>suppose the rbridge once learned MAC info of 100s of terminals. 
>>>rbidge will periodically advertise location of 100s of terminals 
>>>using link-status protocol. after a while, some are switched off, 
>>>some are hibernated and some are just busy on local work. 
>>>the rbridge must advertise aliveness of active terminals. 
>>>how does rbridge know which terminal is active and which is dead? 
>>
>>It knows because it hears traffic FROM those terminals. It times-out 
>>idle entries, just like a learning bridge.
> 
> oh.I see.. 

> Is it your own opinion, or a conclusion reached by consensus? 

We haven't started the work of the WG. It is my opinion, but based on 
work we did in PILC where we did examine this issue in detail, and 
conclusion was reached by consensus. It may or may not apply here, but 
that is for the WG to decide.

> In my company, my terminal is attached in a VLAN that includes 
> about 100 terminals. When I capture Ethernet frames, I see nearly 
> 2 ~ 3 ARP broadcasts at every second. 
> 
> If 100 terminals produce 2~3 ARPs per second, a rbridged network 
> of 50,000 terminals will cause 1000 ~ 1500 link-status update 
> and route calculation at every second.

As (far) above, that amount of update isn't required; the routing tables 
can be updated quickly, but not triggered per se by every single MAC change.

Further, just because some party loses or times-out an ARP cache and 
does an ARP broadcast does _not_ mean that the related MAC addresses 
(source or dest) have moved. The routing table needs to be updated only 
if something moves.

> Of course all rbridges 
> must perform the calculation simultaneously. In fact, the overhead 
> is doubled if the link-status info is fed from destination rbridge 
> by ARP reply, and from source rbridge by L2 frame.
> 
> I am wondering what system can handle this processing overhead. 
> This is the scalability issue that Alex has pointed out at the beginning 
> of this mail thread, and people suggested methods to reduce this 
> overhead, such as end-station probing or reporting.
> I think dynamic state update without optimization is no better idea.

See above - I don't think the situtation you describe causes problems.

>>>>>Why does rbridge try to 
>>>>>build up MAC table although it is possible that the MAC info can be 
>>>>>installed on bridges on-demand when ARP is actually exchanged between source 
>>>>
>>>>and 
>>>>
>>>>>destination ? Of course if we use ARP for this purpose instead of link-status 
>>>>
>>>>protocol. 
>>>>
>>>>I think of it the way you do - on-demand, the way learning bridges work. 
>>>
>>>and then what happen? why did you stop thinking of this method. 
>>>what problem did you face? I have a solution. I want to share my idea. 
>>
>>My understanding is that an rbridge will learn the ingress of a MAC 
>>address when it sees packets enter that ingress with that MAC address as 
>>an L2 packet source address. 
>>
>>The arrival of the address means we learn it and propagate its routing 
>>info. End stations need not use ARP to learn an address (it may be 
>>loaded out-of-band, e.g.), so once we know where to send a MAC address 
>>we should expect to handle it at -any- ingress, not just the one that 
>>sent (or did not send) an ARP.
> 

---

Alternately if you install the source MAC along the broadcast tree when 
the first ARP goes through (leaving breadcrumbs to get home), then the 
return ARP will go back same broadcast tree. So all routes will be 
installed on the same broadcast tree.

That's basically how a learning bridge works, and what we're trying to 
avoid - use of only a single broadcast tree for all traffic.

> there's no need for MAC learning, no need for propagation of MAC info. 
> in summary, ARP is used for distribution of MAC info as well as for 
> shortest path establishment in a integrated, lightweight method. 
> isn't it simple than broadcasting link-status update separately?
> 
> you may read http://www.ietf.org/internet-drafts/draft-jaihyung-ccamp-arpsignal- 
> 00.txt 
> for detail of my idea, although the draft wasn't written for rbridge in mind. 
> I'm thinking to submit edited version for rbridge, if people are not so negative 
> on my idea.

It doesn't appear to help, because it appears to behave like existing 
learning bridges... (or please correct the above conclusions).

  >>>>>"Divide local network by IP subnets. Pass ARP between rbridges in 
a way
>>>>>that prevent looping and reduce unnecessary flooding and via shortest path. 
>>>>>The shortest -path, I mean, is according to subnets and other information. 
>>>>
>>>>That's not an rbridge; that's a set of routers. 
>>>
>>>what's your criteria of distinguishing hybrid switch and router? 
>>>for me, a router requires IP processing function in data forwarder, whereas, 
>>>hybrid switch is a machine providing IP equivalent service using L2 hardware. 
>>
>>L2 - forwards based on L2 information 
>>L3 - forwards based on L3 information 
>>
>>There are hybrids, but an rbridge from the _outside_ looks like (IMO) an 
>>L2 device, not a hybrid. Internally it makes use of L3-derived routing 
>>protocols for distributing encapsulation information and forwarding entries. 
> 
> I see no difference of your definition and my concept of hybrid switch 
> except the *encapsulation* part that you still insist.

Agreed.

> my proposal makes use of L3 information (i.e. IP subnet) internally configured 
> in control plane. the subnet info is used for controlling range of ARP 
> broadcast and for imposing policy between group of terminals. 
> it is in effect a L2 forwarding machine because MAC forwarding state 
> is stored on data plane using ARP.

Agreed, and I disagree that this is either what an rbridge is or what 
would be useful.

> this is just a different way of using ARP than your design of rbridge. 
> you have no reason to call your rbridge is the only pure hybrid and others are 
> kind of router solution.

The encapsulation part _is_ the reason.

>>>the concept of employing IP aware protocol over L2 hardware is same 
>>>as rbridge and my proposal. read the above text carefully. I just talked ARP, 
>>>shortest-path and subnet. Isn't that a bit different way of using ARP 
>>>compared to rbridge that you drafted? and you spell it router.... 
>>
>>It is different, and not what I think we're talking about. 
> 
> yes, it is not the way you are thinking. 
> however the objective and scope of work are exactly matching to 
> what is described in drafted charter, except the *encapsulation* part.

Definitely agreed.

>>>what defined in RFC2644 is service termination of L2 at routers. 
>>>I am sure some objective of rbridge is to replace the role of 
>>>routers, 
>>
>>It is to replace the role of existing bridges. It is not to provide L3 
>>services. 
> 
> do you mean that rbridge will never replace in-campus routers? 

I think it will replace them only where they are used relucantly because 
a bridge system didn't scale. I don't think they will replace all uses 
of routers.

> note that routers are heavily used in campus network. 
> typical configuration of campus network are mesh or ring of 
> local backbone routers and there are only one or two levels of bridged 
> trees under the backbone cloud. there's not much room for routing at the 
> bridged trees, because most traffic go through local backbone. 
> this typical configuration is basically same in metro-Ethernet. 
> hence, not much practical benefit is expected from 
> replacing the low-cost bridges to rbridges. 
> furthermore, unless you remove the local routers, you'll not 
> achieve the advantage of no-renumbering in migration. 

Agreed. In that case, we want to replace the routers. But it is because 
we could have tried to use bridges but they would have had spanning 
trees that slowly converted.

> I think right target of rbridge is local backbone routers 
> and metro-backbone L3 switches.

OK - I agree with that too, but I don't agree that we will expect L3 
services at rbridges.

>>>I am wondering, somehow, you think one whole rbridge domain 
>>>should be one IP subnet. 
>>
>>It might have overlapping non-interacting IP subnets (vlans), but yes, 
>>IMO IP subnets map to L2 nets. 
> 
> .......
>  
> 
>>>IEEE recently works on Provider Bridge 
>>>standard (802.1ad) of which the main objective is to replace L3 switches 
>>>to bridges. Main idea of pbridge is providing VLAN interconnectivity 
>>>between customer network using bridged provider network. 
>>>
>>>I think IETF rbridge will eventually compete with IEEE pbridge in market. 
>>>In that case, I am wondering what grouping 
>>>method you will propose to be distinguished from IEEE pbridge. 
>>
>>I am unable to access that spec; what little information indicates that 
>>pbridge is more like auto-managed vlans, and does not address the need 
>>for a replacement for spanning tree inside a set of bridges (esp. in 
>>being backward compatible with such). 
> 

> "......  this standard specifies the operation of *MAC Bridges* 
> that support VLANs. To this end it ....  to enable a Service Provider 
> to use a Virtual Bridged Local Area Network to provide separate 
> instances of the 802 MAC Service, ...., to multiple independent customers, 
> in a manner that does not require cooperation among the users and that 
> requires a minimum of cooperation between the users and the provider 
> of MAC service, this standard further specifies the operation of 
> Provider Bridges. ..."
> 
> IEEE does not replace spanning tree, but uses it more structured, 
> systematic and efficient way.  multiple-spanning trees inside the provider
> network provides near-shortest paths between customer networks. 
> furthermore, the scale of pbridged network can be up to metro-Etherent size. 
> I think it is necessary for TRILL people keep in mind of 802.1ad closely.

So using separate spanning trees for different VLANs is what makes 
802.1ad scale? But you need to use L3 routers to get between VLANs. This 
doesn't help a single L2 scale, it just means you can share hardware. 
This doesn't help what an rbridge is trying to do.

> if you rely on routers for this function, rbridge will never make 
> any bit of market share. because network managers will still be using routers. 

If that is what they are using routers for, I agree. I don't agree that 
is the case of router use rbridges are trying to address.

> you may think you can do it using VLAN, however, you'll see 
> lots of enemy once you start touching VLAN because 
> VLAN function and space is seriously limited, but many people 
> want to do lots of different things using VLAN.
> 
> on the contrary, IETF has developed far scalable and flexible 
> concept of IP hierarchy. I don't understand why you don't 
> make use of this superior tool of IP subnetting for rbridge. 

Because it's not an rbridge anymore; it's a router.

> IP subnet is friendly to router. it can be used for controlling 
> range of broadcast. it is a convenient tool for imposing internal policy and security.

And it doesn't support mobility nearly as well as a single L2 subnet.

> BTW, you may think 10,000 terminals is a good scale limit of rbridge, 
> however, it is no good figure at all. 
> one, single broadcast network of 10,000 terminal is unacceptable thing 
> to network managers. 

I disagree.

Joe

--------------enigC303B6F71839B74E484DD819
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigC303B6F71839B74E484DD819--

Date: Thu, 17 Mar 2005 07:55:50 -0800
From: Joe Touch <[email-masked]>
To: =?EUC-KR?B?wbbA58f8?= <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] text on hop-count in updated charter
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 9417

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7718E711C259045F2679FCB2
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 8bit

?????? wrote:
>  
> Dear Joe Touch,
>  
>  >
>  >>>With this regard, I would like to ask what are the service objectives
>  >>>of rbridge given to end-users? It seems rbridge lacks commercially
>  >>>meaningful benefits to end-users, such as QoS, authentication,
>  >>>metering & charging, etc.
>  >>>How will rbridge protect guaranteed flows from abusive user or
>  >>>masquerading of service class?
>  >>
>  >>Please begin by explaining how any of these are currently provided by
>  >>arbitrary link layers.
>  >
>  >> QoS service is the prime requisite in any of upcoming network.
>  >> RFC2814, 2815, 2816 proposes a RSVP application over 802 networks
>  >> (i.e. bridged local network) for resource control.
>  >> Although not widely deployed, some company
>  >> supports use of RSVP in local network. If you are interested, you 
> may read
>  >>
>  >> 
> http://www.ietf.org/internet-drafts/draft-jaihyung-ccamp-lseframework-00.txt
>  >> 
> http://www.ietf.org/internet-drafts/draft-jaihyung-ccamp-arpsignal-00.txt
>  >>
>  >> What rbridge lacks is the QoS service.
>  >
>  >These are _proposed_ applications of RSVP over 802, as well as _draft_
>  >documents, so IMO bridges lack this service right now.
>  
> The RFCs are proposed standard for resource control over bridged network.
> RFC2816 has QoS mechanism on bridge, IEEE pbridge also has class of service,
> but rbridge doesn't have such concept of service differentiation.
> simple item to add when people compare related works on bridge QoS??.

RFC2816 is an informational document, not a proposed standard.

Further, by using L3-type routing protocols, it may be possible to
support QoS inside an rbridge system as easily ;-) as it can be
supported in the rest of the Internet. What would be needed would be a
way to translate L2 QoS signalling at the rbridge edge to L3 QoS
signalling inside, and that should be in scope for this WG, though
perhaps not an initial target.

>  >> If rbridge is aiming the place of
>  >> next-generation bridge to replace legacy bridges, rbridge must
>  >> include such industry requirement whether this group likes it or not.
>  >
>  >I don't see a screaming industry requirement for this at the 802 level,
>  >where overprovisioning is the norm. Note that rbridges would have much
>  >higher internal bandwidth, because they can use multiple internal paths
>  >rather than just a single spanning tree, so amplify the overprovisioning
>  >that is already in use.
> 
> have you ever talked with actual industry?
> how much over-provisioning do you think you can *guarantee* reliable
> commercial service via campus network.

You need to review the rbridge document. We use the term 'campus' to
describe a cluster of rbridges. The term has nothing to do with
university deployment.

And as to what industry is doing, where can I _buy_ QoS-based service? I
can buy provisioned service, but not on-the-fly bandwidth reservation.

> the correct answer is NOT AT ALL, because you have NO such mechanism.
> in future network, people will receive TV, voice and data service via
> single integrated network.

This is a future I have been promised since 1983, when it was promised
by ISDN. Then in 1988, it was promised by BISDN/ATM. Then in 1994 it was
promised by RSVP.

When I _see_ it, I will believe it. Until then, it will remain a promise.

> ISPs will charge by usage per service.
> it is obvious that network builders will choose equipment that has
> at least a QoS solution. you can't sell anything without QoS in future 
> market.
> over-provisioning is simply not an answer to market.

It has been so far, and it is where telecom markets evolve - towards
flat-rate, because it's easier to overprovision than to reserve,
enforce, account, and charge. But that debate has been going on for 20
years (or more), and we don't need to have that here.

Rbridges support QoS as easily (or not) as any L3 system.

>  >> Otherwise, IEEE pbridge or other alternatives will be favored by market.
>  >> Contrast to original scope of work on campus network, I think rbridge
>  >> is more meaningful to metro-Ethernet. There's clear need for L2 
> solution.
>  >> rbridge may help ISPs reducing CAPEX if it is cheaper than L3 switches.
>  >> rbridge may also help to reduce OPEX if management is simple.
>  >
>  >The primary reason to use an rbridge vs. an L3 device is to avoid
>  >renumbering while moving. If that isn't a goal, IMO, an L3 device is
>  >more useful because routing tables can be more easily partitioned and
>  >broadcasts avoided.
> 
> do you think network builders will replace L3 switch to rbridge
> because in-campus mobility in rbridged network is better than
> any mobility solution implemented in L3 product?

Yes.

> you haven't proposed any mobility mechanism that can convince
> people rbridge mobility is superior to mobile IP.

Moving ports on a single L2 subnet doesn't require L3 'mobility',
because as far as L3 is concerned the device hasn't moved. Using a
mobility mechanism that requires _no_ L3 support is preferred to using
(not widely-supported) L3 mobility mechanisms.

This is why large L2 subnets are being used, esp. for groups of mobile
users (wireless within a city, or on a university or corporate campus).

> The last factor determining market is always money.
> If it is not cheaper, it can't replace something.
> but if it doesn't have a function, it may still replace if it is cheaper.

Agreed, but it is not clear that issue applies here. The additional
capabilities needed for an rbridge vs conventional learning bridge are
similar to the difference between learning bridges and hubs, where a
cost differential still exists, but is both small and insufficient
affect user's choice for the additional capability a learning bridge
provides. I think we hope the same for rbridges vs. learning bridges.

>  >> It will
>  >> give great profit to ISP if rbridge has a capability to provide QoS
>  >> service and charge per usage.
>  >
>  >Because they're currently providing that service and they want it to
>  >scale? What I see is ISPs not offering QoS - but not because bridges
>  >don't support it.
> 
> you keep thinking rbridge can only be bridge, but I keep saying
> rbridge must be campus backbone machine.
> you keep saying rbridge doesn't need QoS because bridges don't have.
> however I keep saying rbridge need QoS because backbone routers
> have QoS.
> and I say that if rbridge can't replace backbone routers, no market at all.

And I disagree. I think rbridges replace sets of bridges, with better
capability as a result. When they replace routers, it is because routers
were required to interconnect sets of bridges, not because routers were
desired to support QoS.

>  >> The requirements in provider network
>  >> are a lot different than campus network. It needs to be defined in this
>  >> group prior to work.
>  >
>  >I don't agree that L2 systems run as a service need fundamentally
>  >different capabilites than L2 systems run by their user organization.
> 
> read any list of functional requirements written by private organization
> and commercial providers. they are a lot different.
> it is unfortunate I can't show you evidence because most of documents
> are confidential. I hope someone in this mailing list may show some
> example.
>
>  >>>Further, I haven't seen anyone else mention circuits here. Circuits are
>  >>>not used for switching packets to the endsystem (maybe that was their
>  >>>intent, but they're used more in the core for provisioning). Rbridges
>  >>>work more at the endsystem, where bridges work. As such, I doubt
>  >>>circuits will be either appropriate or useful anyway.
>  >>
>  >> I believe by now, you will notice what *virtual circuit* technology
>  >> I am trying to say. The circuit I referred is a dynamic (on-demand)
>  >> frame transmission path established across bridged network
>  >> using an interactive signaling between two communicating party.
>  >> In bridged networks,
>  >
>  >Yes - that was what ATM was supposed to be, and ATM is basically (IMO)
>  >dead. I don't believe it makes sense to consider MPLS for on-demand E2E
>  >circuits, but rather for aggregate provisioning.
>  >
>  >Again, I haven't seen anyone else mention the use of circuits in an
>  >rbridge system. Even _if_ there were interest, at best an rbridge system
>  >would need to support circuits AND conventional L3 routing in its 
> interior.
>  >
>  >Joe
>  
> because no-one in rbridge has talked about QoS.

QoS does not require circuits. If it does, then there would be no L3
support for QoS over non-circuit technologies - such as 802.

If we want to talk about QoS, let's do that. But I still don't see a
reason to talk about circuits.

Joe

--------------enig7718E711C259045F2679FCB2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig7718E711C259045F2679FCB2--

Priority: normal
From: =?ks_c_5601-1987?B?wbbA58f8?= <[email-masked]>
To: <[email-masked]>
Cc: 
Date: Thu, 17 Mar 2005 17:09:34 +0900
Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCBCY06x4rz6utC8rsbALCC047Tn?=
Content-Class: urn:content-classes:message
Importance: normal
Subject: Re: [rbridge] text on hop-count in updated charter
Reply-To: =?ks_c_5601-1987?B?wbbA58f8?= <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 10891

This is a multi-part message in MIME format.

------=_NextPart_000_11FB6_01C52B14.17CF0270
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

------=_NextPart_000_11FB6_01C52B14.17CF0270
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

------=_NextPart_000_11FB6_01C52B14.17CF0270--

priority: normal
From: "CHO, JAI HYUNG" <[email-masked]>
To: <[email-masked]>
Cc: 
Date: Thu, 17 Mar 2005 17:06:36 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Content-Class: urn:content-classes:message
Importance: normal
Subject: Re: [rbridge] End station discovery/liveness detection
Reply-To: "CHO, JAI HYUNG" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 11642

Dear Joe Touch,

>>>>1) ARP is sent actively to probe an inactive terminal and obtain MAC info, 
>>>>right? 
>>> 
>>>No. Not in general, and I haven't heard that proposed as a way to make 
>>>the rbridge work.
 
oh, didn't you? 
In chapter 4 section C of Radia's Infocom paper, it is clearly 
stated that:
 
". the DR (rbridge) can periodically issue ARP queries for D (destination), 
to reassure itself that D still resides on its LAN"
 
maybe you wrote the rbridge draft without reading Radia's paper.
 
Also, if you read past thread of this discussion, you'll see Radia, Alex, 
Russ are all discussing about some probing method.

>>>New MAC addresses are noticed by seeing packets enter the rbridge with 
>>>new (MAC) source addresses, the same as with a learning bridge. 
>> 
>> see following case; 
>> 
>> +----------+ 
>> |   rbridge   |---[Hub1]----[Hub2]----[ 100s of terminals ] 
>> +----------+ 
>> 
>> suppose the rbridge once learned MAC info of 100s of terminals. 
>> rbidge will periodically advertise location of 100s of terminals 
>> using link-status protocol. after a while, some are switched off, 
>> some are hibernated and some are just busy on local work. 
>> the rbridge must advertise aliveness of active terminals. 
>> how does rbridge know which terminal is active and which is dead? 
> 
>It knows because it hears traffic FROM those terminals. It times-out 
>idle entries, just like a learning bridge.

oh.I see.. 

Is it your own opinion, or a conclusion reached by consensus? 
Reading past discussion on this mail thread, it seems other 
people have little bit different idea.

In my company, my terminal is attached in a VLAN that includes 
about 100 terminals. When I capture Ethernet frames, I see nearly 
2 ~ 3 ARP broadcasts at every second. 

If 100 terminals produce 2~3 ARPs per second, a rbridged network 
of 50,000 terminals will cause 1000 ~ 1500 link-status update 
and route calculation at every second. Of course all rbridges 
must perform the calculation simultaneously. In fact, the overhead 
is doubled if the link-status info is fed from destination rbridge 
by ARP reply, and from source rbridge by L2 frame.

I am wondering what system can handle this processing overhead. 
This is the scalability issue that Alex has pointed out at the beginning 
of this mail thread, and people suggested methods to reduce this 
overhead, such as end-station probing or reporting.
I think dynamic state update without optimization is no better idea.

>>>>Why does rbridge try to 
>>>>build up MAC table although it is possible that the MAC info can be 
>>>>installed on bridges on-demand when ARP is actually exchanged between source 
>>>and 
>>>>destination ? Of course if we use ARP for this purpose instead of link-status 
>>>protocol. 
>>> 
>>>I think of it the way you do - on-demand, the way learning bridges work. 
>> 
>> and then what happen? why did you stop thinking of this method. 
>> what problem did you face? I have a solution. I want to share my idea. 
> 
>My understanding is that an rbridge will learn the ingress of a MAC 
>address when it sees packets enter that ingress with that MAC address as 
>an L2 packet source address. 
> 
>The arrival of the address means we learn it and propagate its routing 
>info. End stations need not use ARP to learn an address (it may be 
>loaded out-of-band, e.g.), so once we know where to send a MAC address 
>we should expect to handle it at -any- ingress, not just the one that 
>sent (or did not send) an ARP.

when the destination terminal replies ARP reply, the rbridges install MAC 
forwarding state using the information contained in ARP message. 
the rbridge passes the ARP reply to upstream node, as a result, MAC forwarding 
path is established between source and destination terminal. 
there's no need for MAC learning, no need for propagation of MAC info. 
in summary, ARP is used for distribution of MAC info as well as for 
shortest path establishment in a integrated, lightweight method. 
isn't it simple than broadcasting link-status update separately?

you may read http://www.ietf.org/internet-drafts/draft-jaihyung-ccamp-arpsignal- 
00.txt 
for detail of my idea, although the draft wasn't written for rbridge in mind. 
I'm thinking to submit edited version for rbridge, if people are not so negative 
on my idea.

>>>>"Divide local network by IP subnets. Pass ARP between rbridges in a way 
>>>>that prevent looping and reduce unnecessary flooding and via shortest path. 
>>>>The shortest -path, I mean, is according to subnets and other information. 
>>> 
>>>That's not an rbridge; that's a set of routers. 
>> 
>> what's your criteria of distinguishing hybrid switch and router? 
>> for me, a router requires IP processing function in data forwarder, whereas, 
>> hybrid switch is a machine providing IP equivalent service using L2 hardware. 
> 
>L2 - forwards based on L2 information 
>L3 - forwards based on L3 information 
> 
>There are hybrids, but an rbridge from the _outside_ looks like (IMO) an 
>L2 device, not a hybrid. Internally it makes use of L3-derived routing 
>protocols for distributing encapsulation information and forwarding entries. 
>

I see no difference of your definition and my concept of hybrid switch 
except the *encapsulation* part that you still insist.

my proposal makes use of L3 information (i.e. IP subnet) internally configured 
in control plane. the subnet info is used for controlling range of ARP 
broadcast and for imposing policy between group of terminals. 
it is in effect a L2 forwarding machine because MAC forwarding state 
is stored on data plane using ARP.

this is just a different way of using ARP than your design of rbridge. 
you have no reason to call your rbridge is the only pure hybrid and others are 
kind of router solution.

>> the concept of employing IP aware protocol over L2 hardware is same 
>> as rbridge and my proposal. read the above text carefully. I just talked ARP, 
>> shortest-path and subnet. Isn't that a bit different way of using ARP 
>> compared to rbridge that you drafted? and you spell it router.... 
> 
>It is different, and not what I think we're talking about. 
>

yes, it is not the way you are thinking. 
however the objective and scope of work are exactly matching to 
what is described in drafted charter, except the *encapsulation* part.

> 
>> what defined in RFC2644 is service termination of L2 at routers. 
>> I am sure some objective of rbridge is to replace the role of 
>> routers, 
> 
>It is to replace the role of existing bridges. It is not to provide L3 
>services. 
>

do you mean that rbridge will never replace in-campus routers? 
note that routers are heavily used in campus network. 
typical configuration of campus network are mesh or ring of 
local backbone routers and there are only one or two levels of bridged 
trees under the backbone cloud. there's not much room for routing at the 
bridged trees, because most traffic go through local backbone. 
this typical configuration is basically same in metro-Ethernet. 
hence, not much practical benefit is expected from 
replacing the low-cost bridges to rbridges. 
furthermore, unless you remove the local routers, you'll not 
achieve the advantage of no-renumbering in migration. 
I think right target of rbridge is local backbone routers 
and metro-backbone L3 switches.

>> I am wondering, somehow, you think one whole rbridge domain 
>> should be one IP subnet. 
> 
>It might have overlapping non-interacting IP subnets (vlans), but yes, 
>IMO IP subnets map to L2 nets. 
.......
 
>> IEEE recently works on Provider Bridge 
>> standard (802.1ad) of which the main objective is to replace L3 switches 
>> to bridges. Main idea of pbridge is providing VLAN interconnectivity 
>> between customer network using bridged provider network. 
>> 
>> I think IETF rbridge will eventually compete with IEEE pbridge in market. 
>> In that case, I am wondering what grouping 
>> method you will propose to be distinguished from IEEE pbridge. 
> 
>I am unable to access that spec; what little information indicates that 
>pbridge is more like auto-managed vlans, and does not address the need 
>for a replacement for spanning tree inside a set of bridges (esp. in 
>being backward compatible with such). 
>

"......  this standard specifies the operation of *MAC Bridges* 
that support VLANs. To this end it ....  to enable a Service Provider 
to use a Virtual Bridged Local Area Network to provide separate 
instances of the 802 MAC Service, ...., to multiple independent customers, 
in a manner that does not require cooperation among the users and that 
requires a minimum of cooperation between the users and the provider 
of MAC service, this standard further specifies the operation of 
Provider Bridges. ..."

IEEE does not replace spanning tree, but uses it more structured, 
systematic and efficient way. multiple-spanning trees inside the provider 
network provides near-shortest paths between customer networks. 
furthermore, the scale of pbridged network can be up to metro-Etherent size. 
I think it is necessary for TRILL people keep in mind of 802.1ad closely.

if you rely on routers for this function, rbridge will never make 
any bit of market share. because network managers will still be using routers. 
you may think you can do it using VLAN, however, you'll see 
lots of enemy once you start touching VLAN because 
VLAN function and space is seriously limited, but many people 
want to do lots of different things using VLAN.

on the contrary, IETF has developed far scalable and flexible 
concept of IP hierarchy. I don't understand why you don't 
make use of this superior tool of IP subnetting for rbridge. 
IP subnet is friendly to router. it can be used for controlling 
range of broadcast. it is a convenient tool for imposing internal policy and security.

BTW, you may think 10,000 terminals is a good scale limit of rbridge, 
however, it is no good figure at all. 
one, single broadcast network of 10,000 terminal is unacceptable thing 
to network managers. 
two, IEEE pbridge will scale better. 
three, processing overhead at that scale will seriously be heavy.

Dr. Jaihyung Cho
ETRI, Korea
phone :       042) 860-5514
oversea: +82-42-860-5514
fax:         +82-42-861-5550 

Date: Tue, 15 Mar 2005 06:39:41 -0800
From: Joe Touch <[email-masked]>
To: "CHO, JAI HYUNG" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] End station discovery/liveness detection
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 9388

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigC40DC071B2E2A5D77FBD94C9
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

CHO, JAI HYUNG wrote:
> Dear Joe,
>  
> 
> 
>>CHO, JAI HYUNG wrote:
> 
> 
>>>1) ARP is sent actively to probe an inactive terminal and obtain MAC info, 
>>>right? 
>>
>>No. Not in general, and I haven't heard that proposed as a way to make 
>>the rbridge work. 
>>New MAC addresses are noticed by seeing packets enter the rbridge with 
>>new (MAC) source addresses, the same as with a learning bridge.
> 
>  
> see following case;
>  
> +----------+ 
> |rbridge|---[Hub1]----[Hub2]----[ 100s of terminals ] 
> +----------+
>  
> suppose the rbridge once learned MAC info of 100s of terminals. 
> rbidge will periodically advertise location of 100s of terminals 
> using link-status protocol. after a while, some are switched off, 
> some are hibernated and some are just busy on local work. 
> the rbridge must advertise aliveness of active terminals. 
> how does rbridge know which terminal is active and which is dead? 

It knows because it hears traffic FROM those terminals. It times-out 
idle entries, just like a learning bridge.

> in this case, monitoring data frame or sensing local link doesn't help. 

See above - that's what makes time-outs work.

> you may not use active probing using ARP, however 
> you will need substitute method for rbridge's probing or 
> periodical reporting of active terminals, other than just MAC learning.

I agree that active probing doesn't work,  but neither does your 
assumption of hard state. You need soft state - state which times out.

>>>3) The distributed MAC information is used for passing datagram to actual 
>>>destination. By the way, in most IP terminals, the first datagram sent to destination 
>>>terminal is, again...., ARP !!!! 
>>
>>ARP is not sent to the destination; it is sent to broadcast.
> 
> In the context above, "sent" means being transferred to 
> destination by any means, including broadcasting or multicasting or 
> any guided transfer method. 
> Arguing on syntax hardly helps on technical discussion.

If my terminal sends a broadcast that includes your terminal's IP 
address inside, there is NO information about your MAC address to learn. 
  All the system can learn is my MAC address - which it learns because 
it is the source address of a packet.

When you send the ARP reply, it will contain your MAC address as the 
source of that packet, which is where (and when) it will be learned.

It is sufficient to learn MAC addresses when seeing them as source 
addresses of L2 packets that enter the rbrige system.

>>>- in other words, rbridges must keep up MAC address of all terminals in lookup table 
>>>although the actual number of MAC addresses other terminals need to know is only a 
>>>few of servers. 
>>
>>No, again as above.
> 
> as above of what reference? specific point please. 
> note that even in 802 bridges keep up all MAC addresses in all bridges 
> belong to same broadcast domain. MAC address is not aggregatable. 
> unless some VLAN grouping or IP subnetting is used, rbridges will 
> have the overhead of learning all MAC infos.

The rbridge is going to keep the MAC addresses only of all actively 
speaking terminals. Others will timeout. (i.e., as to the first 
assertion that ARPs are used to probe for a complete list of all 
terminals, your item #1).

>>>- the link-status protocol distributes MAC info which will be anyway known by 
>>>ARP when it is actually necessary by terminal. In other words, rbridge 
>>>uses ARP and link-status protocol to know the information that will be known 
>>>by ARP? 
>>
>>No, again as above.
> 
> also, please be specific.

As I mentioned above in the description of how learning works (even in 
an rbridge), rbridge doesn't care about ARP per se; all it cares about 
is the source MAC address of packets. There is no need to peek at ARP.

>>>Why does rbridge try to 
>>>build up MAC table although it is possible that the MAC info can be 
>>>installed on bridges on-demand when ARP is actually exchanged between source 
>>and 
>>>destination ? Of course if we use ARP for this purpose instead of link-status 
>>protocol. 
>>
>>I think of it the way you do - on-demand, the way learning bridges work.
> 
> and then what happen? why did you stop thinking of this method. 
> what problem did you face? I have a solution. I want to share my idea.

My understanding is that an rbridge will learn the ingress of a MAC 
address when it sees packets enter that ingress with that MAC address as 
an L2 packet source address.

The arrival of the address means we learn it and propagate its routing 
info. End stations need not use ARP to learn an address (it may be 
loaded out-of-band, e.g.), so once we know where to send a MAC address 
we should expect to handle it at -any- ingress, not just the one that 
sent (or did not send) an ARP.

>>>"Divide local network by IP subnets. Pass ARP between rbridges in a way 
>>>that prevent looping and reduce unnecessary flooding and via shortest path. 
>>>The shortest -path, I mean, is according to subnets and other information. 
>>
>>That's not an rbridge; that's a set of routers.
> 
> what's your criteria of distinguishing hybrid switch and router? 
> for me, a router requires IP processing function in data forwarder, whereas, 
> hybrid switch is a machine providing IP equivalent service using L2 hardware.

L2 - forwards based on L2 information

L3 - forwards based on L3 information

There are hybrids, but an rbridge from the _outside_ looks like (IMO) an 
L2 device, not a hybrid. Internally it makes use of L3-derived routing 
protocols for distributing encapsulation information and forwarding entries.

> the concept of employing IP aware protocol over L2 hardware is same 
> as rbridge and my proposal. read the above text carefully. I just talked ARP, 
> shortest-path and subnet. Isn't that a bit different way of using ARP 
> compared to rbridge that you drafted? and you spell it router.... 

It is different, and not what I think we're talking about.

>>>ARP will be flooded in destination subnet anyway. 
>>
>>ARP will not flood beyond the first IP subnet; see RFCs 1812 (don't 
>>forward all 1's broadcast, which is ARP) and RFC 2644 (don't even 
>>forward subnet-directed broadcasts). 
> 
> what defined in RFC2644 is service termination of L2 at routers. 
> I am sure some objective of rbridge is to replace the role of 
> routers,

It is to replace the role of existing bridges. It is not to provide L3 
services.

> and extend the range of L2 service (including ARP) across 
> rbridged LANs.

Yes, all L2 services should be handled across a group of rbridges, just 
as they would be over a group of bridges.

> In that case, RFC2644 is not exactly relevant to 
> new concept of hybrid switch.

Perhaps - that may be an interesting new WG. This WG, IMO, is not 
focused on a device which provides a hybrid external service, however, 
so this is out of scope.

> I am wondering, somehow, you think one whole rbridge domain 
> should be one IP subnet.

It might have overlapping non-interacting IP subnets (vlans), but yes, 
IMO IP subnets map to L2 nets.

> If so. (though not sure of your opinion) 
> as Alex noted, I must point out that the size of one rbridge cloud 
> can be more than 50,000 terminals if rbridge is used in metro-Ethernet.
> Currently metro-Ethernet ISPs use L3 switches 
> to tackle scaling problem. 

Yes - partly because spanning tree doesn't scale.

> IEEE recently works on Provider Bridge 
> standard (802.1ad) of which the main objective is to replace L3 switches 
> to bridges. Main idea of pbridge is providing VLAN interconnectivity 
> between customer network using bridged provider network. 
> 
> I think IETF rbridge will eventually compete with IEEE pbridge in market. 
> In that case, I am wondering what grouping 
> method you will propose to be distinguished from IEEE pbridge. 

I am unable to access that spec; what little information indicates that 
pbridge is more like auto-managed vlans, and does not address the need 
for a replacement for spanning tree inside a set of bridges (esp. in 
being backward compatible with such).

FWIW, IMO rbridges might scale better than bridges, but they will never 
scale as well as routers. That's OK, though - routers require 
renumbering when migrating, and rbridges/bridges do not. There's the 
tradeoff...

Joe

--------------enigC40DC071B2E2A5D77FBD94C9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigC40DC071B2E2A5D77FBD94C9--

Date: Tue, 15 Mar 2005 06:01:53 -0800
From: Joe Touch <[email-masked]>
To: "CHO, JAI HYUNG" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] text on hop-count in updated charter
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5140

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig83FF6321D5DF7EDFB43BC344
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

CHO, JAI HYUNG wrote:
>  
> Dear Joe Touch,
>  
>  
> 
>>>With this regard, I would like to ask what are the service objectives 
>>>of rbridge given to end-users? It seems rbridge lacks commercially 
>>>meaningful benefits to end-users, such as QoS, authentication, 
>>>metering & charging, etc. 
>>>How will rbridge protect guaranteed flows from abusive user or 
>>>masquerading of service class? 
>>
>>Please begin by explaining how any of these are currently provided by 
>>arbitrary link layers.
> 
> QoS service is the prime requisite in any of upcoming network. 
> RFC2814, 2815, 2816 proposes a RSVP application over 802 networks 
> (i.e. bridged local network) for resource control. 
> Although not widely deployed, some company 
> supports use of RSVP in local network. If you are interested, you may read
>  
> http://www.ietf.org/internet-drafts/draft-jaihyung-ccamp-lseframework-00.txt 
> http://www.ietf.org/internet-drafts/draft-jaihyung-ccamp-arpsignal-00.txt
> 
> What rbridge lacks is the QoS service.

These are _proposed_ applications of RSVP over 802, as well as _draft_ 
documents, so IMO bridges lack this service right now.

> If rbridge is aiming the place of 
> next-generation bridge to replace legacy bridges, rbridge must 
> include such industry requirement whether this group likes it or not.

I don't see a screaming industry requirement for this at the 802 level, 
where overprovisioning is the norm. Note that rbridges would have much 
higher internal bandwidth, because they can use multiple internal paths 
rather than just a single spanning tree, so amplify the overprovisioning 
that is already in use.

> Otherwise, IEEE pbridge or other alternatives will be favored by market.
> Contrast to original scope of work on campus network, I think rbridge 
> is more meaningful to metro-Ethernet. There's clear need for L2 solution. 
> rbridge may help ISPs reducing CAPEX if it is cheaper than L3 switches. 
> rbridge may also help to reduce OPEX if management is simple.

The primary reason to use an rbridge vs. an L3 device is to avoid 
renumbering while moving. If that isn't a goal, IMO, an L3 device is 
more useful because routing tables can be more easily partitioned and 
broadcasts avoided.

> It will 
> give great profit to ISP if rbridge has a capability to provide QoS 
> service and charge per usage.

Because they're currently providing that service and they want it to 
scale? What I see is ISPs not offering QoS - but not because bridges 
don't support it.

> The requirements in provider network 
> are a lot different than campus network. It needs to be defined in this 
> group prior to work.

I don't agree that L2 systems run as a service need fundamentally 
different capabilites than L2 systems run by their user organization.

>>Further, I haven't seen anyone else mention circuits here. Circuits are 
>>not used for switching packets to the endsystem (maybe that was their 
>>intent, but they're used more in the core for provisioning). Rbridges 
>>work more at the endsystem, where bridges work. As such, I doubt 
>>circuits will be either appropriate or useful anyway.
>  
> I believe by now, you will notice what *virtual circuit* technology 
> I am trying to say. The circuit I referred is a dynamic (on-demand) 
> frame transmission path established across bridged network 
> using an interactive signaling between two communicating party. 
> In bridged networks,

Yes - that was what ATM was supposed to be, and ATM is basically (IMO) 
dead. I don't believe it makes sense to consider MPLS for on-demand E2E 
circuits, but rather for aggregate provisioning.

Again, I haven't seen anyone else mention the use of circuits in an 
rbridge system. Even _if_ there were interest, at best an rbridge system 
would need to support circuits AND conventional L3 routing in its interior.

Joe

> I believe ARP/ND will be best candidates to 
> use for this purpose. It only differs in the way of using ARP 
> compared to current rbridge design, however, it is a lot 
> versatile because it can be used for QoS, authentication, 
> fast-rerouting, load-sharing and traffic engineering, etc.
>  
> 
> Dr. Jaihyung Cho
> ETRI, Korea
> phone :       042) 860-5514
> oversea: +82-42-860-5514
> fax:         +82-42-861-5550 
> 
> 
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://www.postel.org/mailman/listinfo/rbridge

--------------enig83FF6321D5DF7EDFB43BC344
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig83FF6321D5DF7EDFB43BC344--

priority: normal
From: "CHO, JAI HYUNG" <[email-masked]>
To: <[email-masked]>
Cc: 
Date: Tue, 15 Mar 2005 18:06:03 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Content-Class: urn:content-classes:message
Importance: normal
Subject: Re: [rbridge] text on hop-count in updated charter
Reply-To: "CHO, JAI HYUNG" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2758

Dear Joe Touch,

>> With this regard, I would like to ask what are the service objectives 
>> of rbridge given to end-users? It seems rbridge lacks commercially 
>> meaningful benefits to end-users, such as QoS, authentication, 
>> metering & charging, etc. 
>> How will rbridge protect guaranteed flows from abusive user or 
>> masquerading of service class? 
> 
>Please begin by explaining how any of these are currently provided by 
>arbitrary link layers.
 
QoS service is the prime requisite in any of upcoming network. 
RFC2814, 2815, 2816 proposes a RSVP application over 802 networks 
(i.e. bridged local network) for resource control. 
Although not widely deployed, some company 
supports use of RSVP in local network. If you are interested, you may read
 
http://www.ietf.org/internet-drafts/draft-jaihyung-ccamp-lseframework-00.txt 
http://www.ietf.org/internet-drafts/draft-jaihyung-ccamp-arpsignal-00.txt

What rbridge lacks is the QoS service. If rbridge is aiming the place of 
next-generation bridge to replace legacy bridges, rbridge must 
include such industry requirement whether this group likes it or not. 
Otherwise, IEEE pbridge or other alternatives will be favored by market.
Contrast to original scope of work on campus network, I think rbridge 
is more meaningful to metro-Ethernet. There's clear need for L2 solution. 
rbridge may help ISPs reducing CAPEX if it is cheaper than L3 switches. 
rbridge may also help to reduce OPEX if management is simple. It will 
give great profit to ISP if rbridge has a capability to provide QoS 
service and charge per usage. The requirements in provider network 
are a lot different than campus network. It needs to be defined in this 
group prior to work.

>Further, I haven't seen anyone else mention circuits here. Circuits are 
>not used for switching packets to the endsystem (maybe that was their 
>intent, but they're used more in the core for provisioning). Rbridges 
>work more at the endsystem, where bridges work. As such, I doubt 
>circuits will be either appropriate or useful anyway.
 
I believe by now, you will notice what *virtual circuit* technology 
I am trying to say. The circuit I referred is a dynamic (on-demand) 
frame transmission path established across bridged network 
using an interactive signaling between two communicating party. 
In bridged networks, I believe ARP/ND will be best candidates to 
use for this purpose. It only differs in the way of using ARP 
compared to current rbridge design, however, it is a lot 
versatile because it can be used for QoS, authentication, 
fast-rerouting, load-sharing and traffic engineering, etc.

Dr. Jaihyung Cho
ETRI, Korea
phone :       042) 860-5514
oversea: +82-42-860-5514
fax:         +82-42-861-5550 

priority: normal
From: "CHO, JAI HYUNG" <[email-masked]>
To: <[email-masked]>
Cc: 
Date: Tue, 15 Mar 2005 16:34:13 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Content-Class: urn:content-classes:message
Importance: normal
Subject: Re: [rbridge] End station discovery/liveness detection
Reply-To: "CHO, JAI HYUNG" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5399

Dear Joe,

>CHO, JAI HYUNG wrote:

>> 1) ARP is sent actively to probe an inactive terminal and obtain MAC info, 
>> right? 
> 
>No. Not in general, and I haven't heard that proposed as a way to make 
>the rbridge work. 
>New MAC addresses are noticed by seeing packets enter the rbridge with 
>new (MAC) source addresses, the same as with a learning bridge.
 
see following case;
 
+----------+ 
|rbridge|---[Hub1]----[Hub2]----[ 100s of terminals ] 
+----------+
 
suppose the rbridge once learned MAC info of 100s of terminals. 
rbidge will periodically advertise location of 100s of terminals 
using link-status protocol. after a while, some are switched off, 
some are hibernated and some are just busy on local work. 
the rbridge must advertise aliveness of active terminals. 
how does rbridge know which terminal is active and which is dead? 
in this case, monitoring data frame or sensing local link doesn't help. 
you may not use active probing using ARP, however 
you will need substitute method for rbridge's probing or 
periodical reporting of active terminals, other than just MAC learning.

>> 3) The distributed MAC information is used for passing datagram to actual 
>> destination. By the way, in most IP terminals, the first datagram sent to destination 
>> terminal is, again...., ARP !!!! 
> 
>ARP is not sent to the destination; it is sent to broadcast.
 
In the context above, "sent" means being transferred to 
destination by any means, including broadcasting or multicasting or 
any guided transfer method. 
Arguing on syntax hardly helps on technical discussion.

>> - in other words, rbridges must keep up MAC address of all terminals in lookup table 
>> although the actual number of MAC addresses other terminals need to know is only a 
>> few of servers. 
> 
>No, again as above.

as above of what reference? specific point please. 
note that even in 802 bridges keep up all MAC addresses in all bridges 
belong to same broadcast domain. MAC address is not aggregatable. 
unless some VLAN grouping or IP subnetting is used, rbridges will 
have the overhead of learning all MAC infos.
 
>> - the link-status protocol distributes MAC info which will be anyway known by 
>> ARP when it is actually necessary by terminal. In other words, rbridge 
>> uses ARP and link-status protocol to know the information that will be known 
>> by ARP? 
> 
>No, again as above.
 
also, please be specific.
 
>> Why does rbridge try to 
>> build up MAC table although it is possible that the MAC info can be 
>> installed on bridges on-demand when ARP is actually exchanged between source 
>and 
>> destination ? Of course if we use ARP for this purpose instead of link-status 
>protocol. 
> 
>I think of it the way you do - on-demand, the way learning bridges work.
 
and then what happen? why did you stop thinking of this method. 
what problem did you face? I have a solution. I want to share my idea.
 
>> "Divide local network by IP subnets. Pass ARP between rbridges in a way 
>> that prevent looping and reduce unnecessary flooding and via shortest path. 
>> The shortest -path, I mean, is according to subnets and other information. 
> 
>That's not an rbridge; that's a set of routers.
 
what's your criteria of distinguishing hybrid switch and router? 
for me, a router requires IP processing function in data forwarder, whereas, 
hybrid switch is a machine providing IP equivalent service using L2 hardware. 
the concept of employing IP aware protocol over L2 hardware is same 
as rbridge and my proposal. read the above text carefully. I just talked ARP, 
shortest-path and subnet. Isn't that a bit different way of using ARP 
compared to rbridge that you drafted? and you spell it router.... 

>> ARP will be flooded in destination subnet anyway. 
> 
>ARP will not flood beyond the first IP subnet; see RFCs 1812 (don't 
>forward all 1's broadcast, which is ARP) and RFC 2644 (don't even 
>forward subnet-directed broadcasts). 
>
 
what defined in RFC2644 is service termination of L2 at routers. 
I am sure some objective of rbridge is to replace the role of 
routers, and extend the range of L2 service (including ARP) across 
rbridged LANs. In that case, RFC2644 is not exactly relevant to 
new concept of hybrid switch.
 
I am wondering, somehow, you think one whole rbridge domain 
should be one IP subnet. If so. (though not sure of your opinion) 
as Alex noted, I must point out that the size of one rbridge cloud 
can be more than 50,000 terminals if rbridge is used in metro-Ethernet.
Currently metro-Ethernet ISPs use L3 switches 
to tackle scaling problem. IEEE recently works on Provider Bridge 
standard (802.1ad) of which the main objective is to replace L3 switches 
to bridges. Main idea of pbridge is providing VLAN interconnectivity 
between customer network using bridged provider network. 

I think IETF rbridge will eventually compete with IEEE pbridge in market. 
In that case, I am wondering what grouping 
method you will propose to be distinguished from IEEE pbridge. 
In order to get favorable support from customer, you need a method of 
systematically organizing rbridged network consists of 100,000 of terminals. 
I can't think better method than IP subnetting of customer networks 
and interconnecting subnets by rbridge.

Dr. Jaihyung Cho
ETRI, Korea
phone :       042) 860-5514
oversea: +82-42-860-5514
fax:         +82-42-861-5550 

Date: Mon, 14 Mar 2005 06:29:43 -0800
From: Joe Touch <[email-masked]>
To: "CHO, JAI HYUNG" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] End station discovery/liveness detection
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4532

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5A2C41D06BB8A8BF7459CA84
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

CHO, JAI HYUNG wrote:
>  
> Dear All
>  
> Pardon me if I ask some question regarding this discussion.
>  
> 1) ARP is sent actively to probe an inactive terminal and obtain MAC info, 
> right? 

No. Not in general, and I haven't heard that proposed as a way to make 
the rbridge work.

New MAC addresses are noticed by seeing packets enter the rbridge with 
new (MAC) source addresses, the same as with a learning bridge.

> 2) And the MAC information is distributed using something like link-status 
> protocol. 

Yes - within each rbridge campus.

> 3) The distributed MAC information is used for passing datagram to actual 
> destination. By the way, in most IP terminals, the first datagram sent to destination 
> terminal is, again...., ARP !!!!

ARP is not sent to the destination; it is sent to broadcast.

> - Therefore, in summary, the rbridge does ARP probing constantly although 
> my terminal never get called by others. 

No, as above.

> - in other words, rbridges must keep up MAC address of all terminals in lookup table 
> although the actual number of MAC addresses other terminals need to know is only a 
> few of servers. 

No, again as above.

> - the link-status protocol distributes MAC info which will be anyway known by 
> ARP when it is actually necessary by terminal. In other words, rbridge
> uses ARP and link-status protocol to know the information that will be known 
> by ARP?

No, again as above.

> For me, it sounds strange. 
> 
> Why does rbridge try to 
> build up MAC table although it is possible that the MAC info can be 
> installed on bridges on-demand when ARP is actually exchanged between source and 
> destination ? Of course if we use ARP for this purpose instead of link-status protocol.

I think of it the way you do - on-demand, the way learning bridges work.

> Here is my suggestion;
> 
> "Divide local network by IP subnets. Pass ARP between rbridges in a way 
> that prevent looping and reduce unnecessary flooding and via shortest path.
> The shortest -path, I mean, is according to subnets and other information.

That's not an rbridge; that's a set of routers.

> ARP will be flooded in destination subnet anyway. 

ARP will not flood beyond the first IP subnet; see RFCs 1812 (don't 
forward all 1's broadcast, which is ARP) and RFC 2644 (don't even 
forward subnet-directed broadcasts).

> When a destination terminal replies, just install the MAC entry on 
> lookup table of rbridges. Thus a MAC forwarding path, i.e. a L2 connection,
> is established via sub-optimal path across IP subnets.
>  
> This is not ATM, nor MPLS, but something L2 LSP.
>  
> Using this method, rbridges do not need to probe terminals constantly, 
> do not need to build entire MAC table, also do not need to 
> worry about terminals that are indirectly connected, removed or inactive. 
> am I wrong?

See above. ;-)

Joe

>  
> Jaihyung Cho
>  
> 
> 
>>Alex Zinin wrote: 
>>
>>>Yes, this would work, and would most probably represent the largest part of 
>>>station attachments in today deployments. There are corner cases, like a 
>>>mini-hub in a cubicle with a single station attached to it, but we don't 
>>>optimize for those and a probing-based safe-fail should take care of them. 
>>
>>That sort of probing can cause large amounts of broadcasts outside the 
>>rbridge campus, notably which may cascade into a subsequent rbridge 
>>(imagine two campuses that get connected by a hub). 
>>
>>What about this case (the direct attached one) is so significantly worth 
>>optimizing? 
>>
>>Joe
> 
>  
> 
> Dr. Jaihyung Cho
> ETRI, Korea
> phone :       042) 860-5514
> oversea: +82-42-860-5514
> fax:         +82-42-861-5550 
> 
> 
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://www.postel.org/mailman/listinfo/rbridge

--------------enig5A2C41D06BB8A8BF7459CA84
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig5A2C41D06BB8A8BF7459CA84--

priority: normal
From: "CHO, JAI HYUNG" <[email-masked]>
To: <[email-masked]>
Cc: 
Date: Mon, 14 Mar 2005 23:20:13 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Content-Class: urn:content-classes:message
Importance: normal
Subject: Re: [rbridge] End station discovery/liveness detection
Reply-To: "CHO, JAI HYUNG" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2820

Dear All
 
Pardon me if I ask some question regarding this discussion.
 
1) ARP is sent actively to probe an inactive terminal and obtain MAC info, 
right? 
2) And the MAC information is distributed using something like link-status 
protocol. 
3) The distributed MAC information is used for passing datagram to actual 
destination. By the way, in most IP terminals, the first datagram sent to destination 
terminal is, again...., ARP !!!!

- Therefore, in summary, the rbridge does ARP probing constantly although 
my terminal never get called by others. 
- in other words, rbridges must keep up MAC address of all terminals in lookup table 
although the actual number of MAC addresses other terminals need to know is only a 
few of servers. 
- the link-status protocol distributes MAC info which will be anyway known by 
ARP when it is actually necessary by terminal. In other words, rbridge
uses ARP and link-status protocol to know the information that will be known 
by ARP?

For me, it sounds strange. 

Why does rbridge try to 
build up MAC table although it is possible that the MAC info can be 
installed on bridges on-demand when ARP is actually exchanged between source and 
destination ? Of course if we use ARP for this purpose instead of link-status protocol.
 
Here is my suggestion;

"Divide local network by IP subnets. Pass ARP between rbridges in a way 
that prevent looping and reduce unnecessary flooding and via shortest path.
The shortest -path, I mean, is according to subnets and other information.
ARP will be flooded in destination subnet anyway. 
When a destination terminal replies, just install the MAC entry on 
lookup table of rbridges. Thus a MAC forwarding path, i.e. a L2 connection,
is established via sub-optimal path across IP subnets.
 
This is not ATM, nor MPLS, but something L2 LSP.
 
Using this method, rbridges do not need to probe terminals constantly, 
do not need to build entire MAC table, also do not need to 
worry about terminals that are indirectly connected, removed or inactive. 
am I wrong?
 
Jaihyung Cho

>Alex Zinin wrote: 
>> Yes, this would work, and would most probably represent the largest part of 
>> station attachments in today deployments. There are corner cases, like a 
>> mini-hub in a cubicle with a single station attached to it, but we don't 
>> optimize for those and a probing-based safe-fail should take care of them. 
> 
>That sort of probing can cause large amounts of broadcasts outside the 
>rbridge campus, notably which may cascade into a subsequent rbridge 
>(imagine two campuses that get connected by a hub). 
> 
>What about this case (the direct attached one) is so significantly worth 
>optimizing? 
> 
>Joe

Dr. Jaihyung Cho
ETRI, Korea
phone :       042) 860-5514
oversea: +82-42-860-5514
fax:         +82-42-861-5550 

Date: Mon, 14 Mar 2005 05:13:40 -0800
From: Joe Touch <[email-masked]>
To: "CHO, JAI HYUNG" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] text on hop-count in updated charter
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 6859

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig56BDD6D0842FC760E227EB18
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

CHO, JAI HYUNG wrote:
>  
> I apologize for previous mal-formatted mail.
> my company mail system has recently been updated and it seems
> not working well with rbridge mailing system.
> please ignore previous mail of same title.
>  
> Jaihyung Cho
>  
> ======================================
> 
> Dear Joe Touch
> I just get back to work after long-flying. 
> Please read following in-line.
>  
>  
> 
>>>I believe you are confining applicable routing technology just in 
>>>link-status protocols. 
>>
>>No; I am assuming that TRILL will not _force_ a single specific interior 
>>routing protocol, but would still like to have a common encapsulation 
> 
>                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
> 
>>header. 
>>
> 
> By saying a "common encapsulating header", you are already 
> selective to certain technology. 

That is the point of standards. ;-)

> I am wondering what are the actual goals of R-bridge. 
> Is it improving bridges or creating your own link protocol? 

It is a protocol or shim header that is local to the rbridge, and yes, 
it is created for the rbridge.

> It seems your effort is more focused on justifying new header 
> rather than seeking a solution.
> Unless you open discussion, you wouldn't know what 
> other solutions there will be. However, if anything referring the 
> "encapsulation header" part is fixed in charter, I think it is 
> in effect, excluding other *non-encapsulation* technology from 
> consideration.

The need for the header is to be INCLUSIVE, not exclusive. Here's why:

- we want to support internal links that lack loop checks (notably Ethernet)
- we want to support routing protocols that may have transient routing 
loops, and not limit ourselves to just circuit-based solutions

As others have observed, there are other ways to avoid loops than TTLs, 
but TTLs are the common, simple solution. Adding TTLs requires a header 
(shim or otherwise) inside the rbridge.

Thus the need for common support a variety of solutions means the need 
for TTLs in a common rbridge (shim) header.

>>>| ATM-MPLS is a circuit-oriented technology (on both counts). The current 
>>>| charter doesn't want to assume only circuits inside an rbridge campus, 
>>>
>>>which part of charter specifically exclude circuit technology inside the 
>>>rbridge? 
>>
>>"does not want to assume only circuits" does not exclude their use; it 
>>excludes their EXCLUSIVE use. I.e., it assumes we may want to support 
>>others, which is already true (IS-IS, as you mention). 
>>
> 
> Partly agreed.. 
> It is good to consider several dissimilar technologies together. 
> However, I do not think rbridge should have a *generic* 
> architecture that can do everything. If one solution, ether connectionless 
> or connection-oriented, is sufficient to provide service to both type 
> of applications, I think one light-weight solution is better than 
> multi-function solution.

One byte of TTL is very lightweight. And the Internet teaches us that 
multifunction solutions are fine. Optimizing for a single solution is 
where we have typically had more problem.

> With this regard, I would like to ask what are the service objectives 
> of rbridge given to end-users? It seems rbridge lacks commercially 
> meaningful benefits to end-users, such as QoS, authentication, 
> metering & charging, etc. 
> How will rbridge protect guaranteed flows from abusive user or 
> masquerading of service class? 

Please begin by explaining how any of these are currently provided by 
arbitrary link layers.

If you want to advertize either ATM or MPLS, that's fine - but that's 
not what the rbridge is solving.

> How will rbridge provide flexible and secure platform for commercial 
> service flows. Traffic attributes of some applications are really dynamic. 
> How will rbridge know such variation of user request?
> I think these are important requirements of NGN. 
> Rbridge is surely an attractive, however, if rbridge does not give any solution 
> to such market requirements, I think impact to industry will be marginal.

Industry ubiquitously uses bridges. It does not ubiquitously use ATM 
(does it even use it anymore?). And it does not use MPLS to the end 
user. It isn't clear this discussion is relevant to what this WG is 
trying to achieve.

> Note that some technology is good for flexibility but hard to 
> guarantee anything, however, others are rigid but good for commercial 
> service. For example, think about the way rbridge forward frames in 
> connectionless mode or connection-oriented way...
> If commercial factors are equally considered, I think the way 
> people think about rbridge can be a lot different.
> 
>>>If some *virtual circuit* technology can be considered, there are 
>>>several loop prevention/detection techique we can discuss. 
>>
>>See above; I don't think this is relevant to whether TTLs need to be 
>>supported.
> 
> Why not? If frame forwarding in rbridge is based on pre-establishment 
> of virtual circuit, rather than pre-establishment of routing database, 
> looping can be thoroughly examined at circuit establishment time, 
> thus removes TTL at datagrams.

You have already made the point that IF circuits are used inside 
rbridges we might not need TTLs. But we definitely want to support other 
routing protocols (whether or not we support circuits), so TTLs are 
already needed.

> Again, it must be an open question what forwarding technology 
> the rbridge must adopt, whether header is necessary, whether TTL 
> needs to be introduced, etc.. 
> I'm not asking to remove TTL. I just say to discuss if we really can't 
> do without TTL. 

I am presuming that the rbridge will not fix a single interior routing 
protocol, but might support a variety (not in a single instance, but in 
different campuses, e.g.).

Further, I haven't seen anyone else mention circuits here. Circuits are 
not used for switching packets to the endsystem (maybe that was their 
intent, but they're used more in the core for provisioning). Rbridges 
work more at the endsystem, where bridges work. As such, I doubt 
circuits will be either appropriate or useful anyway.

Joe

--------------enig56BDD6D0842FC760E227EB18
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig56BDD6D0842FC760E227EB18--

priority: normal
From: "CHO, JAI HYUNG" <[email-masked]>
To: <[email-masked]>
Cc: 
Date: Mon, 14 Mar 2005 19:00:46 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Content-Class: urn:content-classes:message
Importance: normal
Subject: Re: [rbridge] text on hop-count in updated charter
Reply-To: "CHO, JAI HYUNG" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4005

I apologize for previous mal-formatted mail.
my company mail system has recently been updated and it seems
not working well with rbridge mailing system.
please ignore previous mail of same title.
 
Jaihyung Cho
 
======================================

Dear Joe Touch
I just get back to work after long-flying. 
Please read following in-line.

>> I believe you are confining applicable routing technology just in 
>> link-status protocols. 
> 
>No; I am assuming that TRILL will not _force_ a single specific interior 
>routing protocol, but would still like to have a common encapsulation 
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
>header. 
By saying a "common encapsulating header", you are already 
selective to certain technology. 
I am wondering what are the actual goals of R-bridge. 
Is it improving bridges or creating your own link protocol? 
It seems your effort is more focused on justifying new header 
rather than seeking a solution.
Unless you open discussion, you wouldn't know what 
other solutions there will be. However, if anything referring the 
"encapsulation header" part is fixed in charter, I think it is 
in effect, excluding other *non-encapsulation* technology from 
consideration.

>> | ATM-MPLS is a circuit-oriented technology (on both counts). The current 
>> | charter doesn't want to assume only circuits inside an rbridge campus, 
>> 
>> which part of charter specifically exclude circuit technology inside the 
>> rbridge? 
> 
>"does not want to assume only circuits" does not exclude their use; it 
>excludes their EXCLUSIVE use. I.e., it assumes we may want to support 
>others, which is already true (IS-IS, as you mention). 
>
Partly agreed.. 
It is good to consider several dissimilar technologies together. 
However, I do not think rbridge should have a *generic* 
architecture that can do everything. If one solution, ether connectionless 
or connection-oriented, is sufficient to provide service to both type 
of applications, I think one light-weight solution is better than 
multi-function solution.
With this regard, I would like to ask what are the service objectives 
of rbridge given to end-users? It seems rbridge lacks commercially 
meaningful benefits to end-users, such as QoS, authentication, 
metering & charging, etc. 
How will rbridge protect guaranteed flows from abusive user or 
masquerading of service class? 
How will rbridge provide flexible and secure platform for commercial 
service flows. Traffic attributes of some applications are really dynamic. 
How will rbridge know such variation of user request?
I think these are important requirements of NGN. 
Rbridge is surely an attractive, however, if rbridge does not give any solution 
to such market requirements, I think impact to industry will be marginal.
Note that some technology is good for flexibility but hard to 
guarantee anything, however, others are rigid but good for commercial 
service. For example, think about the way rbridge forward frames in 
connectionless mode or connection-oriented way...
If commercial factors are equally considered, I think the way 
people think about rbridge can be a lot different.
>> If some *virtual circuit* technology can be considered, there are 
>> several loop prevention/detection techique we can discuss. 
> 
>See above; I don't think this is relevant to whether TTLs need to be 
>supported.
Why not? If frame forwarding in rbridge is based on pre-establishment 
of virtual circuit, rather than pre-establishment of routing database, 
looping can be thoroughly examined at circuit establishment time, 
thus removes TTL at datagrams.
Again, it must be an open question what forwarding technology 
the rbridge must adopt, whether header is necessary, whether TTL 
needs to be introduced, etc.. 
I'm not asking to remove TTL. I just say to discuss if we really can't 
do without TTL. 

Dr. Jaihyung Cho
ETRI, Korea
phone :       042) 860-5514
oversea: +82-42-860-5514
fax:         +82-42-861-5550 

priority: normal
From: "CHO, JAI HYUNG" <[email-masked]>
To: <[email-masked]>
Cc: 
Date: Mon, 14 Mar 2005 17:10:04 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Content-Class: urn:content-classes:message
Importance: normal
Subject: Re: [rbridge] text on hop-count in updated charter
Reply-To: "CHO, JAI HYUNG" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3656

Dear Joe Touch I just get back to work after long-flying.Please read following in-line. >> I believe you are confining applicable routing technology just in>> link-status protocols.>>No; I am assuming that TRILL will not _force_ a single specific interior>routing protocol, but would still like to have a common encapsulation                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^>header.> By saying a "common encapsulating header", you are alreadyselective to certain technology.  I am wondering what are the actual goals of R-bridge.Is it improving bridges or creating your own link protocol? It seems your effort is more focused on justifying new header rather than seeking a solution. Unless you open discussion, you wouldn't know whatother solutions there will be. However, if anything referring the "encapsulation header" part is fixed in charter, I think it is in effect, excluding other *non-encapsulation* technology from consideration.  >> | ATM-MPLS is a circuit-oriented technology (on both counts). The current>> | charter doesn't want to assume only circuits inside an rbridge campus,>>>> which part of charter specifically exclude circuit technology inside the>> rbridge?>>"does not want to assume only circuits" does not exclude their use; it>excludes their EXCLUSIVE use. I.e., it assumes we may want to support>others, which is already true (IS-IS, as you mention).> Partly agreed..It is good to consider several dissimilar technologies together.However, I do not think rbridge should have a *generic*architecture that can do everything. If one solution, ether connectionlessor connection-oriented, is sufficient to provide service to both typeof applications, I think one light-weight solution is better thanmulti-function solution. With this regard, I would like to ask what are the service objectivesof rbridge given to end-users? It seems rbridge lacks commercially meaningful benefits to end-users, such as QoS, authentication, metering & charging, etc.  How will rbridge protect guaranteed flows from abusive us
er ormasquerading of service class?How will rbridge provide flexible and secure platform for commercialservice flows. Traffic attributes of some applications are really dynamic.How will rbridge know such variation of user request? I think these are important requirements of NGN. Rbridge is surely an attractive, however, if rbridge does not give any solutionto such market requirements, I think impact to industry will be marginal. Note that some technology is good for flexibility but hard to guarantee anything, however, others are rigid but good for commercial service. For example, think about the way rbridge forward frames in connectionless mode or connection-oriented way... If commercial factors are equally considered, I think the waypeople think about rbridge can be a lot different. >> If some *virtual circuit* technology can be considered, there are>> several loop prevention/detection techique we can discuss.>>See above; I don't think this is relevant to whether TTLs need to be>supported. Why not? If frame forwarding in rbridge is based on pre-establishmentof virtual circuit, rather than pre-establishment of routing database,looping can be thoroughly examined at circuit establishment time, thus removes TTL at datagrams. Again, it must be an open question what forwarding technologythe rbridge must adopt, whether header is necessary, whether TTLneeds to be introduced, etc..I'm not claiming to remove TTL. I just say to discuss if we really can'tdo without TTL.

Dr. Jaihyung Cho
ETRI, Korea
phone :       042) 860-5514
oversea: +82-42-860-5514
fax:         +82-42-861-5550 

Date: Fri, 11 Mar 2005 19:44:54 -0800
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Yes, each VLAN must be a different IP subnet
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 657

Margaret asked me a question at the BOF which I did not think about 
carefully enough
before answering and probably gave
the wrong answer. She theorized that each VLAN must be a separate IP 
subnet, and
she was right. Since the point of VLANs is to separate traffic, each 
VLAN would have
to have its own prefix (so that an endnode in VLAN A won't mistakenly
thing that an endnode in VLAN B was actually a neighbor).
Traffic from one VLAN can only get to another VLAN if forwarded
through a router. And if an endnode moves from one VLAN to another it 
must change
its IP address. This is true today with bridges, and wouldn't change 
with RBridges.

Radia

Date: Fri, 11 Mar 2005 19:54:29 +0000 (GMT)
From: Greg Daley <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Priority: normal
Subject: Re: [rbridge] Possible new attacks to add for security considerations document
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1090

----- Original Message -----
From: Erik Nordmark <[email-masked]>
Date: Friday, March 11, 2005 3:10 am
Subject: Re: [rbridge] Possible new attacks to add for security
considerations document

> Greg Daley wrote:
> 
> > Also I don't think that any keying mechanisms
> > for IEEE are generally applicable, since I
> > guess that the unmanaged network case needs consideration and 
> support> from rbridge as well.
> > 
> > We shouldn't assume that new to be developed
> > techniques are deployed or even applicable in this
> > case.
> 
> I suspect things are a bit more nuanced.

I'm not really tactful though...
 
> While we want to provide a plug&play way to do things (which means 
> that 
> no meaningful key/secret/passwd based security can be required), it 
> is 
> still useful to allow for added security, at the cost of needing to 
> configure things.

Yes, I agree.   Being able to use or reuse security
mechanisms is a worthwhile thing.

I think there are a lot of opportunities for
networks as unmanaged as existing 802 networks
though.

This is an important case.

Greg

Date: Thu, 10 Mar 2005 19:39:07 -0800
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Forwarding inside rbridge cloud
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1667

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD8DB4EB2C096012CD4139F55
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

The only thing not mentioned, IMO, is a VERSION field ;-)

As Radia (and others) point out, all the data that is duplicate can be 
ignored.

I'd hate to have to back-calculate that for half a byte.

Joe

Radia Perlman wrote:
> The ethertype for the original frame is still in the original frame. The 
> outer ethernet
> header is *additional* information. Unlike something like IPsec's ESP or 
> AH header,
> which displaces the "protocol type"/"next header" field in
> the IP header. Here we aren't displacing
> anything.
> 
> Radia
> 
> 
> 
> Margaret Wasserman wrote:
> 
> 
>>One thing that I am not sure about, though, is that we can get away 
>>with such a short rbridge header.  At minimum, I would expect it to 
>>also include an ethertype for the original packet (IPv4, ARP, IPv6...).
>>
>>Margaret
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://www.postel.org/mailman/listinfo/rbridge

--------------enigD8DB4EB2C096012CD4139F55
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigD8DB4EB2C096012CD4139F55--

Date: Thu, 10 Mar 2005 19:32:58 -0800
From: Joe Touch <[email-masked]>
To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Cc: Radia Perlman <[email-masked]>, Russ White <[email-masked]>
Subject: Re: [rbridge] End station discovery/liveness detection
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1319

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5112C205B7DF9DF4A90D42B3
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Alex Zinin wrote:
> Yes, this would work, and would most probably represent the largest part of
> station attachments in today deployments. There are corner cases, like a
> mini-hub in a cubicle with a single station attached to it, but we don't
> optimize for those and a probing-based safe-fail should take care of them.

That sort of probing can cause large amounts of broadcasts outside the 
rbridge campus, notably which may cascade into a subsequent rbridge 
(imagine two campuses that get connected by a hub).

What about this case (the direct attached one) is so significantly worth 
optimizing?

Joe

--------------enig5112C205B7DF9DF4A90D42B3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig5112C205B7DF9DF4A90D42B3--

Date: Thu, 10 Mar 2005 19:10:20 -0800
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Possible new attacks to add for security considerations document
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 604

Greg Daley wrote:

> Also I don't think that any keying mechanisms
> for IEEE are generally applicable, since I
> guess that the unmanaged network case needs consideration and support
> from rbridge as well.
> 
> We shouldn't assume that new to be developed
> techniques are deployed or even applicable in this
> case.

I suspect things are a bit more nuanced.

While we want to provide a plug&play way to do things (which means that 
no meaningful key/secret/passwd based security can be required), it is 
still useful to allow for added security, at the cost of needing to 
configure things.

    Erik

Date: Thu, 10 Mar 2005 16:26:03 -0800
From: Joe Touch <[email-masked]>
To: =?EUC-KR?B?wbbA58f8?= <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] text on hop-count in updated charter
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4297

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig80612167F173F9F25861097A
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 8bit

?????? wrote:
>  
> 
> Dear Joe Touch
> 
>  
> 
> please read followings
> 
> 
> 
> | Hopcounts are required where routing is locally updated; in those cases,
> | the global routing state may temporarily pass through configurations
> | that have transient routing loops.
> 
>  
> 
> 
> I believe you are confining applicable routing technology just in
> link-status protocols.

No; I am assuming that TRILL will not _force_ a single specific interior
routing protocol, but would still like to have a common encapsulation
header.

> I thought TRILL is still open to *the third way* of
> distributing routing information. If the charter doesn't limit the choice of
> routing algorithm, there are some different routing algorithms we can
> consider.
> 
> I am wondering..., if TRILL may give up link-status algorithm and
> willing to experiment yet unknown routing algorithm, .. if there is a
> clear benefit from new solution.

That seems unlikely, IMO. The point of TRILL, at least last I checked
(things seem to be in flux, though) was to enable the use of
well-understood routing protocols as an alternative to just
spanning-tree. While new protocols may also be used, it isn't clear that
a single one needs to be fixed a-priori; that could be negotiated.

> ... or is there a reason people stick to IS-IS?> 
> if it is not...., I think  (routing update = looping)  is not always
> correct assumption to all routing method.
> 
> | ATM-MPLS is a circuit-oriented technology (on both counts). The current
> | charter doesn't want to assume only circuits inside an rbridge campus,
> 
> which part of charter specifically exclude circuit technology inside the 
> rbridge?

"does not want to assume only circuits" does not exclude their use; it
excludes their EXCLUSIVE use. I.e., it assumes we may want to support
others, which is already true (IS-IS, as you mention).

That means either the encapsulation protocol is routing-protocol
specific (which seems unnecessarily complex) or it has a TTL (which
seems a small overhead to pay for flexibility, as well as providing a
safety check if circuits get misconfigured).

> MPLS is also a circuit-oriented technology.
> 
> Is MPLS style bridge control being excluded ?
> 
> I believe employing MPLS forwarding technique within rbridge might be
> useful for layer-2 traffic engineering, although it may possibly
> conflict with CCAMP.
> 
> If some *virtual circuit* technology can be considered, there are
> several loop prevention/detection techique we can discuss.

See above; I don't think this is relevant to whether TTLs need to be
supported.

> |and we expect that the rbridge header will not depend on the routing
> |protocol used. As a result, since packet forwarding may be used (in
> |fact, IMO is more likely to be used), hopcounts are necessary.
> 
> I think this is irrelevant issue. No one proved dependancy of
> routing algorithm and hopcount.

This is well-known for some routing protocols, notably any hop-by-hop
protocols that do not require global synchronization for routing updates.

> |(unless you know of a better or different way to enforce loop detection
> |that does not depend on the routing protocol used).
> 
> perhapse, we may.....
> 
> 
> Dr. Jaihyung Cho
> ETRI, Korea
> phone :       042) 860-5514
> oversea: +82-42-860-5514
> fax:         +82-42-861-5550
> 
> 
> 
> 
> 
> Web Bug from MailScannerWebBug
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://www.postel.org/mailman/listinfo/rbridge

--------------enig80612167F173F9F25861097A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig80612167F173F9F25861097A--

From: =?ks_c_5601-1987?B?wbbA58f8?= <[email-masked]>
To: <[email-masked]>
Cc: 
Date: Fri, 11 Mar 2005 08:33:48 +0900
Priority: normal
Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCBCY06x4rz6utC8rsbALCC047Tn?=
Content-class: urn:content-classes:message
Importance: normal
Subject: Re: [rbridge] text on hop-count in updated charter
Reply-To: =?ks_c_5601-1987?B?wbbA58f8?= <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4662

This is a multi-part message in MIME format.

------=_NextPart_000_B161_01C5260A.E1B08E60
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

------=_NextPart_000_B161_01C5260A.E1B08E60
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

------=_NextPart_000_B161_01C5260A.E1B08E60--

priority: normal
From: "CHO, JAI HYUNG" <[email-masked]>
To: <[email-masked]>
Cc: 
Date: Fri, 11 Mar 2005 08:27:12 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Content-Class: urn:content-classes:message
Importance: normal
Subject: [rbridge]  cheer up!!
Reply-To: "CHO, JAI HYUNG" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1830

Dear TRILL people I think what you guys have done today was great job.The number of people attended in the room manifests big interest on rbridge.The only reason people wasn't fully convinced is because (I think) there wasn't enough explanation on necessity and uniqueness of the work. Part of the reason I am interested in rbridge is because it may provideversatile tool for controlling L2 flows using IP protocols. Such functionis much required in access network where many low-end L2 switchesneeds to be controlled by remote BRAS routers. BRAS is the point that has to distinguish and authenticate user flows, protect premium flows and charge by usage. However, current designof low-end L2 switches doesn't interact with remote routers and giveenough information of user flows. I am wondering TRILL people have discussed potential application of rbridge in this respect. Bringing IP routing capability on L2 bridges is a fancy idea, howeverit seems not much practical benefit is expected just from routing service.However, if it is for L2 switches to pass user information to routersand get traffic control of routers, situation might have been differentbecause it means commercial profit of providers. Application of such service to enterprise network and campus network also has significant meaning because ISPs may have tangible controlon commercial flows across private network. I think it is necessary at this stage to discuss more on potential area ofservice and application rather than focusing on technical solution.If people are open to discuss this matter, I'll submit some requirement and service scenario of such hybrid switch. Hope to have good discussion on this matter. Thank you Regards.... 
 
Dr. Jaihyung Cho
ETRI, Korea
phone :       042) 860-5514
oversea: +82-42-860-5514
fax:         +82-42-861-5550 

Date: Thu, 10 Mar 2005 20:05:28 +0000 (GMT)
From: Greg Daley <[email-masked]>
To: [email-masked]
Priority: normal
Subject: [rbridge] Possible new attacks to add for security considerations document
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1120

Hi,

I think there are two possible attacks which need
adding or clarifying.

1) That a device with multiple ports on the
   VLAN can advertise in order to become a
   root bridge, in a way which makes it on the
   path for connecting two parts of a network.
   It can then not forward packets passing
   between those network fractions.

2) A possible denial of service attack is to
   cycle destination addresses for unicast 
   packets.  This will cause flooding on all
   ports continually (consuming bandwidth, hitting
   back planes), until frame dropping occurs.

*troll warning*

Also I don't think that any keying mechanisms
for IEEE are generally applicable, since I
guess that the unmanaged network case needs consideration and support
from rbridge as well.

We shouldn't assume that new to be developed
techniques are deployed or even applicable in this
case.

I'd certainly welcome statements about the 
applicability and use of these techniques
in the document.  The security issues stand
today in exsiting networks, and will continue
in many environments.

Comments on this issue are welcome.

Greg

Date: Thu, 10 Mar 2005 11:48:21 -0800
From: Dino Farinacci <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [rbridge] VLANs
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1704

>> a packet to all the nodes within the VLAN. These are the same choices as 
>> for multicast,
>> which I summarized in an earlier message, but basically it's
>> a) send through a spanning tree to all RBridges, and DRs only flood onto 
>> their LAN
>> to endnodes if the packet is for the right VLAN (if we did this we 
>> wouldn't even
>> need to announce in link state packets which VLANs RBridge supported)
>> b) send through the same single spanning tree to all RBridges, but an 
>> RBridge looks
>> downstream, and stops forwarding if there are no RBridges supporting 
>> that VLAN further down
>> c) compute per-source-RBridge trees, and when RBridge R floods a packet 
>> for VLAN A,
>> the flooding will be done based on the tree rooted at R, and pruning 
>> will also be done,
>> as per point b.

    d) Use IGMP-snooping to further constrain the forwarding to only where
       there are group members. Can be added to schemes a) through c) above.

    e) Put group membership in LSPs ala MOSPF and use per-source-Rbridge trees.
 
    I think in this environment (where there are less protocols than in IP), 
    that e) might be the best way to go. Typically in layer-2 networks, there 
    is less diameter but more fanout, so you can get the benefits of source
    aggregation per attached switch.

    Flooding of LSPs are pretty fast, incremental Dijkstra's have been
    optimized so good join and prune latency can be acheived.

    In the case of e), IGMP-snooping is not used as the traditional way but 
    the IGMP protocol is used as a link-local protocol as in layer-3.
    That is, received IGMP reports would dictate what groups are put in an
    LSP by an attached DR.

Dino

Date: Thu, 10 Mar 2005 12:30:35 -0700
From: "The Purple Streak, Hilarie Orman" <[email-masked]>
To: [email-masked]
Subject: Re: [rbridge] text on hop-count  in updated charter
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 668

Joe Touch, on Thu, 10 Mar 2005 at 10:29:33 -0800:

> (unless you know of a better or different way to enforce loop detection
> that does not depend on the routing protocol used).

In the literal sense, hopcounts don't detect loops.  There are many
ways to detect loops, the easiest being to collect the destination
addresses onto the packet itself.  So, in a technical sense, the
answer is, sure there's a better way.  But if the goal is to mitigate
the deleterious effects of loops, then a hopcount has a big advantage
in its simplicity.  That simplicity may be obviated by the effect of
(unlikely) persistent errors in handling the hop count field, though.

Hilarie

Date: Thu, 10 Mar 2005 20:18:25 +0100
From: Loa Andersson <[email-masked]>
To: [email-masked]
Subject: Re: [rbridge] text on hop-count  in updated charter
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3695

Radia,

I guess that there are several questions that has to be clarified:

- MPLS header, is this the MPLS label, and if so is it limited to
  one single label or is it possible to stack several
- "onto the frame" exactly where?
- "removed by the egress" would we like to PHP?
- is this the L3 label as specified in the RFC3032, or a "Ethernet
  label" as it will potentially be specified by the CCAMP working
  group

/Loa

Radia Perlman wrote:
> Well, the encapsulation is really link dependent. So on MPLS, indeed, as
> you point
> out, you don't need a hop count. We haven't written down exactly how RBridge
> would work over MPLS, but I think no extra information is needed...an MPLS
> header is stuck onto the frame by the ingress RBridge, and removed by the
> egress RBridge. (Does anyone see any problem with that?)
> 
> For links which are shared media though, it's safer to ensure that temporary
> loops won't cause a problem, rather than try to ensure there never will be
> a temporary loop. Temporary loops can form no matter what if, for instance,
> someone brings up a repeater.
> 
> Radia
> 
> ?????? wrote:
> 
> 
>>Dear All,
>>
>>I am new to this BOF and I found from Radia??s paper, the approach
>>
>>and goal of rbridge is somewhat related to what I have researched for
>>
>>several years.
>>
>>I am very eager to share my idea with TRILL people.
>>
>>By the way, I briefly read initial draft of TRILL charter and felt
>>obliged to
>>
>>express some worry on ??encapsulation?? and ??TTL?? part.
>>
>>I found following text in the charter draft :
>>
>>??.. the packet header *should* have a hop count for robustness
>>
>>in the presence of temporary routing loops??
>>
>>I know TTL has been constantly an issue in TRILL. However,
>>
>>I do not understand why people think TTL as an indispensable part
>>
>>of routing from the first place.
>>
>>Although TTL is a simple, and proven method,
>>
>>TTL is not the only technology tackling looping problem.
>>
>>ATM-MPLS has done well without TTL. There are plenty of
>>
>>proposals preventing or examining loops. I am wondering if
>>
>>there has been enough discussion on other options before
>>
>>people reach the conclusion on TTL.
>>
>>By fixing the hop-count part in charter item, I think this may prevent
>>
>>any future anti-looping technology from consideration and justifying
>>
>>encapsulation overhead from the first. I think the motivation of
>>
>>rbridge is very attractive, however, if it is possible, people must find
>>
>>a way to achieve the goal without modifying current format.
>>
>>For the charter text, I think it is just enough to mention that
>>
>>??Rbridge must have sufficient measure to prevent/detect
>>
>>possible looping ....?? without mentioning new header.
>>
>>Hopefully, this may provide a good consideration.
>>
>>Thank you.
>>
>>Regards
>>
>>Dr. Jaihyung Cho
>>ETRI, Korea
>>phone : 042) 860-5514
>>oversea: +82-42-860-5514
>>fax: +82-42-861-5550
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>rbridge mailing list
>>[email-masked]
>>http://www.postel.org/mailman/listinfo/rbridge
>> 
>>
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://www.postel.org/mailman/listinfo/rbridge

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                           [email-masked]

Date: Thu, 10 Mar 2005 12:52:39 -0600
From: Alex Zinin <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] VLANs
Reply-To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5193

Joe,

 I explained issues with multi-instance routing in one of the previous
 threads.

-- 
Alex
http://www.psg.com/~zinin

Thursday, March 10, 2005, 12:32:52 PM, Joe Touch wrote:
> IMO, VLAN support requires a few things:

> 	a) a way to assign an rbridge port to a VLAN

> 	b) separate forwarding tables and routing protocol instances
> 	   for each VLAN, inside the rbridge campus

> 		which thus contains the MAC addresses on each VLAN
> 		sufficiently

> Other than that, what is hard? and wouldn't these take care of the stuff 
> below?

> Radia Perlman wrote:
>> There are various ways that we can optimize for VLANs, and as usual, the 
>> choices are
>> a continuum of tradeoffs between optimality of memory, bandwidth, 
>> complexity, etc.
>> 
>> One thing we should do is have RBridges announce which VLANs they are 
>> supporting
>> for endnodes. This would have to be configured, which I believe it is 
>> done for bridges.
>> 
>> So each RBridge knows, for each of its links, which VLANs are allowed on 
>> that link.
>> It announces this information in its link state information.
>> 
>> Now all RBridges know which RBridges are attached to which VLANs.
>> 
>> This now allows confining the broadcast domains. Unknown destinations or 
>> ARP/ND
>> queries only need to be sent to Designated RBridges attached to the VLAN 
>> in which
>> the packet originated. Depending on the amount of traffic which is 
>> unicast vs
>> needing to be flooded (within the VLAN), there is a range of choices of 
>> how to get
>> a packet to all the nodes within the VLAN. These are the same choices as 
>> for multicast,
>> which I summarized in an earlier message, but basically it's
>> a) send through a spanning tree to all RBridges, and DRs only flood onto 
>> their LAN
>> to endnodes if the packet is for the right VLAN (if we did this we 
>> wouldn't even
>> need to announce in link state packets which VLANs RBridge supported)
>> b) send through the same single spanning tree to all RBridges, but an 
>> RBridge looks
>> downstream, and stops forwarding if there are no RBridges supporting 
>> that VLAN further down
>> c) compute per-source-RBridge trees, and when RBridge R floods a packet 
>> for VLAN A,
>> the flooding will be done based on the tree rooted at R, and pruning 
>> will also be done,
>> as per point b.
>> 
>> Now for known endnodes:
>> Especially since someone told me that people want the capability to have 
>> overlapping
>> MAC address spaces among VLANs (the node with MAC address "m" in VLAN A
>> might be totally different from the node "m" in VLAN B), RBridges, in 
>> their link
>> state information, should tag what VLAN "m" belongs to.
>> 
>> Given that R knows what VLANs MAC addresses belong to, if R does not support
>> VLAN B, then there is no reason for R to put MAC addresses for B in its
>> forwarding table. But if the endnode information is in the regular link 
>> state information
>> (assume that for now), then R will need to store it so R can participate 
>> in link state
>> flooding.
>> 
>> Now another optimization: Suppose you want to avoid making R know about any
>> endnodes except in VLANs that R supports.
>> 
>> Then we could do the distribution of endnode information separately from the
>> rest of the link state information (the "regular stuff" is the connectivity
>> of the network consisting of RBridges, and tagging which RBridges are in 
>> which
>> VLANs).
>> 
>> If R is in VLAN A, then R must inform all the other RBridges attached to 
>> VLAN A
>> of all of R's VLAN A attached endnodes. If there were enough VLAN A peers in
>> the campus, it would probably be simplest to just use the regular link state
>> flooding to distribute the information. However, if that isn't the case, 
>> then
>> the VLAN A RBridge peers could talk to each other across the cloud to 
>> separately
>> distribute their endnode information. For instance, it could be sent as
>> a VLAN A flood, which the core would know how to do (as per the beginning of
>> this note).
>> 
>> Now, if non-VLAN-A RBridges do not know about the MAC addresses in A,
>> that can't be what they base their forwarding decision on.
>> 
>> If RBridge is working over MPLS, this isn't a problem, since the MPLS
>> path leads to the egress RBridge.
>> 
>> If there were only pt-to-pt links (no shared media) we could have the
>> encapsulation header point to the egress RBridge.
>> 
>> But on shared media, what we can do, at a cost of only 6 additional
>> bytes, is to also put "egress RBridge ID" into the encapsulation header.
>> 
>> So before on Ethernets a packet being forwarded by RBridges looked like:
>> 
>> outer header: source=transmitting RBridge, dest=nexthop RBridge, protocol
>> type=to be defined
>> encapsulation header: TTL
>> original frame
>> 
>> But by making the encapsulation header include "destination RBridge",
>> and having the RBridges along the path forward based on that, then
>> they wouldn't need to be forwarding based on endnode MACs, only
>> RBridge MACs.
>> 
>> Radia
>> 
>> 
>> 
>> _______________________________________________
>> rbridge mailing list
>> [email-masked]
>> http://www.postel.org/mailman/listinfo/rbridge

Date: Thu, 10 Mar 2005 10:32:52 -0800
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] VLANs
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5588

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigC34EFFA477E55C66E8B3CCC5
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

IMO, VLAN support requires a few things:

	a) a way to assign an rbridge port to a VLAN

	b) separate forwarding tables and routing protocol instances
	   for each VLAN, inside the rbridge campus

		which thus contains the MAC addresses on each VLAN
		sufficiently

Other than that, what is hard? and wouldn't these take care of the stuff 
below?

Joe

Radia Perlman wrote:
> There are various ways that we can optimize for VLANs, and as usual, the 
> choices are
> a continuum of tradeoffs between optimality of memory, bandwidth, 
> complexity, etc.
> 
> One thing we should do is have RBridges announce which VLANs they are 
> supporting
> for endnodes. This would have to be configured, which I believe it is 
> done for bridges.
> 
> So each RBridge knows, for each of its links, which VLANs are allowed on 
> that link.
> It announces this information in its link state information.
> 
> Now all RBridges know which RBridges are attached to which VLANs.
> 
> This now allows confining the broadcast domains. Unknown destinations or 
> ARP/ND
> queries only need to be sent to Designated RBridges attached to the VLAN 
> in which
> the packet originated. Depending on the amount of traffic which is 
> unicast vs
> needing to be flooded (within the VLAN), there is a range of choices of 
> how to get
> a packet to all the nodes within the VLAN. These are the same choices as 
> for multicast,
> which I summarized in an earlier message, but basically it's
> a) send through a spanning tree to all RBridges, and DRs only flood onto 
> their LAN
> to endnodes if the packet is for the right VLAN (if we did this we 
> wouldn't even
> need to announce in link state packets which VLANs RBridge supported)
> b) send through the same single spanning tree to all RBridges, but an 
> RBridge looks
> downstream, and stops forwarding if there are no RBridges supporting 
> that VLAN further down
> c) compute per-source-RBridge trees, and when RBridge R floods a packet 
> for VLAN A,
> the flooding will be done based on the tree rooted at R, and pruning 
> will also be done,
> as per point b.
> 
> Now for known endnodes:
> Especially since someone told me that people want the capability to have 
> overlapping
> MAC address spaces among VLANs (the node with MAC address "m" in VLAN A
> might be totally different from the node "m" in VLAN B), RBridges, in 
> their link
> state information, should tag what VLAN "m" belongs to.
> 
> Given that R knows what VLANs MAC addresses belong to, if R does not support
> VLAN B, then there is no reason for R to put MAC addresses for B in its
> forwarding table. But if the endnode information is in the regular link 
> state information
> (assume that for now), then R will need to store it so R can participate 
> in link state
> flooding.
> 
> Now another optimization: Suppose you want to avoid making R know about any
> endnodes except in VLANs that R supports.
> 
> Then we could do the distribution of endnode information separately from the
> rest of the link state information (the "regular stuff" is the connectivity
> of the network consisting of RBridges, and tagging which RBridges are in 
> which
> VLANs).
> 
> If R is in VLAN A, then R must inform all the other RBridges attached to 
> VLAN A
> of all of R's VLAN A attached endnodes. If there were enough VLAN A peers in
> the campus, it would probably be simplest to just use the regular link state
> flooding to distribute the information. However, if that isn't the case, 
> then
> the VLAN A RBridge peers could talk to each other across the cloud to 
> separately
> distribute their endnode information. For instance, it could be sent as
> a VLAN A flood, which the core would know how to do (as per the beginning of
> this note).
> 
> Now, if non-VLAN-A RBridges do not know about the MAC addresses in A,
> that can't be what they base their forwarding decision on.
> 
> If RBridge is working over MPLS, this isn't a problem, since the MPLS
> path leads to the egress RBridge.
> 
> If there were only pt-to-pt links (no shared media) we could have the
> encapsulation header point to the egress RBridge.
> 
> But on shared media, what we can do, at a cost of only 6 additional
> bytes, is to also put "egress RBridge ID" into the encapsulation header.
> 
> So before on Ethernets a packet being forwarded by RBridges looked like:
> 
> outer header: source=transmitting RBridge, dest=nexthop RBridge, protocol
> type=to be defined
> encapsulation header: TTL
> original frame
> 
> But by making the encapsulation header include "destination RBridge",
> and having the RBridges along the path forward based on that, then
> they wouldn't need to be forwarding based on endnode MACs, only
> RBridge MACs.
> 
> Radia
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://www.postel.org/mailman/listinfo/rbridge

--------------enigC34EFFA477E55C66E8B3CCC5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigC34EFFA477E55C66E8B3CCC5--

Date: Thu, 10 Mar 2005 10:29:33 -0800
From: Joe Touch <[email-masked]>
To: =?EUC-KR?B?wbbA58f8?= <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] text on hop-count  in updated charter
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2020

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7CBC213427F8F560E43EF433
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 8bit

?????? wrote:
...
> I found following text in the charter draft :
> 
> ??.. the packet header *should* have a hop count for robustness
> in the presence of temporary routing loops??
> 
> I know TTL has been constantly an issue in TRILL. However,
> 
> I do not understand why people think TTL as an indispensable part
> of routing from the first place.
> Although TTL is a simple, and proven method,
> TTL is not the only technology tackling looping problem.
>  
> ATM-MPLS has done well without TTL. There are plenty of
> proposals preventing or examining loops. I am wondering if
> there has been enough discussion on other options before
> people reach the conclusion on TTL.

Hopcounts are required where routing is locally updated; in those cases,
the global routing state may temporarily pass through configurations
that have transient routing loops.

ATM-MPLS is a circuit-oriented technology (on both counts). The current
charter doesn't want to assume only circuits inside an rbridge campus,
and we expect that the rbridge header will not depend on the routing
protocol used. As a result, since packet forwarding may be used (in
fact, IMO is more likely to be used), hopcounts are necessary.

(unless you know of a better or different way to enforce loop detection
that does not depend on the routing protocol used).

Joe

--------------enig7CBC213427F8F560E43EF433
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig7CBC213427F8F560E43EF433--

priority: normal
From: =?ks_c_5601-1987?B?wbbA58f8?= <[email-masked]>
To: <[email-masked]>
Cc: 
Date: Fri, 11 Mar 2005 03:05:22 +0900
Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCBCY06x4rz6utC8rsbALCC047Tn?=
Content-Class: urn:content-classes:message
Importance: normal
Subject: [rbridge]  test... please ignore and delete it.... sorry
Reply-To: =?ks_c_5601-1987?B?wbbA58f8?= <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 220

text encoding test....
 
sorry for messing mailing list..
 
please delete this mail from archive.

Dr. Jaihyung Cho
ETRI, Korea
phone :       042) 860-5514
oversea: +82-42-860-5514
fax:         +82-42-861-5550 

Priority: normal
From: "CHO, JAI HYUNG" <[email-masked]>
To: <[email-masked]>
Date: Fri, 11 Mar 2005 01:41:52 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Content-Class: urn:content-classes:message
Importance: normal
Subject: Re: [rbridge] text on hop-count  in updated charter
Reply-To: "CHO, JAI HYUNG" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 12214

This is a multi-part message in MIME format.

------=_NextPart_000_AFB5_01C525DB.7FCF6150
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: base64

------=_NextPart_000_AFB5_01C525DB.7FCF6150
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: base64

------=_NextPart_000_AFB5_01C525DB.7FCF6150--

Date: Thu, 10 Mar 2005 08:39:15 -0800
From: Radia Perlman <[email-masked]>
To: =?x-windows-949?B?wbbA58f8?= <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] text on hop-count  in updated charter
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2657

Well, the encapsulation is really link dependent. So on MPLS, indeed, as
you point
out, you don't need a hop count. We haven't written down exactly how RBridge
would work over MPLS, but I think no extra information is needed...an MPLS
header is stuck onto the frame by the ingress RBridge, and removed by the
egress RBridge. (Does anyone see any problem with that?)

For links which are shared media though, it's safer to ensure that temporary
loops won't cause a problem, rather than try to ensure there never will be
a temporary loop. Temporary loops can form no matter what if, for instance,
someone brings up a repeater.

Radia

?????? wrote:

> Dear All,
>
> I am new to this BOF and I found from Radia??s paper, the approach
>
> and goal of rbridge is somewhat related to what I have researched for
>
> several years.
>
> I am very eager to share my idea with TRILL people.
>
> By the way, I briefly read initial draft of TRILL charter and felt
> obliged to
>
> express some worry on ??encapsulation?? and ??TTL?? part.
>
> I found following text in the charter draft :
>
> ??.. the packet header *should* have a hop count for robustness
>
> in the presence of temporary routing loops??
>
> I know TTL has been constantly an issue in TRILL. However,
>
> I do not understand why people think TTL as an indispensable part
>
> of routing from the first place.
>
> Although TTL is a simple, and proven method,
>
> TTL is not the only technology tackling looping problem.
>
> ATM-MPLS has done well without TTL. There are plenty of
>
> proposals preventing or examining loops. I am wondering if
>
> there has been enough discussion on other options before
>
> people reach the conclusion on TTL.
>
> By fixing the hop-count part in charter item, I think this may prevent
>
> any future anti-looping technology from consideration and justifying
>
> encapsulation overhead from the first. I think the motivation of
>
> rbridge is very attractive, however, if it is possible, people must find
>
> a way to achieve the goal without modifying current format.
>
> For the charter text, I think it is just enough to mention that
>
> ??Rbridge must have sufficient measure to prevent/detect
>
> possible looping ....?? without mentioning new header.
>
> Hopefully, this may provide a good consideration.
>
> Thank you.
>
> Regards
>
> Dr. Jaihyung Cho
> ETRI, Korea
> phone : 042) 860-5514
> oversea: +82-42-860-5514
> fax: +82-42-861-5550
>
>------------------------------------------------------------------------
>
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>

Priority: normal
From: =?ks_c_5601-1987?B?wbbA58f8?= <[email-masked]>
To: <[email-masked]>
Date: Thu, 10 Mar 2005 22:22:58 +0900
Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCBCY06x4rz6utC8rsbALCC047Tn?=
Content-Class: urn:content-classes:message
Importance: normal
Cc: [email-masked]
Subject: [rbridge]  text on hop-count  in updated charter
Reply-To: =?ks_c_5601-1987?B?wbbA58f8?= <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 11571

This is a multi-part message in MIME format.

------=_NextPart_000_A986_01C525BF.B6A14250
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

------=_NextPart_000_A986_01C525BF.B6A14250
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

------=_NextPart_000_A986_01C525BF.B6A14250--

Date: Wed, 09 Mar 2005 18:48:54 -0800
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Need scribe and jabber scribe for tomorrows TRILL meeting
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 32

Who will volunteer?

    Erik

Date: Wed, 09 Mar 2005 07:59:43 -0800
From: Radia Perlman <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] VLANs
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4150

There are various ways that we can optimize for VLANs, and as usual, the 
choices are
a continuum of tradeoffs between optimality of memory, bandwidth, 
complexity, etc.

One thing we should do is have RBridges announce which VLANs they are 
supporting
for endnodes. This would have to be configured, which I believe it is 
done for bridges.

So each RBridge knows, for each of its links, which VLANs are allowed on 
that link.
It announces this information in its link state information.

Now all RBridges know which RBridges are attached to which VLANs.

This now allows confining the broadcast domains. Unknown destinations or 
ARP/ND
queries only need to be sent to Designated RBridges attached to the VLAN 
in which
the packet originated. Depending on the amount of traffic which is 
unicast vs
needing to be flooded (within the VLAN), there is a range of choices of 
how to get
a packet to all the nodes within the VLAN. These are the same choices as 
for multicast,
which I summarized in an earlier message, but basically it's
a) send through a spanning tree to all RBridges, and DRs only flood onto 
their LAN
to endnodes if the packet is for the right VLAN (if we did this we 
wouldn't even
need to announce in link state packets which VLANs RBridge supported)
b) send through the same single spanning tree to all RBridges, but an 
RBridge looks
downstream, and stops forwarding if there are no RBridges supporting 
that VLAN further down
c) compute per-source-RBridge trees, and when RBridge R floods a packet 
for VLAN A,
the flooding will be done based on the tree rooted at R, and pruning 
will also be done,
as per point b.

Now for known endnodes:
Especially since someone told me that people want the capability to have 
overlapping
MAC address spaces among VLANs (the node with MAC address "m" in VLAN A
might be totally different from the node "m" in VLAN B), RBridges, in 
their link
state information, should tag what VLAN "m" belongs to.

Given that R knows what VLANs MAC addresses belong to, if R does not support
VLAN B, then there is no reason for R to put MAC addresses for B in its
forwarding table. But if the endnode information is in the regular link 
state information
(assume that for now), then R will need to store it so R can participate 
in link state
flooding.

Now another optimization: Suppose you want to avoid making R know about any
endnodes except in VLANs that R supports.

Then we could do the distribution of endnode information separately from the
rest of the link state information (the "regular stuff" is the connectivity
of the network consisting of RBridges, and tagging which RBridges are in 
which
VLANs).

If R is in VLAN A, then R must inform all the other RBridges attached to 
VLAN A
of all of R's VLAN A attached endnodes. If there were enough VLAN A peers in
the campus, it would probably be simplest to just use the regular link state
flooding to distribute the information. However, if that isn't the case, 
then
the VLAN A RBridge peers could talk to each other across the cloud to 
separately
distribute their endnode information. For instance, it could be sent as
a VLAN A flood, which the core would know how to do (as per the beginning of
this note).

Now, if non-VLAN-A RBridges do not know about the MAC addresses in A,
that can't be what they base their forwarding decision on.

If RBridge is working over MPLS, this isn't a problem, since the MPLS
path leads to the egress RBridge.

If there were only pt-to-pt links (no shared media) we could have the
encapsulation header point to the egress RBridge.

But on shared media, what we can do, at a cost of only 6 additional
bytes, is to also put "egress RBridge ID" into the encapsulation header.

So before on Ethernets a packet being forwarded by RBridges looked like:

outer header: source=transmitting RBridge, dest=nexthop RBridge, protocol
type=to be defined
encapsulation header: TTL
original frame

But by making the encapsulation header include "destination RBridge",
and having the RBridges along the path forward based on that, then
they wouldn't need to be forwarding based on endnode MACs, only
RBridge MACs.

Radia

Date: Fri, 4 Mar 2005 21:03:11 -0800
From: Alex Zinin <[email-masked]>
To: Russ White <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] End station discovery/liveness detection
Reply-To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1426

Friday, March 4, 2005, 6:01:47 PM, Russ White wrote:
>> Yes, this would work, and would most probably represent the largest part
>> of station attachments in today deployments. There are corner cases, like 
>> a mini-hub in a cubicle with a single station attached to it, but we 
>> don't optimize for those and a probing-based safe-fail should take care 
>> of them.

> I assume all bridges use BPDU's?

They start sending/processing BPDUs when STP is enabled, otherwise they're
silently flooding/learning/forwarding.

> If so, could we listen for those, and if
> we don't hear them, simply assume the link is point-to-point?

Presence of BPDUs unambiguously identifies a bridge on the port. However,
absence of them does not.

> Another thing 
> we could look for would be multiple source mac addresses (?).

This will work most of the time, except for the hub case I mentioned:

  +---+
  | Sw|-----[Hub]---[E]
  +---+

The switch sees one link, one MAC. If the Sw-Hub link is down, it does mean that
E is unavailable. However, if that link is up, it is still possible for E to be
unavailable because link Hub-E is down.

I think the above should be good enough, as long as we assume that we're
announcing _reachability of a specific MAC address, rather than momentary
connectivity to the station that uses it. This should go well with the
"presumption of reachability" I mentioned in a previous message to Radia.

Alex

Date: Fri, 4 Mar 2005 21:01:47 -0500 (Eastern Standard Time)
From: Russ White <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] End station discovery/liveness detection
Reply-To: Russ White <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2599

> Yes, this would work, and would most probably represent the largest part 
> of station attachments in today deployments. There are corner cases, like 
> a mini-hub in a cubicle with a single station attached to it, but we 
> don't optimize for those and a probing-based safe-fail should take care 
> of them.

I assume all bridges use BPDU's? If so, could we listen for those, and if 
we don't hear them, simply assume the link is point-to-point? Another thing 
we could look for would be multiple source mac addresses (?).

I think those are the two pieces of "magic" that come to mind without 
spending a lot of time thinking about it.....

:-)

Russ

>
> -- 
> Alex
> http://www.psg.com/~zinin
>
> Friday, March 4, 2005, 6:51:58 AM, Russ White wrote:
>
>>>  If rbridges use the method currently used in bridges, i.e. install a new MAC
>>>  entry when a data frame is seen from the station, and remove it if the station
>>>  hasn't been heard from for about 5-15 minutes, we will be seeing more dynamic
>>>  state changes than if we used the control traffic-based approach. In other
>>>  words, we'd be announcing end station activity information rather than end
>>>  station reachability, and the former is likely to change faster, and thus
>>>  cause the switch to reoriginate and reflood its link-state information more
>>>  often. We would need something better than that for rbridges to scale.
>
>> Hmmm... A simple thought is if there are no "traditional" bridges between
>> you and the attached host, you could rely on simple link state, right? In
>> other words, assuming the host is directly attached to an rbridge, there's
>> really no reason the link would be up with the host down.
>
>> (There are exceptions for ethernet and other oddities, and we're not going
>> to solve those very easily for all cases, so let's consider them an
>> exception, for now, and work with the majority of cases).
>
>> So, what we could do is:
>
>> -- Use some "magic" to determine if we're directly connected to the
>> attached host.
>
>> -- If we are, then just consider the link state the actual state, just like
>> in a real link state protocol. :-)
>
>> -- If we aren't, either use probing, or just use normal bridge techniques
>> (learn etc).
>
>> Thoughts? It would, at least, reduce the number of cases where we would
>> need some technique other than simple link state to a minimal, and possible
>> none in many networks.
>
>> :-)
>
>> Russ
>
>> __________________________________
>> [email-masked] CCIE <>< Grace Alone
>

__________________________________
[email-masked] CCIE <>< Grace Alone

Date: Fri, 4 Mar 2005 15:39:17 -0800
From: Alex Zinin <[email-masked]>
To: Margaret Wasserman <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Control plane scalability
Reply-To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1260

Margaret,

  Sounds like an interesting topic :)

-- 
Alex
http://www.psg.com/~zinin

Friday, March 4, 2005, 3:13:33 PM, Margaret Wasserman wrote:

> Hi Alex,

>>>  Are you planning to build one massive device that would run all of the
>>>  bridging and routing for this 50,000 node network?
>>
>>Margaret, when building switched Ethernet networks today, folks don't build
>>different broadcast domains using separate sets of single-VLAN 
>>devices. Neither
>>they use a single massive device to connect all stations 50,000 as you suggest
>>above. They build VLANs using multi-VLAN switches connected by VLAN trunks.
>>Those VLANs are distributed location-wise, and switches in the core of the
>>network have visibility to most (if not all) VLANs through those trunks.

> Yes, I am somewhat aware of these deployments, but I don't understand why
> this implies that the core switches would be rbridges and/or why they would be
> part of most of the rbridge clouds.

> Maybe we can talk about this when we have a whiteboard handy?  I'm not
> trying to score debating points here .  I think we're just thinking 
> about this differently,
> and I'd like to understand how you believe the topology will work as opposed
> to how I think it will work.

> Margaret

Date: Fri, 4 Mar 2005 18:13:33 -0500
To: Alex Zinin <[email-masked]>
From: Margaret Wasserman <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Control plane scalability
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1082

Hi Alex,

>>  Are you planning to build one massive device that would run all of the
>>  bridging and routing for this 50,000 node network?
>
>Margaret, when building switched Ethernet networks today, folks don't build
>different broadcast domains using separate sets of single-VLAN 
>devices. Neither
>they use a single massive device to connect all stations 50,000 as you suggest
>above. They build VLANs using multi-VLAN switches connected by VLAN trunks.
>Those VLANs are distributed location-wise, and switches in the core of the
>network have visibility to most (if not all) VLANs through those trunks.

Yes, I am somewhat aware of these deployments, but I don't understand why
this implies that the core switches would be rbridges and/or why they would be
part of most of the rbridge clouds.

Maybe we can talk about this when we have a whiteboard handy?  I'm not
trying to score debating points here .  I think we're just thinking 
about this differently,
and I'd like to understand how you believe the topology will work as opposed
to how I think it will work.

Margaret

Date: Fri, 4 Mar 2005 15:09:50 -0800
From: Alex Zinin <[email-masked]>
To: Bill Sommerfeld <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] End station discovery/liveness detection
Reply-To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1234

Bill,

  Unfortunately, node-local knowledge is insufficient. The edge rbridges
  need to know what dst mac to put in the frame, and the internal nodes
  need to know whether to install mac entries for all end stations or
  only other rbridges. So the knowledge and behavior must be consistent
  throughout the network.

-- 
Alex
http://www.psg.com/~zinin

Friday, March 4, 2005, 11:57:18 AM, Bill Sommerfeld wrote:
> On Fri, 2005-03-04 at 13:32, Radia Perlman wrote:
>> If the DB knows a port is not shared media...that it's 
>> only a pt-to-pt link with no intervening bridges, 

> I think you mean "the DB's admin knows".

> I suspect there are few situations where a bridge could know *for sure* 
> that that there can be only one mac address on the other end of the link.  
> There could be a hub.. there could be a bridge told not to talk STP..
> could be a host which uses multiple source mac addresses.

> on the other hand, "I've only seen one source mac address so far and I 
> haven't heard any STP" might be a good enough heuristic in practice.

> 						- Bill

> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://www.postel.org/mailman/listinfo/rbridge

Date: Fri, 4 Mar 2005 14:57:07 -0800
From: Alex Zinin <[email-masked]>
To: Russ White <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Control plane scalability
Reply-To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2531

Russ,

> I'm actually not entirely certain this is true... While STP is, itself,
> rather simple, and concerned with finding loops, isn't layer 2 address 
> learning also required, along with the requisite timers, etc? If so, then I 
> would class these as part of the control plane, as well, I think (?).

This is an interesting point. MAC table can be classified as forwarding state,
similar to the forwarding table in IP routers. MAC table management indeed
involves control plane operations (timers, link state changes, STP topology
change notification), and should be counted.

> And this is where my question comes in, above. No, STP doesn't carry these,
> but the actual learning of where layer 2 addresses are attached to the 
> network is required to make an STP based bridged network actually work, 
> correct?

sure

> The only real difference is, then, between learning these 
> addresses as they are attached, vs when they transmit. I don't know that 
> there's a lot of difference, computationally, between the two.

The difference is what is in computations, data, and BW required to
learn/compute the MAC table entries. In the routing-based scheme, the MAC
entries are the direct result of operations of a distributed algorithm, while in
the bridging case, they are more results of listening to the transit traffic.

>>  The most promising approach would be to use what link-state protocols don't do
>>  today yet--multi-topology flooding, where information related to each VLAN
>>  would be flooded only to the nodes that need it. Note that this would only
>>  reduce the amount of information maintained by the edge switches, and only if
>>  they participate in a considerably smaller subset of VLANs. The core switches,
>>  exposed to most of VLANs would still have to maintain entries for all of them
>>  in their control-plane databases.

> This sound like it might actually scale better than multiple processes, one 
> per vlan.

I certainly think so. Experience with 2547 vs per-VR routing also suggests this.

> Note that if you're using MPLS as your "core," you might not even 
> need this. You might be able to aggregate the address spaces using labels 
> and sites, so the edges see the full table, or at least the part of the 
> table they care about, while the core sees just site to site connections 
> (?)....

> Think that might be feasible??

This is approximately what I had in mind when I asked the question in the
"Forwarding inside rbridge cloud" threat. It may work even without MPLS.

Alex

Date: Fri, 4 Mar 2005 14:38:35 -0800
From: Alex Zinin <[email-masked]>
To: Margaret Wasserman <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Control plane scalability
Reply-To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 10569

Margaret,

> Roughly how many nodes are on a "mid-size network"?  How many L2 links?

>From what I know, switched campus networks today have in the order of 1K VLANs
and a few tens of thousands of stations.

> You later talk about a 50,000 node, 100 link network. Would you consider that
> to be a mid-sized network? Personally, I have never been involved in network
> administration at an organization that owned >5,000 nodes, so I consider
> 50,000 nodes to be a *large* enterprise network. I think of mid-sized
> enterprise networks as consisting of a few hundred to a few thousand nodes.
> (Small ones are less than a few hundred.)

We're on the same page here. Note that the new Ethernet service providers, that
are emerging now, will have thousands of customers, and are already pushing the
common limit of 4K VLANs and current CAM table limits with 100s of MACs that
will need to be supported.

The point being here: looking at a single broadcast domain (VLAN) in this case
is not sufficient. We have to push it to the numbers we're about to see to
understand how this scales.

> What do you mean by "routing at the network layer"?

That was a generalization for IP, IPX, AT routing. Think IP routing.

> It is my understanding that each VLAN represents an IP subnet, and that IP
> routing between VLANs is performed using normal IP routing protocols (OSPF,
> etc.). This requires each VLAN to be configured with IP addresses on a
> separate IP subnet, and nodes cannot move between different VLANs without
> changing IP addresses or running a mobility/tunneling protocol.

That's how we scale beyond the limits of the broadcast domain today. I didn't
catch if you were trying to say this was a bad thing.

>>   Control plane functionality in switches is limited to STP operations.

> I am not sure what definition of "switches" you are using here.

I mean Ethernet switches.

> I think that some switches also contain routing functionality (as described
> above) for IP routing between VLANs.

Of course. Those look logically as routers.

>>   stations. The protocol also doesn't maintain a complete topology map, but
>>   rather functions in distance-vector-like behavior.

> Some of these same advantages could be ascribed to RIP (as opposed to
> OSPF or IS-IS), right?

Close, but not exactly. STP is a single-destination (root) protocol.

>>      1) size of the topology graph and its denseness
>>      2) frequency of topological changes in the graph
>>      3) amount of routing information announced
>>      4) frequency of routing information changes

> These are excellent factors to focus on, I think.  Do we know which of these
> factors is pushing the limits of existing switching hardware?

Those were scaling aspects of the link-state protocols, that don't run on the
Ethernet switches today, and the point was to see what in rbridges would be
different from IP routing.

>   Or is the
> computational portion of a typical switch under-used, with the cost largely
> contained in the switching fabric itself?

for pure Ethernet switches (i.e. routing functionality aside), the control plane
part is simple.

>>   The key consideration is the amount of MAC reachability info and its change
>>   frequency. Clearly, since we're talking about announcing each individual MAC
>>   address, and they are not summarizeable, we will have much more 
>>information to
>>   be distributed than we do in IP routing. E.g., in a multisegment network, if
>>   IP routing was used with /27 subnets, a 100 IP prefixes would 
>>represent about
>>   3,000 hosts that would have to be announced individually in TRILL. One could
>>   certainly make a valid argument that the size of an Ethernet segment is
>>   limited by broadcast, and that a reasonable segment would include a few
>>   hundred stations maximum, which is nothing for link-state IP 
>>routing protocol
>>   implementations today. However, I believe we need to look at the multi-VLAN
>>   scenario in large scale networks to understand the scaling properties.

> Without a way to limit broadcast/multicast traffic to a specific set of nodes,
> a single rbridge cloud could not grow beyond the practical size for a
> broadcast domain.

I would even take it one step further and say that rbridges need a viable way
of scaling in an environment with a large number of VLANs.

> I think that you may be an order of magnitude low in this estimation and that
> broadcast domains of a few thousand nodes may be reasonable (based on my dated
> knowledge of pre-VLAN bridged ethernet deployments). This still wouldn't tax
> the memory and processing capability of a mid-sized router, though.

The above wasn't an attempt to come at the maximum practical size of a broadcast
domain. It was to show how a number of IP prefixes in a network would translate
to the number of MACs.

> It would be interesting to get some real-world data on this.  Are there any
> enterprise network operators in the room who would like to inject some numbers
> about the practical size of a single broadcast domain?

I found a publicly-available description of a university campus network. Here's
the URL: http://sydnet.usyd.edu.au/doc/sydnet.html
Dated 1998 (7 years ago), they had 100 VLANs and 12,000 Ethernet ports.

> We should probably do some investigation to determine if the scaling factors
> of flat routing will hit before or after the scaling factors of a single
> broadcast domain.

Within a single VLAN, broadcast limits will kick in first. I'm not concerned
about this. Multi-VLAN environment is a different story.

> I agree that (as currently defined) an rbridge cloud will be a single
> broadcast domain, and I expect that limits the size of an rbridge cloud to
> something that can be flat routed using a fairly modest amount of processing.

> And, unless folks have some idea of how to create multiple broadcast domains
> without creating separate IP subnets (I am not seeing how that would work), it
> will be necessary (in rbridge networks, just like STP networks) to configure
>   different IP subnet prefixes for different broadcast domains and to route
> between those domains at the IP layer.

I'm not sure what you are arguing here. The points above are obvious...

> I don't understand where the VLANs come in as a multiplier.  If you have 100
> separate rbridge clouds with 500 nodes each, the internal rbridges for
> each cloud will each have 500 entries.  Outside of the rbridge clouds,
> you will effectively have 100 IP subnets (with separate IP subnet addresses
> that will be routed at the IP layer).  So, you will have 100 entries in your IP
> routing tables and a maximum of 500 entries in the "routing" table for any
> given rbridge.

> Are you planning to build one massive device that would run all of the
> bridging and routing for this 50,000 node network?

Margaret, when building switched Ethernet networks today, folks don't build
different broadcast domains using separate sets of single-VLAN devices. Neither
they use a single massive device to connect all stations 50,000 as you suggest
above. They build VLANs using multi-VLAN switches connected by VLAN trunks.
Those VLANs are distributed location-wise, and switches in the core of the
network have visibility to most (if not all) VLANs through those trunks.

> If so, I agree that it
> would need to run 100 rbridge instances (each with 500 "routes"), plus
> at least one IP routing instance (with 100 routes).  I don't really see a
> problem with that, though...

See my reply to Bill and Jarno.

> The alternative device would be running 500 instances of STP and at
> least one IP routing instance (with 100 routes).

See my note on scaling STP in the original message.

> It isn't necessary to run separate IS-IS processes to have separate instances
> of the routing table... At least, I have worked on IP and OSPF implementations
> that ran multiple routing instances in a single process (with a single copy of
> the running code in RAM) by accesses different routing tables based on
> per-instance state blocks. But, this all falls into the category of
> implementation details, I think...

I shouldn't have used the word "process", which is simply a useful abstraction
for resource separation that I used in a wider sense to represent a set of data
structures and computations associated with a specific instance. There _are
implementation-independent scaling issues which I pointed out in my previous
message.

> Besides, it really isn't possible to talk about whether CPU resources will be
> adequate without understanding the time constraints for when the calculation
> would need to complete.  Do you have a good feel for those constraints?

I do have typical numbers, but this is about scalability analysis, which means
we're concerned with asymptotical efficiencies of each approach. In other words,
which algorithm will allow to support larger N using the same CPU, memory, and
BW... or to put it on the other side: which approach will require sooner memory
and CPU upgrades. Clearly maintaining N times more adjacencies and calculating N
times more SPFs becomes a problem with large Ns.

> A lot of this would depend on how the rbridge learning function handles the
> caching and timeout of information.  Would an entry go away when a node
> hibernates?  Or only when that node stops responding to <what?> for <how
long>>?  What happens when the same node shows up elsewhere in the
> topology?

See the thread with subject "End station discovery/liveness detection"

> It is hard, at this point, to distinguish between questions/issues in four
> categories:

> (1) Inherent properties of the TRILL concept (such as the scaling properties
>      of flat routing MAC addresses inside rbridge clouds).

Modulo very dynamic environments with frequent station relocations, TRILL
should be able to handle a single broadcast domain.

> (2) Specific properties of the current rbridge proposal (that could change).
> (3) Ideas that people have about how we could expand rbridge to solve
>      additional problems (like adding a broadcast domain concept).

I don't consider this an additional problem. If the rbridge approach wants to
see the light of deployment, the multi-VLAN case needs to be solved.

Alex

> (3) Constraints that need to be considered for standards work in this
>      space (such as the practical limits for the size of broadcast domains).

> I think that your post touches on all of these areas, and we need to
> figure out how to break them apart and how/when to address each of
> them.

> Margaret

Date: Fri, 4 Mar 2005 13:29:42 -0800
From: Alex Zinin <[email-masked]>
To: Bill Sommerfeld <[email-masked]>, [email-masked]
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Control plane scalability
Reply-To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2655

Bill, Jarno-

 Combined answers to two messages.

 Scaling a routing implementation in general is certainly mostly an
 implementation issue, though, of course, implementations inherit efficiency of
 the algorithms used inside the protocol.

 Scaling routing in virtual topologies takes more than that, however. There are
 very clear implementation-independent scaling differences between
 multi-instance and aggregated (multi-topology) approaches, such as:

  - amount of CPU, BW, and memory spent on neighbor discovery and maintenance;
    the multi-instance approach takes times more, since it operates on virtual
    topologies and sees N times more adjacencies, while the aggregated one operates
    on the physical one.

  - amount of CPU and BW required to reconverge after a topology change;
    in the multi-instance case, each physical topology change maps into N
    virtual topology changes, that result in modification of N neighbor
    adjacencies, reorigination, and reflooding of N LSPs, recalculation of
    N SPFs and routing tables; the aggregated approach sees the physical
    topology, and thus spends less of those.

 When N is small (e.g. O(10)), the multi-instance approach gives acceptable
 results. When N grows larger, however (e.g. current campus network deployments
 already can use 100s to a 1000 VLANs), it becomes a problem. In other words,
 its scaling properties are limited.
    
 This is extremely similar to the question of scaling routing in the L3 VPN
 case. Ross Callon et al did a great job describing different trade-offs of
 routing in VPN in the framework document: draft-ietf-l3vpn-framework-00.txt.
 I would recommend reading it.

Alex

Thursday, March 3, 2005, 11:10:34 PM, [email-masked] wrote:
> Isn't this an implementation/platform issue? E.g. running the different
> instances as threads on the same process would not cause any extra CPU
> overhead?

> So, running separate protocol instances should not be ruled out yet.

Friday, March 4, 2005, 8:07:37 AM, Bill Sommerfeld wrote:
> On the other hand, multiple instances of a protocol are probably the easiest
> way to exploit thread-level parallelism.  

> And scheduling algorithms which can cope efficiently with many
> threads/processes aren't exactly exotic.

> Maybe I'm making a big leap here but somehow I think 
> multicore/multithreaded/etc. processors will eventually find their way into
> the embedded space.

> (And I agree with everything Margaret said about the 1:1 linkage you presume
> between protocol instance and "process" being an implementation artifact.
> Admittedly one that's painful to change...)

> 					- Bill

Date: Fri, 4 Mar 2005 12:31:57 -0800
From: Alex Zinin <[email-masked]>
To: Russ White <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] End station discovery/liveness detection
Reply-To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2127

Yes, this would work, and would most probably represent the largest part of
station attachments in today deployments. There are corner cases, like a
mini-hub in a cubicle with a single station attached to it, but we don't
optimize for those and a probing-based safe-fail should take care of them.

-- 
Alex
http://www.psg.com/~zinin

Friday, March 4, 2005, 6:51:58 AM, Russ White wrote:

>>  If rbridges use the method currently used in bridges, i.e. install a new MAC
>>  entry when a data frame is seen from the station, and remove it if the station
>>  hasn't been heard from for about 5-15 minutes, we will be seeing more dynamic
>>  state changes than if we used the control traffic-based approach. In other
>>  words, we'd be announcing end station activity information rather than end
>>  station reachability, and the former is likely to change faster, and thus
>>  cause the switch to reoriginate and reflood its link-state information more
>>  often. We would need something better than that for rbridges to scale.

> Hmmm... A simple thought is if there are no "traditional" bridges between 
> you and the attached host, you could rely on simple link state, right? In 
> other words, assuming the host is directly attached to an rbridge, there's 
> really no reason the link would be up with the host down.

> (There are exceptions for ethernet and other oddities, and we're not going 
> to solve those very easily for all cases, so let's consider them an 
> exception, for now, and work with the majority of cases).

> So, what we could do is:

> -- Use some "magic" to determine if we're directly connected to the 
> attached host.

> -- If we are, then just consider the link state the actual state, just like 
> in a real link state protocol. :-)

> -- If we aren't, either use probing, or just use normal bridge techniques 
> (learn etc).

> Thoughts? It would, at least, reduce the number of cases where we would 
> need some technique other than simple link state to a minimal, and possible 
> none in many networks.

> :-)

> Russ

> __________________________________
> [email-masked] CCIE <>< Grace Alone

From: Bill Sommerfeld <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Date: Fri, 04 Mar 2005 14:57:18 -0500
Subject: Re: [rbridge] End station discovery/liveness detection
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 654

On Fri, 2005-03-04 at 13:32, Radia Perlman wrote:
> If the DB knows a port is not shared media...that it's 
> only a pt-to-pt link with no intervening bridges, 

I think you mean "the DB's admin knows".

I suspect there are few situations where a bridge could know *for sure* 
that that there can be only one mac address on the other end of the link.  
There could be a hub.. there could be a bridge told not to talk STP..
could be a host which uses multiple source mac addresses.

on the other hand, "I've only seen one source mac address so far and I 
haven't heard any STP" might be a good enough heuristic in practice.

						- Bill

Date: Fri, 04 Mar 2005 14:49:42 -0500
From: Cheng-Yin Lee <[email-masked]>
To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Cc: Radia Perlman <[email-masked]>
Subject: Re: [rbridge] End station discovery/liveness detection
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4227

Alex, Radia,

Alex Zinin wrote:

> Radia,
>
> Thursday, March 3, 2005, 4:04:45 PM, Radia Perlman wrote:
> > Well, endnode reachability information in and of itself is not a problem,
> > because as those that remember DECnet (and CLNP) that's what level 1 routers
> > passed around. The difference was that DECnet/CLNP had the advantage of having
> > endnodes proactively advertise. I think very large flag CLNP networks were
> > deployed, and worked better than bridged topologies of the same size.
>
> How large was "large", if you remember?
>
> > But Ales, I think you are arguing that instead of reporting endnode up/down
> > status we are reporting endnode active/quiet status, which would be more
> > volatile.
>
> Exactly.
>
> > That argument I think argues for having the DB check up on the endnodes, so
> > that the DB is indeed arguing for aliveness rather than "recent activity".
> > This can be done for IP nodes, because we know how to make them talk (ARP,
> > ND). Not sure what other non-IP protocols are widely deployed, and how it
> > would be best to keep tabs on who is still there.
>
> IPX and NetBEUI are probably the most widely spread in enterprise LANs.
> See below.
>
> > One optimization that come to mind is leaving E in your link state information
> > unless you see it pop up elsewhere. If E is dead, then it's not reachable
> > anyway. It's no different than assuming E is on link L based on its IP prefix.
>
> Yes, I was thinking in the direction of "presumption of reachability". I.e.,
> once you've seen it on the the port, assume it's still there unless you've got
> an explicit evidence that it's not, at which time you start actively looking for
> truth by probing or aging the entry out in the absence of traffic from it.
>
> > The obvious thing to worry about is that E has moved, it has spoken, but
> > nobody noticed it has moved becausewhat it said when it came up in the new
> > location got lost.
>
> If positive reachability can be identified based on both traffic and control
> messages, that shouldn't happen.
>
> > To handle that case, we could have the DB, R, in the case where R has reported
> > E as being attached, but R hasn't verified that information in "a long time",
> > then R can continue assuming E is alive and well and still connected, until
> > someone attempts to talk to E. If E is dead or not there and nobody wants to
> > talk to E, then who cares. But if E might have moved, then at the point of
> > delivering data to it, is a good time to check to make sure it's still there,
> > so at that point R can do an ARP/ND query to reassure itself that E is
> > actually there.
>
> One case that I worry about is when a station moves and its address is announced
> by two rbridges for some time, because the old rbridge hasn't had enough time to
> make sure the station is really down. Some of the traffic will be delivered to
> the old location.
>
> > Another optimization is pure data compression. Having link state information
> > that reports all the attached endnodes, with locally assigned dense nicknames
> > (R reports 1=Alice, 2=George, 3=Debra, ...etc). Then R can report the up/down
> > status of all its endnodes as a bitmask.
>
> That would have a visible advantage only in cases where multiple end stations
> changed their state simultaneously. If only one station does (the common case),
> it is not a big difference whether one flushes/floods its MAC address or the
> updated bitmask--the size of the message is approx the same, and the frequency
> is still the same.
>

One thought (to overcome Alex's concerns with link state dissemination of MAC
addresses) is to have the remote RBridge acts as a  "Proxy MAC" (analogous to Proxy
ARP) for its attached hosts.

E.g : X ARP for Y,  Y responds but DstR intercepts the ARP Reply and replies with
its own MAC address, MAC R.
DstR have to cache the attached IP Y address to MAC Y address

X sends pkt to Y with DstR's MAC addresss MAC R.. DstR replaces the dest MAC address
with Y's real MAC address, MAC Y.
=> RBridges flood MAC addresses link states of RBridges,  but not MAC addresses of
hosts.
There would be n MAC addresses link states  if there are n RBridges in the network.

Regards
Cheng-Yin

Date: Fri, 04 Mar 2005 11:22:29 -0800
From: Radia Perlman <[email-masked]>
To: Margaret Wasserman <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Forwarding inside rbridge cloud
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1396

The inside packet will be whatever the source transmitted. So if the source
is on Fiberchannel, or Infiniband, or IEEE, that's what it would look like.

An interesting issue is whether we should RBridge across dissimilar links,
to fool an Infiniband node into thinking it is neighbors with, say, an 
Ethernet node.

I'm sure it will be possible with some link types, and impossible with 
others.
I don't know enough about the various link types to know which ones 
would be hard.

Radia

Margaret Wasserman wrote:

>
> Right.  Sorry...
>
> So, the assumption is that the next header (after the rbridge 
> 'header") will always be an Ethernet header?  Wasn't there a desire to 
> rbridge across IEEE and non-IEEE media?
>
> Margaret
>
> At 10:36 AM -0800 3/4/05, Radia Perlman wrote:
>
>> The ethertype for the original frame is still in the original frame. 
>> The outer ethernet
>> header is *additional* information. Unlike something like IPsec's ESP 
>> or AH header,
>> which displaces the "protocol type"/"next header" field in
>> the IP header. Here we aren't displacing
>> anything.
>>
>> Radia
>>
>>
>>
>> Margaret Wasserman wrote:
>>
>>>
>>>  One thing that I am not sure about, though, is that we can get away 
>>> with such a short rbridge header.  At minimum, I would expect it to 
>>> also include an ethertype for the original packet (IPv4, ARP, IPv6...).
>>>
>>>  Margaret
>>
>

Date: Fri, 4 Mar 2005 14:12:03 -0500
To: Radia Perlman <[email-masked]>
From: Margaret Wasserman <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Forwarding inside rbridge cloud
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 828

Right.  Sorry...

So, the assumption is that the next header (after the rbridge 
'header") will always be an Ethernet header?  Wasn't there a desire 
to rbridge across IEEE and non-IEEE media?

Margaret

At 10:36 AM -0800 3/4/05, Radia Perlman wrote:
>The ethertype for the original frame is still in the original frame. 
>The outer ethernet
>header is *additional* information. Unlike something like IPsec's 
>ESP or AH header,
>which displaces the "protocol type"/"next header" field in
>the IP header. Here we aren't displacing
>anything.
>
>Radia
>
>
>
>Margaret Wasserman wrote:
>
>>
>>  One thing that I am not sure about, though, is that we can get 
>>away with such a short rbridge header.  At minimum, I would expect 
>>it to also include an ethertype for the original packet (IPv4, ARP, 
>>IPv6...).
>>
>>  Margaret

Date: Fri, 04 Mar 2005 10:36:33 -0800
From: Radia Perlman <[email-masked]>
To: Margaret Wasserman <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Forwarding inside rbridge cloud
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 554

The ethertype for the original frame is still in the original frame. The 
outer ethernet
header is *additional* information. Unlike something like IPsec's ESP or 
AH header,
which displaces the "protocol type"/"next header" field in
the IP header. Here we aren't displacing
anything.

Radia

Margaret Wasserman wrote:

>
> One thing that I am not sure about, though, is that we can get away 
> with such a short rbridge header.  At minimum, I would expect it to 
> also include an ethertype for the original packet (IPv4, ARP, IPv6...).
>
> Margaret

Date: Fri, 04 Mar 2005 10:32:39 -0800
From: Radia Perlman <[email-masked]>
To: Russ White <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] End station discovery/liveness detection
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2514

I agree with Russ. Simplifications/optimizations are possible, depending 
on the
type of link. If the DB knows a port is not shared media...that it's 
only a pt-to-pt link
with no intervening bridges, then certainly it seems like a good
idea to do what Russ says below. Also, when we
know a link isn't shared media, we can do another optimization Alex 
suggested earlier (routing towards the exit RBridge rather than the
next hop RBridge). The hop-by-hop specifics of exactly what the
encapsulation header looks like, and various other strategies like how
to learn who is attached, are really link type
specific.

Radia

Russ White wrote:

>> If rbridges use the method currently used in bridges, i.e. install a new MAC
>> entry when a data frame is seen from the station, and remove it if the station
>> hasn't been heard from for about 5-15 minutes, we will be seeing more dynamic
>> state changes than if we used the control traffic-based approach. In other
>> words, we'd be announcing end station activity information rather than end
>> station reachability, and the former is likely to change faster, and thus
>> cause the switch to reoriginate and reflood its link-state information more
>> often. We would need something better than that for rbridges to scale.
>>    
>>
>
>Hmmm... A simple thought is if there are no "traditional" bridges between 
>you and the attached host, you could rely on simple link state, right? In 
>other words, assuming the host is directly attached to an rbridge, there's 
>really no reason the link would be up with the host down.
>
>(There are exceptions for ethernet and other oddities, and we're not going 
>to solve those very easily for all cases, so let's consider them an 
>exception, for now, and work with the majority of cases).
>
>So, what we could do is:
>
>-- Use some "magic" to determine if we're directly connected to the 
>attached host.
>
>-- If we are, then just consider the link state the actual state, just like 
>in a real link state protocol. :-)
>
>-- If we aren't, either use probing, or just use normal bridge techniques 
>(learn etc).
>
>Thoughts? It would, at least, reduce the number of cases where we would 
>need some technique other than simple link state to a minimal, and possible 
>none in many networks.
>
>:-)
>
>Russ
>
>__________________________________
>[email-masked] CCIE <>< Grace Alone
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>

Date: Fri, 4 Mar 2005 12:51:49 -0500 (Eastern Standard Time)
From: Russ White <[email-masked]>
To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Control plane scalability
Reply-To: Russ White <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3918

> Control plane functionality in switches is limited to STP operations. STP 
> is data- and computationally inexpensive. One of its nice properties is 
> that it has no knowledge of end stations. Its purpose is to prune the 
> topology to remove possible loops, rather than to find shortest paths to 
> destinations. STP is not used to populate the MAC table, and its 
> operation is completely independent from the MAC learning and forwarding 
> processes. Therefore, STP message and computational complexity doesn't 
> depend on the number of end stations. The protocol also doesn't maintain 
> a complete topology map, but rather functions in distance-vector-like 
> behavior.

I'm actually not entirely certain this is true... While STP is, itself, 
rather simple, and concerned with finding loops, isn't layer 2 address 
learning also required, along with the requisite timers, etc? If so, then I 
would class these as part of the control plane, as well, I think (?).

> The key consideration is the amount of MAC reachability info and its 
> change frequency. Clearly, since we're talking about announcing each 
> individual MAC address, and they are not summarizeable, we will have much 
> more information to be distributed than we do in IP routing. E.g., in a 
> multisegment network, if IP routing was used with /27 subnets, a 100 IP 
> prefixes would represent about 3,000 hosts that would have to be 
> announced individually in TRILL. One could certainly make a valid 
> argument that the size of an Ethernet segment is limited by broadcast, 
> and that a reasonable segment would include a few hundred stations 
> maximum, which is nothing for link-state IP routing protocol 
> implementations today. However, I believe we need to look at the 
> multi-VLAN scenario in large scale networks to understand the scaling 
> properties.

And this is where my question comes in, above. No, STP doesn't carry these, 
but the actual learning of where layer 2 addresses are attached to the 
network is required to make an STP based bridged network actually work, 
correct? The only real difference is, then, between learning these 
addresses as they are attached, vs when they transmit. I don't know that 
there's a lot of difference, computationally, between the two.

In other words, I don't think a link state vs stp comparison actually 
captures all the elements of complexity involved in the actual operation of 
the network (?).

>  An alternate approach is to run a separate instance of IS-IS for each VLAN.
>  While this may give acceptable results in moderate-size network with a few
>  sparsely populated VLANs, it will have scaling issues of a different type in
>  mid- to large-size deployments, where core switches participate in the
>  majority of VLANs. More specifically, the number of individual processes
>  that would run on the control CPU would stretch the CPU resources.
>
>  The most promising approach would be to use what link-state protocols don't do
>  today yet--multi-topology flooding, where information related to each VLAN
>  would be flooded only to the nodes that need it. Note that this would only
>  reduce the amount of information maintained by the edge switches, and only if
>  they participate in a considerably smaller subset of VLANs. The core switches,
>  exposed to most of VLANs would still have to maintain entries for all of them
>  in their control-plane databases.

This sound like it might actually scale better than multiple processes, one 
per vlan. Note that if you're using MPLS as your "core," you might not even 
need this. You might be able to aggregate the address spaces using labels 
and sites, so the edges see the full table, or at least the part of the 
table they care about, while the core sees just site to site connections 
(?)....

Think that might be feasible??

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone

From: Bill Sommerfeld <[email-masked]>
To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Date: Fri, 04 Mar 2005 11:07:37 -0500
Subject: Re: [rbridge] Control plane scalability
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 764

On Thu, 2005-03-03 at 19:49, Alex Zinin wrote:
>   More specifically, the number of individual processes
>   that would run on the control CPU would stretch the CPU resources.

On the other hand, multiple instances of a protocol are probably the easiest
way to exploit thread-level parallelism.  

And scheduling algorithms which can cope efficiently with many
threads/processes aren't exactly exotic.

Maybe I'm making a big leap here but somehow I think 
multicore/multithreaded/etc. processors will eventually find their way into
the embedded space.

(And I agree with everything Margaret said about the 1:1 linkage you presume
between protocol instance and "process" being an implementation artifact.
Admittedly one that's painful to change...)

					- Bill

Date: Fri, 4 Mar 2005 09:51:58 -0500 (Eastern Standard Time)
From: Russ White <[email-masked]>
To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Cc: Radia Perlman <[email-masked]>
Subject: Re: [rbridge] End station discovery/liveness detection
Reply-To: Russ White <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1688

>  If rbridges use the method currently used in bridges, i.e. install a new MAC
>  entry when a data frame is seen from the station, and remove it if the station
>  hasn't been heard from for about 5-15 minutes, we will be seeing more dynamic
>  state changes than if we used the control traffic-based approach. In other
>  words, we'd be announcing end station activity information rather than end
>  station reachability, and the former is likely to change faster, and thus
>  cause the switch to reoriginate and reflood its link-state information more
>  often. We would need something better than that for rbridges to scale.

Hmmm... A simple thought is if there are no "traditional" bridges between 
you and the attached host, you could rely on simple link state, right? In 
other words, assuming the host is directly attached to an rbridge, there's 
really no reason the link would be up with the host down.

(There are exceptions for ethernet and other oddities, and we're not going 
to solve those very easily for all cases, so let's consider them an 
exception, for now, and work with the majority of cases).

So, what we could do is:

-- Use some "magic" to determine if we're directly connected to the 
attached host.

-- If we are, then just consider the link state the actual state, just like 
in a real link state protocol. :-)

-- If we aren't, either use probing, or just use normal bridge techniques 
(learn etc).

Thoughts? It would, at least, reduce the number of cases where we would 
need some technique other than simple link state to a minimal, and possible 
none in many networks.

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone

Date: Fri, 4 Mar 2005 07:48:21 -0500
To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
From: Margaret Wasserman <[email-masked]>
Subject: Re: [rbridge] Control plane scalability
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 10337

Hi Alex,

A few clarifying questions and some random thoughts...

At 4:49 PM -0800 3/3/05, Alex Zinin wrote:
>   VLANs are used in Ethernet networks of a considerable size to 
>control the size
>   of the broadcast domains. While the size of each VLAN is naturally 
>limited by
>   broadcast, the total number of VLANs in the network can be pretty high
>   (O(100s) for a mid-size network), and so the physical size of the 
>network may
>   be quite large. Connectivity between VLANs is provided via routing at the
>   network layer. Within the VLAN, switches do STP and bridging.

Roughly how many nodes are on a "mid-size network"?  How many L2 links?

You later talk about a 50,000 node, 100 link network.  Would you consider that
to be a mid-sized network?  Personally, I have never been involved in network
administration at an organization that owned >5,000 nodes, so I consider
50,000 nodes to be a *large* enterprise network.  I think of 
mid-sized enterprise
networks as consisting of a few hundred to a few thousand nodes.  (Small ones
are less than a few hundred.)

What do you mean by "routing at the network layer"?  It is my 
understanding that
each VLAN represents an IP subnet, and that IP routing between VLANs is
performed using normal IP routing protocols (OSPF, etc.).  This requires each
VLAN to be configured with IP addresses on a separate IP subnet, and nodes
cannot move between different VLANs without changing IP addresses or running
a mobility/tunneling protocol.

>   Control plane functionality in switches is limited to STP operations.

I am not sure what definition of "switches" you are using here.  I 
think that some
switches also contain routing functionality (as described above) for IP routing
between VLANs.

>  STP is
>   data- and computationally inexpensive. One of its nice properties is that it
>   has no knowledge of end stations. Its purpose is to prune the topology to
>   remove possible loops, rather than to find shortest paths to 
>destinations. STP
>   is not used to populate the MAC table, and its operation is completely
>   independent from the MAC learning and forwarding processes. Therefore, STP
>   message and computational complexity doesn't depend on the number of end
>   stations. The protocol also doesn't maintain a complete topology map, but
>   rather functions in distance-vector-like behavior.

Some of these same advantages could be ascribed to RIP (as opposed to
OSPF or IS-IS), right?

>      1) size of the topology graph and its denseness
>      2) frequency of topological changes in the graph
>      3) amount of routing information announced
>      4) frequency of routing information changes

These are excellent factors to focus on, I think.  Do we know which of these
factors is pushing the limits of existing switching hardware?  Or is the
computational portion of a typical switch under-used, with the cost largely
contained in the switching fabric itself?

>   The first two scaling parameters (graph size and change frequency) do not
>   worry me much, since topologies of L2 networks tend to me much less complex
>   than those of IP networks (that may be a result of experience with STP
>   convergence, and could be expected to change in future).

Right.  One of the advantages of rbridges would be the ability to 
take advantage
of redundant paths, so we should probably assume that people will install more
redundant paths in an rbridge cloud than in an STP network.

>   The key consideration is the amount of MAC reachability info and its change
>   frequency. Clearly, since we're talking about announcing each individual MAC
>   address, and they are not summarizeable, we will have much more 
>information to
>   be distributed than we do in IP routing. E.g., in a multisegment network, if
>   IP routing was used with /27 subnets, a 100 IP prefixes would 
>represent about
>   3,000 hosts that would have to be announced individually in TRILL. One could
>   certainly make a valid argument that the size of an Ethernet segment is
>   limited by broadcast, and that a reasonable segment would include a few
>   hundred stations maximum, which is nothing for link-state IP 
>routing protocol
>   implementations today. However, I believe we need to look at the multi-VLAN
>   scenario in large scale networks to understand the scaling properties.

Without a way to limit broadcast/multicast traffic to a specific set 
of nodes, a
single rbridge cloud could not grow beyond the practical size for a broadcast
domain.  I think that you may be an order of magnitude low in this estimation
and that broadcast domains of a few thousand nodes may be reasonable
(based  on my dated knowledge of pre-VLAN bridged ethernet deployments).
This still wouldn't tax the memory and processing capability of a 
mid-sized router,
though.

It would be interesting to get some real-world data on this.  Are there any
enterprise network operators in the room who would like to inject some numbers
about the practical size of a single broadcast domain?

>   In a multi-VLAN environment, a single physical network of L2 switches
>   accommodates multiple virtual VLAN topologies. The number of VLANs 
>in a single
>   network may range from a few to a few hundred. The total number of stations
>   within VLANs may vary from hundreds to tens of thousands. Challenges of
>   scaling link-state routing in such environments are similar to those of
>   scaling routing in the VPN case.

We should probably do some investigation to determine if the scaling factors
of flat routing will hit before or after the scaling factors of a 
single broadcast
domain.  I agree that (as currently defined) an rbridge cloud will be a single
broadcast domain, and I expect that limits the size of an rbridge cloud to
something that can be flat routed using a fairly modest amount of processing.

And, unless folks have some idea of how to create multiple broadcast domains
without creating separate IP subnets (I am not seeing how that would work), it
will be necessary (in rbridge networks, just like STP networks) to configure
  different IP subnet prefixes for different broadcast domains and to route
between those domains at the IP layer.

But, you seem to be making some other assumptions...

>   As proposed now, a single copy of IS-IS would be running on all switches in
>   the network. This means that all switches would need to flood and store MAC
>   addresses in all VLANs, regardless of whether they need them or not. This
>   scheme clearly has scaling problems--e.g., a 100 VLANs with 500 
>stations will
>   require flooding and storing 50,000 entries on each switch in the network,
>   regardless of its position in the network, throughput, computational
>   abilities, available memory, or what traffic it actually sees.

I don't understand where the VLANs come in as a multiplier.  If you have 100
separate rbridge clouds with 500 nodes each, the internal rbridges for
each cloud will each have 500 entries.  Outside of the rbridge clouds,
you will effectively have 100 IP subnets (with separate IP subnet addresses
that will be routed at the IP layer).  So, you will have 100 entries in your IP
routing tables and a maximum of 500 entries in the "routing" table for any
given rbridge.

Are you planning to build one massive device that would run all of the
bridging and routing for this 50,000 node network?  If so, I agree that it
would need to run 100 rbridge instances (each with 500 "routes"), plus
at least one IP routing instance (with 100 routes).  I don't really see a
problem with that, though...

The alternative device would be running 500 instances of STP and at
least one IP routing instance (with 100 routes).

>   An alternate approach is to run a separate instance of IS-IS for each VLAN.
>   While this may give acceptable results in moderate-size network with a few
>   sparsely populated VLANs, it will have scaling issues of a different type in
>   mid- to large-size deployments, where core switches participate in the
>   majority of VLANs. More specifically, the number of individual processes
>   that would run on the control CPU would stretch the CPU resources.

It isn't necessary to run separate IS-IS processes to have separate instances
of the routing table...  At least, I have worked on IP and OSPF implementations
that ran multiple routing instances in a single process (with a single copy of
the running code in RAM) by accesses different  routing tables based on
per-instance state blocks.  But, this all falls into the category of 
implementation
details, I think...

Besides, it really isn't possible to talk about whether CPU resources will be
adequate without understanding the time constraints for when the calculation
would need to complete.  Do you have a good feel for those constraints?

>   Update dynamics of topological information within a RBRIDGE 
>network should be
>   similar to that of an IP network. Frequency of reachability info 
>(MAC address)
>   updates will generally have different patterns. E.g. spikes of 
>updates related
>   to "start-of-day" activities, some level of noise related to stations that
>   hibernate and wake up. In scenarios with massive real-time 
>relocations, as in
>   the wireless case, the rate of updates may grow considerably high.

A lot of this would depend on how the rbridge learning function handles the
caching and timeout of information.  Would an entry go away when a node
hibernates?  Or only when that node stops responding to <what?> for <how
long>?  What happens when the same node shows up elsewhere in the
topology?

It is hard, at this point, to distinguish between questions/issues in four
categories:

(1) Inherent properties of the TRILL concept (such as the scaling properties
     of flat routing MAC addresses inside rbridge clouds).
(2) Specific properties of the current rbridge proposal (that could change).
(3) Ideas that people have about how we could expand rbridge to solve
     additional problems (like adding a broadcast domain concept).
(3) Constraints that need to be considered for standards work in this
     space (such as the practical limits for the size of broadcast domains).

I think that your post touches on all of these areas, and we need to
figure out how to break them apart and how/when to address each of
them.

Margaret

Date: Fri, 4 Mar 2005 06:44:51 -0500
To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
From: Margaret Wasserman <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Forwarding inside rbridge cloud
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 997

At 4:57 PM -0800 3/3/05, Alex Zinin wrote:
>>  outer Ethernet header: source=transmitting RBridge, dest=next hop
>>  RBridge, Ethertype=NEW
>>  encapsulation addiitonal field: TTL
>
>OK. Got it now. I assumed there would be an "rbridge" header and the whole
>package would be then be put in a link-local frame.

This more or less matches what Radia is saying, I think...  The 
rbridge header just happens to be very small.

You have a full Ethernet packet.  You add the rbridge header to the 
beginning (the TTL field), then you encapsulate the resulting packet 
(rbridge header + original packet) into an Ethernet frame.  The 
Ethertype is set to <TBD> (a new value that identifies this as an 
rbridge packet), and that indicates that the next header is an 
rbridge header.

One thing that I am not sure about, though, is that we can get away 
with such a short rbridge header.  At minimum, I would expect it to 
also include an ethertype for the original packet (IPv4, ARP, 
IPv6...).

Margaret

Content-class: urn:content-classes:message
Date: Fri, 4 Mar 2005 09:10:34 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Control plane scalability
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 745

Alex wrote:
>   An alternate approach is to run a separate instance of 
> IS-IS for each VLAN.
>   While this may give acceptable results in moderate-size 
> network with a few
>   sparsely populated VLANs, it will have scaling issues of a 
> different type in
>   mid- to large-size deployments, where core switches 
> participate in the
>   majority of VLANs. More specifically, the number of 
> individual processes
>   that would run on the control CPU would stretch the CPU resources.
> 

Isn't this an implementation/platform issue? E.g. running the different instances as threads on the same process would not cause any extra CPU overhead?

So, running separate protocol instances should not be ruled out yet.

Regards,

	Jarno Rajahalme

Date: Thu, 3 Mar 2005 16:57:17 -0800
From: Alex Zinin <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Forwarding inside rbridge cloud
Reply-To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 898

Radia,

...
> However, if the cloud consists of Ethernet links, and let's say that S
> and D are IP nodes,
> then the original packet as transmitted by S will look like:

> Ethernet header: source=S, destination=D, Ethertype=something
> IP header: who knows, S and D might be IP routers and the source and 
> destination might
> be distant nodes
> layer 4 headers, etc.: who knows

> Let's call that "pkt". The RBridges don't change that at all.

Oh, can we call this "frame", and what's inside it "packet", please :)
This would make it much easier for me.

> What the RBridges would add while forwarding the packet is:

> outer Ethernet header: source=transmitting RBridge, dest=next hop 
> RBridge, Ethertype=NEW
> encapsulation addiitonal field: TTL

OK. Got it now. I assumed there would be an "rbridge" header and the whole
package would be then be put in a link-local frame.

Thanks.

Alex

Date: Thu, 03 Mar 2005 16:48:52 -0800
From: Radia Perlman <[email-masked]>
To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Forwarding inside rbridge cloud
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2010

Alex Zinin wrote:

Radia,

  I must be confused about the number of headers a frame is wrapped around in
  then. The text talks about the original packet (which I assume is the original
  Ether frame, or is it the L3 packet?), the forwarding header, and the
  encapsulating header. How many headers is there when an original frame is put
  on a link inside the rbridge cloud?

************************
Let's say source S emits a packet onto the cloud for target node D (also 
on the cloud).
S and D are addresses on the cloud. RBridges want to forward the packet
in such a way that the RBridges are
invisible to D (D will assume that S is a direct neighbor).

So exactly the bits that S transmits will get delivered to D (other than 
the possible
functionality of RBridging dissimilar links to trick S and D on 
dissimilar links into thinking
they are neighbors, but let's not complicate things here.)

If there was an MPLS infrastructure inside the cloud between RBridges, 
with MPLS paths
set up between all pairs of RBridges, then the first RBridge could add 
an MPLS header
onto what S transmitted, which would be removed by the exit MPLS 
RBridge. Again,
D should not know that anything funny happened in between the time when S
transmitted the packet and D received it.

However, if the cloud consists of Ethernet links, and let's say that S 
and D are IP nodes,
then the original packet as transmitted by S will look like:

Ethernet header: source=S, destination=D, Ethertype=something
IP header: who knows, S and D might be IP routers and the source and 
destination might
be distant nodes
layer 4 headers, etc.: who knows

Let's call that "pkt". The RBridges don't change that at all.
What the RBridges would add while forwarding the packet is:

outer Ethernet header: source=transmitting RBridge, dest=next hop 
RBridge, Ethertype=NEW
encapsulation addiitonal field: TTL

So the packet will have one EXTRA Ethernet header, plus an extra byte 
for TTL.

Hope that answers the question.

Radia

Date: Thu, 3 Mar 2005 16:49:06 -0800
From: Alex Zinin <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Control plane scalability
Reply-To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5850

Radia, folks-

Below are some thoughts on scalability of the routing part in a multi-VLAN
environment below. Note that I'm explicitly scoping this to control plane only.
Comments are welcome.

  VLANs are used in Ethernet networks of a considerable size to control the size
  of the broadcast domains. While the size of each VLAN is naturally limited by
  broadcast, the total number of VLANs in the network can be pretty high
  (O(100s) for a mid-size network), and so the physical size of the network may
  be quite large. Connectivity between VLANs is provided via routing at the
  network layer. Within the VLAN, switches do STP and bridging.

  Control plane functionality in switches is limited to STP operations. STP is
  data- and computationally inexpensive. One of its nice properties is that it
  has no knowledge of end stations. Its purpose is to prune the topology to
  remove possible loops, rather than to find shortest paths to destinations. STP
  is not used to populate the MAC table, and its operation is completely
  independent from the MAC learning and forwarding processes. Therefore, STP
  message and computational complexity doesn't depend on the number of end
  stations. The protocol also doesn't maintain a complete topology map, but
  rather functions in distance-vector-like behavior.

Looking at the control plane part of rbridges now:

  Though technical details haven't been worked out yet, the essence of the
  routing part in the RBRIDGE proposal is to run a link-state protocol like
  IS-IS in the bridges and let them announce learned MAC-addresses as we do
  the IP prefixes now--as leaves hanging off the transit nodes.

  Control-plane complexity in link-state routing roughly includes two
  components: database/flooding, and route calculation (I skip neighbor
  discovery and maintenance for simplicity). Several parameters drive the
  overhead in these two components:

     1) size of the topology graph and its denseness
     2) frequency of topological changes in the graph
     3) amount of routing information announced
     4) frequency of routing information changes

  Compared to STP, the amount of information that needs to be maintained by
  rbridges in the control plane is clearly greater. Same is true for the
  computational overhead.

  The first two scaling parameters (graph size and change frequency) do not
  worry me much, since topologies of L2 networks tend to me much less complex
  than those of IP networks (that may be a result of experience with STP
  convergence, and could be expected to change in future).

  The key consideration is the amount of MAC reachability info and its change
  frequency. Clearly, since we're talking about announcing each individual MAC
  address, and they are not summarizeable, we will have much more information to
  be distributed than we do in IP routing. E.g., in a multisegment network, if
  IP routing was used with /27 subnets, a 100 IP prefixes would represent about
  3,000 hosts that would have to be announced individually in TRILL. One could
  certainly make a valid argument that the size of an Ethernet segment is
  limited by broadcast, and that a reasonable segment would include a few
  hundred stations maximum, which is nothing for link-state IP routing protocol
  implementations today. However, I believe we need to look at the multi-VLAN
  scenario in large scale networks to understand the scaling properties.

  In a multi-VLAN environment, a single physical network of L2 switches
  accommodates multiple virtual VLAN topologies. The number of VLANs in a single
  network may range from a few to a few hundred. The total number of stations
  within VLANs may vary from hundreds to tens of thousands. Challenges of
  scaling link-state routing in such environments are similar to those of
  scaling routing in the VPN case.

  As proposed now, a single copy of IS-IS would be running on all switches in
  the network. This means that all switches would need to flood and store MAC
  addresses in all VLANs, regardless of whether they need them or not. This
  scheme clearly has scaling problems--e.g., a 100 VLANs with 500 stations will
  require flooding and storing 50,000 entries on each switch in the network,
  regardless of its position in the network, throughput, computational
  abilities, available memory, or what traffic it actually sees.

  An alternate approach is to run a separate instance of IS-IS for each VLAN.
  While this may give acceptable results in moderate-size network with a few
  sparsely populated VLANs, it will have scaling issues of a different type in
  mid- to large-size deployments, where core switches participate in the
  majority of VLANs. More specifically, the number of individual processes
  that would run on the control CPU would stretch the CPU resources.

  The most promising approach would be to use what link-state protocols don't do
  today yet--multi-topology flooding, where information related to each VLAN
  would be flooded only to the nodes that need it. Note that this would only
  reduce the amount of information maintained by the edge switches, and only if
  they participate in a considerably smaller subset of VLANs. The core switches,
  exposed to most of VLANs would still have to maintain entries for all of them
  in their control-plane databases.

  Update dynamics of topological information within a RBRIDGE network should be
  similar to that of an IP network. Frequency of reachability info (MAC address)
  updates will generally have different patterns. E.g. spikes of updates related
  to "start-of-day" activities, some level of noise related to stations that
  hibernate and wake up. In scenarios with massive real-time relocations, as in
  the wireless case, the rate of updates may grow considerably high.

-- 
Alex
http://www.psg.com/~zinin

Date: Thu, 3 Mar 2005 16:42:56 -0800
From: Alex Zinin <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] End station discovery/liveness detection
Reply-To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3405

Radia,

Thursday, March 3, 2005, 4:04:45 PM, Radia Perlman wrote:
> Well, endnode reachability information in and of itself is not a problem,
> because as those that remember DECnet (and CLNP) that's what level 1 routers
> passed around. The difference was that DECnet/CLNP had the advantage of having
> endnodes proactively advertise. I think very large flag CLNP networks were
> deployed, and worked better than bridged topologies of the same size.

How large was "large", if you remember?

> But Ales, I think you are arguing that instead of reporting endnode up/down
> status we are reporting endnode active/quiet status, which would be more
> volatile.

Exactly.

> That argument I think argues for having the DB check up on the endnodes, so
> that the DB is indeed arguing for aliveness rather than "recent activity".
> This can be done for IP nodes, because we know how to make them talk (ARP,
> ND). Not sure what other non-IP protocols are widely deployed, and how it
> would be best to keep tabs on who is still there.

IPX and NetBEUI are probably the most widely spread in enterprise LANs.
See below.

> One optimization that come to mind is leaving E in your link state information
> unless you see it pop up elsewhere. If E is dead, then it's not reachable
> anyway. It's no different than assuming E is on link L based on its IP prefix.

Yes, I was thinking in the direction of "presumption of reachability". I.e.,
once you've seen it on the the port, assume it's still there unless you've got
an explicit evidence that it's not, at which time you start actively looking for
truth by probing or aging the entry out in the absence of traffic from it.

> The obvious thing to worry about is that E has moved, it has spoken, but
> nobody noticed it has moved becausewhat it said when it came up in the new
> location got lost.

If positive reachability can be identified based on both traffic and control
messages, that shouldn't happen.

> To handle that case, we could have the DB, R, in the case where R has reported
> E as being attached, but R hasn't verified that information in "a long time",
> then R can continue assuming E is alive and well and still connected, until
> someone attempts to talk to E. If E is dead or not there and nobody wants to
> talk to E, then who cares. But if E might have moved, then at the point of
> delivering data to it, is a good time to check to make sure it's still there,
> so at that point R can do an ARP/ND query to reassure itself that E is
> actually there.

One case that I worry about is when a station moves and its address is announced
by two rbridges for some time, because the old rbridge hasn't had enough time to
make sure the station is really down. Some of the traffic will be delivered to
the old location.

> Another optimization is pure data compression. Having link state information
> that reports all the attached endnodes, with locally assigned dense nicknames
> (R reports 1=Alice, 2=George, 3=Debra, ...etc). Then R can report the up/down
> status of all its endnodes as a bitmask.

That would have a visible advantage only in cases where multiple end stations
changed their state simultaneously. If only one station does (the common case),
it is not a big difference whether one flushes/floods its MAC address or the
updated bitmask--the size of the message is approx the same, and the frequency
is still the same.

--
Alex

Date: Thu, 3 Mar 2005 16:16:28 -0800
From: Alex Zinin <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Forwarding inside rbridge cloud
Reply-To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1882

Radia,

  I must be confused about the number of headers a frame is wrapped around in
  then. The text talks about the original packet (which I assume is the original
  Ether frame, or is it the L3 packet?), the forwarding header, and the
  encapsulating header. How many headers is there when an original frame is put
  on a link inside the rbridge cloud?

-- 
Alex
http://www.psg.com/~zinin

Thursday, March 3, 2005, 4:06:37 PM, Radia Perlman wrote:
> The reason I think it's a good idea to do hop-by-hop forwarding (i.e., 
> specify next
> hop rather than destination RBridge) is that then there is no 
> duplication of packets.
> If all you specify is final RBridge, and you forward the packet onto a 
> shared medium,
> it is possible that multiple RBridges will think they should forward the 
> packet.

> Radia

> Alex Zinin wrote:

>>Radia-
>>
>> draft-perlman-rbridge-02 says:
>>
>>  
>>
>>>4. Handling non-IP packets
>>>    
>>>
>>...
>>  
>>
>>>   Therefore, the first RBridge (and only the Designated RBridge on the
>>>   source's link) encapsulates the packet with an encapsulation header. 
>>>   The specified next RBridge, R2, will look up the layer 2 destination 
>>>   in the inner header to determine the forwarding direction.  Then R2 
>>>   will replace the layer 2 source and destination addresses in the 
>>>   outer header with R2 as source and next Rbridge as destination, 
>>>   decrement the TTL, and forward the packet.  If R2 is the Designated
>>>    
>>>
>>
>> Is hop-by-hop lookup on the original destination MAC inside the rbridge cloud
>> essential? Would it be possible for the first rbridge to encapsulate the
>> original frame setting the destination MAC address to the egress rbridge
>> in the cloud, so that rbridges inside the cloud only had to maintain forwarding
>> information about edge rbridges, rather than all end stations?
>>
>>  
>>

Date: Thu, 03 Mar 2005 16:06:37 -0800
From: Radia Perlman <[email-masked]>
To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Forwarding inside rbridge cloud
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1379

The reason I think it's a good idea to do hop-by-hop forwarding (i.e., 
specify next
hop rather than destination RBridge) is that then there is no 
duplication of packets.
If all you specify is final RBridge, and you forward the packet onto a 
shared medium,
it is possible that multiple RBridges will think they should forward the 
packet.

Radia

Alex Zinin wrote:

>Radia-
>
> draft-perlman-rbridge-02 says:
>
>  
>
>>4. Handling non-IP packets
>>    
>>
>...
>  
>
>>   Therefore, the first RBridge (and only the Designated RBridge on the
>>   source's link) encapsulates the packet with an encapsulation header. 
>>   The specified next RBridge, R2, will look up the layer 2 destination 
>>   in the inner header to determine the forwarding direction.  Then R2 
>>   will replace the layer 2 source and destination addresses in the 
>>   outer header with R2 as source and next Rbridge as destination, 
>>   decrement the TTL, and forward the packet.  If R2 is the Designated
>>    
>>
>
> Is hop-by-hop lookup on the original destination MAC inside the rbridge cloud
> essential? Would it be possible for the first rbridge to encapsulate the
> original frame setting the destination MAC address to the egress rbridge
> in the cloud, so that rbridges inside the cloud only had to maintain forwarding
> information about edge rbridges, rather than all end stations?
>
>  
>

Date: Thu, 03 Mar 2005 16:04:45 -0800
From: Radia Perlman <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] End station discovery/liveness detection
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3405

Well, endnode reachability information in and of itself is not a 
problem, because
as those that remember DECnet (and CLNP)  that's what level 1 routers
passed around. The difference was that DECnet/CLNP had the advantage of 
having endnodes
proactively advertise. I think very large flag CLNP networks were 
deployed, and
worked better than bridged topologies of the same size.

But Ales, I think you are arguing that instead of reporting endnode 
up/down status
we are reporting endnode active/quiet status, which would be more volatile.

That argument I think argues for having the DB check up on the endnodes, 
so that
the DB is indeed arguing for aliveness rather than "recent activity". 
This can be
done for IP nodes, because we know how to make them talk (ARP, ND). Not
sure what other non-IP protocols are widely deployed, and how it would be
best to keep tabs on who is still there.

One optimization that come to mind is leaving E in your link state 
information unless
you see it pop up elsewhere. If E is dead, then it's not reachable 
anyway. It's no
different than assuming E is on link L based on its IP prefix. The 
obvious thing
to worry about is that E has moved, it has spoken, but nobody noticed it has
moved becausewhat it said when it came up in the new location
got lost.

To handle that case, we could have the DB, R, in the case where R
has reported E as being attached, but R hasn't verified that information
in "a long time", then R can continue assuming E is alive and well and still
connected, until someone attempts to talk to E.
If E is dead or not there and nobody wants to talk to E,
then who cares. But if E might have moved, then at the point of 
delivering data to it,
is a good time to check to make sure it's still there, so at that point 
R can do an ARP/ND
query to reassure itself that E is actually there.

Another optimization is pure data compression. Having link state 
information that reports
all the attached endnodes, with locally assigned dense nicknames (R 
reports 1=Alice,
2=George, 3=Debra, ...etc). Then R can report the up/down status of all 
its endnodes
as a bitmask.

Radia

Alex Zinin wrote:

>Radia,
>
>  That didn't answer my question about timing ;) Anyway, I'll explain what I
>  have in mind.
>
>  MAC address info would account for the largest portion of information
>  like to understand what we can and can't get here.
>
>  If rbridges use the method currently used in bridges, i.e. install a new MAC
>  entry when a data frame is seen from the station, and remove it if the station
>  hasn't been heard from for about 5-15 minutes, we will be seeing more dynamic
>  state changes than if we used the control traffic-based approach. In other
>  words, we'd be announcing end station activity information rather than end
>  station reachability, and the former is likely to change faster, and thus
>  cause the switch to reoriginate and reflood its link-state information more
>  often. We would need something better than that for rbridges to scale.
>
>  I need to think a little about control protocol probing...
>
>  
>

Date: Thu, 3 Mar 2005 15:43:59 -0800
From: Alex Zinin <[email-masked]>
To: [email-masked]
Subject: [rbridge] Forwarding inside rbridge cloud
Reply-To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 996

Radia-

 draft-perlman-rbridge-02 says:

> 4. Handling non-IP packets
...
>    Therefore, the first RBridge (and only the Designated RBridge on the
>    source's link) encapsulates the packet with an encapsulation header. 
>    The specified next RBridge, R2, will look up the layer 2 destination 
>    in the inner header to determine the forwarding direction.  Then R2 
>    will replace the layer 2 source and destination addresses in the 
>    outer header with R2 as source and next Rbridge as destination, 
>    decrement the TTL, and forward the packet.  If R2 is the Designated

 Is hop-by-hop lookup on the original destination MAC inside the rbridge cloud
 essential? Would it be possible for the first rbridge to encapsulate the
 original frame setting the destination MAC address to the egress rbridge
 in the cloud, so that rbridges inside the cloud only had to maintain forwarding
 information about edge rbridges, rather than all end stations?

-- 
Alex
http://www.psg.com/~zinin

Date: Thu, 3 Mar 2005 15:36:48 -0800
From: Alex Zinin <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] End station discovery/liveness detection
Reply-To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4319

Radia,

  That didn't answer my question about timing ;) Anyway, I'll explain what I
  have in mind.

  MAC address info would account for the largest portion of information
  distributed in the link-state routing protocol running in rbridges. Hence,
  it's important to understand the change dynamics for it, as this will affect
  how much information will be flooded around, and as a result affect
  scalability of the technology. Without trying to pin it down here and now, I'd
  like to understand what we can and can't get here.

  If rbridges use the method currently used in bridges, i.e. install a new MAC
  entry when a data frame is seen from the station, and remove it if the station
  hasn't been heard from for about 5-15 minutes, we will be seeing more dynamic
  state changes than if we used the control traffic-based approach. In other
  words, we'd be announcing end station activity information rather than end
  station reachability, and the former is likely to change faster, and thus
  cause the switch to reoriginate and reflood its link-state information more
  often. We would need something better than that for rbridges to scale.

  I need to think a little about control protocol probing...

-- 
Alex
http://www.psg.com/~zinin

Thursday, March 3, 2005, 11:43:44 AM, Radia Perlman wrote:
> Well, it's trivial to do no better or worse than bridges. Just learn 
> from seeing data
> packets and use the same timeouts as bridges do for station learning.

> However, there is an opportunity to do better, and I think the WG should 
> decide
> what optimizations are worth doing.

> Some of the possibilities:
> a) have the DB on endnode E's LAN "keep tabs" on whether E is still there by
> checking up on it (with periodic ARP/ND queries, for instance). The possible
> downside of this is devices that want to go to sleep and save power. 
> It's possible
> this is only an issue on wireless links, but it should be discussed.
> b) have the DB only check if E is there if E gets reported by some other 
> DB as
> existing in some other part of the campus. Then the DB can check to see if E
> has indeed moved, or might perhaps be multiply connected (though multiple
> connections with layer 2 is/should be illegal with bridges, so perhaps 
> we shouldn't
> say that it is not allowed because I'm sure mixing bridges and RBridges will
> cause weird situations if we allow a layer 2 address to exist in 
> multiple locations).

> The other issue discussed was whether ARP/ND queries for E should be 
> optimized.
> The simplest thing would be doing exactly what bridges would 
> do...forward all
> queries through the spanning tree. But I think it would be nice to 
> optimize so
> that at least some of the time the DB proxies the answer, or routes the 
> query to
> where the DB thinks E is located (then there wouldn't be a false 
> reply...only if
> E is actually alive will it respond). Some combination can be done.

> The cases people are worried about are:
> a) E dies, but looks alive to S when S does an ARP/ND query because the S's
> DB proxy ARPs. I don't think this is that bad a situation, though, 
> because if E
> died after responding to S's query, S still has to have some way of 
> coping. The
> RBridge timers won't keep E around forever. Without bridges or RBridges,
> there are always issues with caches like ARP caches, or router-router links
> that haven't yet missed n hellos, etc.
> b) E moves, but the RBridges don't notice. Again, if E doesn't say 
> something, bridges
> won't forward traffic to E properly either.

> But as I said, it is trivial to be at least as good as bridges at end 
> station discovery/liveness
> detection. The only question is should we take advantage of the fact 
> that RBridges
> can do better.

> Radia

> Alex Zinin wrote:

>>Radia, et al-
>>
>> In reviewing the RBRIDGE proposal within the IESG, I've been evaluating its
>> scaling properties. I'd like to clarify how exactly it is envisioned to
>> discover new and detect unreachable end stations.
>>
>> In particular, I'm interested in what kind of time-outs we're looking at for
>> traffic- and ARP/ND-based proposals. I also remember seeing a discussion about
>> disadvantages of the ARP-based method in the meeting minutes. Was there a
>> decision one way or the other?
>>
>>  
>>

Date: Thu, 03 Mar 2005 11:43:44 -0800
From: Radia Perlman <[email-masked]>
To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] End station discovery/liveness detection
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2889

Well, it's trivial to do no better or worse than bridges. Just learn 
from seeing data
packets and use the same timeouts as bridges do for station learning.

However, there is an opportunity to do better, and I think the WG should 
decide
what optimizations are worth doing.

Some of the possibilities:
a) have the DB on endnode E's LAN "keep tabs" on whether E is still there by
checking up on it (with periodic ARP/ND queries, for instance). The possible
downside of this is devices that want to go to sleep and save power. 
It's possible
this is only an issue on wireless links, but it should be discussed.
b) have the DB only check if E is there if E gets reported by some other 
DB as
existing in some other part of the campus. Then the DB can check to see if E
has indeed moved, or might perhaps be multiply connected (though multiple
connections with layer 2 is/should be illegal with bridges, so perhaps 
we shouldn't
say that it is not allowed because I'm sure mixing bridges and RBridges will
cause weird situations if we allow a layer 2 address to exist in 
multiple locations).

The other issue discussed was whether ARP/ND queries for E should be 
optimized.
The simplest thing would be doing exactly what bridges would 
do...forward all
queries through the spanning tree. But I think it would be nice to 
optimize so
that at least some of the time the DB proxies the answer, or routes the 
query to
where the DB thinks E is located (then there wouldn't be a false 
reply...only if
E is actually alive will it respond). Some combination can be done.

The cases people are worried about are:
a) E dies, but looks alive to S when S does an ARP/ND query because the S's
DB proxy ARPs. I don't think this is that bad a situation, though, 
because if E
died after responding to S's query, S still has to have some way of 
coping. The
RBridge timers won't keep E around forever. Without bridges or RBridges,
there are always issues with caches like ARP caches, or router-router links
that haven't yet missed n hellos, etc.
b) E moves, but the RBridges don't notice. Again, if E doesn't say 
something, bridges
won't forward traffic to E properly either.

But as I said, it is trivial to be at least as good as bridges at end 
station discovery/liveness
detection. The only question is should we take advantage of the fact 
that RBridges
can do better.

Radia

Alex Zinin wrote:

>Radia, et al-
>
> In reviewing the RBRIDGE proposal within the IESG, I've been evaluating its
> scaling properties. I'd like to clarify how exactly it is envisioned to
> discover new and detect unreachable end stations.
>
> In particular, I'm interested in what kind of time-outs we're looking at for
> traffic- and ARP/ND-based proposals. I also remember seeing a discussion about
> disadvantages of the ARP-based method in the meeting minutes. Was there a
> decision one way or the other?
>
>  
>

Date: Thu, 3 Mar 2005 11:04:08 -0800
From: Alex Zinin <[email-masked]>
To: [email-masked]
Subject: [rbridge] End station discovery/liveness detection
Reply-To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 519

Radia, et al-

 In reviewing the RBRIDGE proposal within the IESG, I've been evaluating its
 scaling properties. I'd like to clarify how exactly it is envisioned to
 discover new and detect unreachable end stations.

 In particular, I'm interested in what kind of time-outs we're looking at for
 traffic- and ARP/ND-based proposals. I also remember seeing a discussion about
 disadvantages of the ARP-based method in the meeting minutes. Was there a
 decision one way or the other?

-- 
Alex
http://www.psg.com/~zinin

To: "Developing a hybrid router/bridge." <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 2 Mar 2005 18:00:21 +0100
Subject: [rbridge] analysis of threats
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 388

Hi all,

i have just finished an initial threat analysis of rbridges.

http://www.it.uc3m.es/marcelo/draft-bagnulo-trill-threats-pre.txt

This is a very drafty version, but i guess it will allow us to discuss 
about the security in minneapolis.

Any comments are welcome

regards, marcelo

PS: this is based in the current draft where forwarding is done 
sometimes based on IP addresses

Date: Tue, 01 Mar 2005 11:18:12 -0800
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] forwarding of IP packets to off-campus destiantions
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4850

Yup. You're absolutely right. The current draft still says that RBridges 
forward
based on the IP header, which as you point out, would require
RBridges to know the campus prefix, and therefore not be
zero configuration (unless they autoconfigure it the same way IP
endnodes would, but I'm not advocating that).

That section in the draft was an attempt to both avoid the encapsulation
header (in the case of IP packets) and an attempt to avoid requiring
RBridges to learn locations in the forwarding path (in the case of IP 
packets).

I think after discussing it for awhile we realized it just made 
everything more
complicated, so that portion of the internet draft should change (by being
removed). It seems
a better design to just always forward based on the layer 2 header. I 
thought
we had removed it, but I guess we didn't.

So I think you and I are agreeing on what the design should be, and you're
pointing out that the draft doesn't reflect that design.

Radia

marcelo bagnulo braun wrote:

>Hi Radia,
>
>I am not understanding some point here..
>please see below...
>
>El 01/03/2005, a las 18:22, Radia Perlman escribi?:
>
>  
>
>>The devices that have zero configuration are the RBridges. RBridges do
>>not know
>>anything about "on-campus" or "off-campus". It's the IP nodes attached
>>to the cloud that know the difference, but just in the way that IP 
>>nodes
>>have
>>always acted. The IP nodes will decide if the target is "their
>>neighbor", i.e.,
>>on-campus, the way they have always done.
>>
>>It certainly wasn't the intention that RBridges know the on-campus IP
>>prefix, but
>>it might have been discussed when discussing variations on the design.
>>At any
>>rate, it isn't the intention now.
>>
>>The design now is that RBridges will forward all data packets
>>based on the layer 2 destination.
>>
>>    
>>
>
>this is not what i read on the draft
>
>5. Handling on-campus IP Packets
>
>    Here, RBridges forward based on the layer 3 header.
>
>am i misunderstanding something?
>
>  
>
>>IP nodes will fill in the layer 2 destination as the MAC address they
>>receive in an
>>ARP/ND reply (if the target is deemed by the IP node as on-campus), or 
>>to
>>the layer 2 address of an IP router (if the IP source node deems that
>>the target is
>>off-campus).
>>
>>But RBridges won't know the difference as to whether the node they are
>>delivering
>>the packet to is an IP router or the actual destination.
>>
>>    
>>
>
>I am afraid no.
>
>Current draft states that IP packets are treated differently by 
>rbridges dependeing their destiantion.
>
>it is stated that:
>
>5. Handling on-campus IP Packets
>
>    Here, RBridges forward based on the layer 3 header.
>
>and later on that:
>
>6. Handling off-campus IP packets
>
>    Here, RBridges must forward based on the destination in the original
>    layer 2 header, because the endnode must be able to choose which
>    router to send off-campus packets to.  In particular, an IP router
>    must be able to forward to another IP router across the campus.
>
>
>So, rbrdige needs to know if the IP destiantion address is on campus or 
>off campus, in order to treat them differently, hence on campus prefix 
>configuration is needed.
>
>What am i missing?
>
>
>thanks, marcelo
>
>
>
>  
>
>>Hope that answered your question. I know I had written something about
>>what would
>>happen if RBridges attempted to avoid encapsulation with IP packets, 
>>and
>>why that
>>would be hard (because they'd have to forward based on the layer 2
>>header when
>>the packet was off-campus), but that was intended only to explain why
>>it's better if
>>they always forward based on the layer 2 destination. So, sorry for the
>>confusion...
>>
>>Radia
>>
>>marcelo bagnulo braun wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>i have one question regarding the forwarding of IP packets to
>>>off-campus destiantions
>>>
>>>AFAIU, the rbrdiges will forward differently packets addressed to off
>>>campus destiantions that those whose destiantion is on-campus.
>>>
>>>My question is how do they know if a packet destination is on campus 
>>>or
>>>off campus?
>>>
>>>I guess this requires manual configuration of the on campus prefix,
>>>right?
>>>
>>>But if this is the case, wouldn't this be contradicting the proposed
>>>charter requirement:
>>>
>>>- zero configuration of the hybrid devices
>>>
>>>Regards, marcelo
>>>
>>>
>>>_______________________________________________
>>>rbridge mailing list
>>>[email-masked]
>>>http://www.postel.org/mailman/listinfo/rbridge
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>rbridge mailing list
>>[email-masked]
>>http://www.postel.org/mailman/listinfo/rbridge
>>
>>    
>>
>
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 1 Mar 2005 19:51:49 +0100
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] forwarding of IP packets to off-campus destiantions
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3556

Hi Radia,

I am not understanding some point here..
please see below...

El 01/03/2005, a las 18:22, Radia Perlman escribi?:

> The devices that have zero configuration are the RBridges. RBridges do
> not know
> anything about "on-campus" or "off-campus". It's the IP nodes attached
> to the cloud that know the difference, but just in the way that IP 
> nodes
> have
> always acted. The IP nodes will decide if the target is "their
> neighbor", i.e.,
> on-campus, the way they have always done.
>
> It certainly wasn't the intention that RBridges know the on-campus IP
> prefix, but
> it might have been discussed when discussing variations on the design.
> At any
> rate, it isn't the intention now.
>
> The design now is that RBridges will forward all data packets
> based on the layer 2 destination.
>

this is not what i read on the draft

5. Handling on-campus IP Packets

    Here, RBridges forward based on the layer 3 header.

am i misunderstanding something?

> IP nodes will fill in the layer 2 destination as the MAC address they
> receive in an
> ARP/ND reply (if the target is deemed by the IP node as on-campus), or 
> to
> the layer 2 address of an IP router (if the IP source node deems that
> the target is
> off-campus).
>
> But RBridges won't know the difference as to whether the node they are
> delivering
> the packet to is an IP router or the actual destination.
>

I am afraid no.

Current draft states that IP packets are treated differently by 
rbridges dependeing their destiantion.

it is stated that:

5. Handling on-campus IP Packets

    Here, RBridges forward based on the layer 3 header.

and later on that:

6. Handling off-campus IP packets

    Here, RBridges must forward based on the destination in the original
    layer 2 header, because the endnode must be able to choose which
    router to send off-campus packets to.  In particular, an IP router
    must be able to forward to another IP router across the campus.

So, rbrdige needs to know if the IP destiantion address is on campus or 
off campus, in order to treat them differently, hence on campus prefix 
configuration is needed.

What am i missing?

thanks, marcelo

> Hope that answered your question. I know I had written something about
> what would
> happen if RBridges attempted to avoid encapsulation with IP packets, 
> and
> why that
> would be hard (because they'd have to forward based on the layer 2
> header when
> the packet was off-campus), but that was intended only to explain why
> it's better if
> they always forward based on the layer 2 destination. So, sorry for the
> confusion...
>
> Radia
>
> marcelo bagnulo braun wrote:
>
>> Hi,
>>
>> i have one question regarding the forwarding of IP packets to
>> off-campus destiantions
>>
>> AFAIU, the rbrdiges will forward differently packets addressed to off
>> campus destiantions that those whose destiantion is on-campus.
>>
>> My question is how do they know if a packet destination is on campus 
>> or
>> off campus?
>>
>> I guess this requires manual configuration of the on campus prefix,
>> right?
>>
>> But if this is the case, wouldn't this be contradicting the proposed
>> charter requirement:
>>
>> - zero configuration of the hybrid devices
>>
>> Regards, marcelo
>>
>>
>> _______________________________________________
>> rbridge mailing list
>> [email-masked]
>> http://www.postel.org/mailman/listinfo/rbridge
>>
>>
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://www.postel.org/mailman/listinfo/rbridge
>

Date: Tue, 01 Mar 2005 09:22:33 -0800
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] forwarding of IP packets to off-campus destiantions
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2217

The devices that have zero configuration are the RBridges. RBridges do 
not know
anything about "on-campus" or "off-campus". It's the IP nodes attached
to the cloud that know the difference, but just in the way that IP nodes 
have
always acted. The IP nodes will decide if the target is "their 
neighbor", i.e.,
on-campus, the way they have always done.

It certainly wasn't the intention that RBridges know the on-campus IP 
prefix, but
it might have been discussed when discussing variations on the design. 
At any
rate, it isn't the intention now.

The design now is that RBridges will forward all data packets
based on the layer 2 destination.
IP nodes will fill in the layer 2 destination as the MAC address they 
receive in an
ARP/ND reply (if the target is deemed by the IP node as on-campus), or to
the layer 2 address of an IP router (if the IP source node deems that 
the target is
off-campus).

But RBridges won't know the difference as to whether the node they are 
delivering
the packet to is an IP router or the actual destination.

Hope that answered your question. I know I had written something about 
what would
happen if RBridges attempted to avoid encapsulation with IP packets, and 
why that
would be hard (because they'd have to forward based on the layer 2 
header when
the packet was off-campus), but that was intended only to explain why 
it's better if
they always forward based on the layer 2 destination. So, sorry for the 
confusion...

Radia

marcelo bagnulo braun wrote:

>Hi,
>
>i have one question regarding the forwarding of IP packets to 
>off-campus destiantions
>
>AFAIU, the rbrdiges will forward differently packets addressed to off 
>campus destiantions that those whose destiantion is on-campus.
>
>My question is how do they know if a packet destination is on campus or 
>off campus?
>
>I guess this requires manual configuration of the on campus prefix, 
>right?
>
>But if this is the case, wouldn't this be contradicting the proposed 
>charter requirement:
>
>- zero configuration of the hybrid devices
>
>Regards, marcelo
>
>
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>

To: "Developing a hybrid router/bridge." <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 1 Mar 2005 17:25:53 +0100
Subject: [rbridge] forwarding of IP packets to off-campus destiantions
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 546

Hi,

i have one question regarding the forwarding of IP packets to 
off-campus destiantions

AFAIU, the rbrdiges will forward differently packets addressed to off 
campus destiantions that those whose destiantion is on-campus.

My question is how do they know if a packet destination is on campus or 
off campus?

I guess this requires manual configuration of the on campus prefix, 
right?

But if this is the case, wouldn't this be contradicting the proposed 
charter requirement:

- zero configuration of the hybrid devices

Regards, marcelo