[rbridge] End station discovery/liveness detection

[touch at ISI.EDU (Joe Touch)]

CHO, JAI HYUNG wrote:
>  
> 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? 

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.

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

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.

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

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?

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

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.

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

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

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

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

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

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

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

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

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

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

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

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


Received: from [206.117.27.252] (host252.tethered.net [206.117.27.252]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2IFELq00703; Fri, 18 Mar 2005 07:14:21 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 18 Mar 2005 07:13:59 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "CHO, JAI HYUNG" <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
References: <1d30c01c52b96$d89a0b30$[e-mail]>
In-Reply-To: <1d30c01c52b96$d89a0b30$[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFC7464FF9C6C389000372FE1"
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] End station discovery/liveness detection
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 18 Mar 2005 15:15:40 -0000
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



CHO, JAI HYUNG wrote:
>  
> 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? 

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.

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

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.

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

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?

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

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.

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

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

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

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

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

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

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

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

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

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

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

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"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCOvA3E5f5cImnZrsRAlvOAJwIabq65udDHTtPN0DF1XOu7OtHNQCeI/bZ
sdkWlCqyyHQp52/qnzIH/7U=
=IISo
-----END PGP SIGNATURE-----

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


Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2I8ijq07031 for <[e-mail]>; Fri, 18 Mar 2005 00:44:45 -0800 (PST)
Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC;  Fri, 18 Mar 2005 17:45:33 +0900
priority: normal
Thread-Topic: Re: [rbridge] End station discovery/liveness detection
thread-index: AcUrltiXtOcaF5s5SFG0KqzcZVfecw==
From: "CHO, JAI HYUNG" <[e-mail]>
To: <[e-mail]>
Cc: 
Date: Fri, 18 Mar 2005 17:45:32 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Message-ID: <1d30c01c52b96$d89a0b30$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft CDO for Exchange 2000
Content-Class: urn:content-classes:message
Importance: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181
X-OriginalArrivalTime: 18 Mar 2005 08:45:33.0102 (UTC) FILETIME=[D8B904E0:01C52B96]
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] End station discovery/liveness detection
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "CHO, JAI HYUNG" <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 18 Mar 2005 08:45:23 -0000
Status: RO
Content-Length: 8808

 
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 :       [phone]
oversea: [phone]
fax:         [phone] 










Received: from [70.212.14.185] (185.sub-70-212-14.myvzw.com [70.212.14.185]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2HGQAq28073; Thu, 17 Mar 2005 08:26:11 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 17 Mar 2005 08:26:00 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "CHO, JAI HYUNG" <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
References: <11f1701c52ac8$3db67280$[e-mail]>
In-Reply-To: <11f1701c52ac8$3db67280$[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC303B6F71839B74E484DD819"
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] End station discovery/liveness detection
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 17 Mar 2005 16:27:18 -0000
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.. 
> 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.

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


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

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

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

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

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!

---

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). 
> 
> 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)...

> "......  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.

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

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

> 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

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCOa+YE5f5cImnZrsRAueCAKD067zF4trEm0ZeZfQa1ddRTktSWgCfZYMn
aJkG5gmkWL5ZEZoc7LCbguU=
=W5Tr
-----END PGP SIGNATURE-----

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


Received: from [70.212.14.185] (185.sub-70-212-14.myvzw.com [70.212.14.185]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2HFttq20558; Thu, 17 Mar 2005 07:55:56 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 17 Mar 2005 07:55:50 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: =?EUC-KR?B?wbbA58f8?= <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
References: <11fb501c52ac8$a7e75a70$[e-mail]>
In-Reply-To: <11fb501c52ac8$a7e75a70$[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7718E711C259045F2679FCB2"
Content-Transfer-Encoding: 8bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] text on hop-count in updated charter
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 17 Mar 2005 15:56:24 -0000
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"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCOaiGE5f5cImnZrsRAhwfAJ4x4gnfrCf5+qnmcUwMM7PtbAtxXwCg6O84
fjAf4AQDUN1YHXY/kmvsPLo=
=B8JM
-----END PGP SIGNATURE-----

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


Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2H88jq08611 for <[e-mail]>; Thu, 17 Mar 2005 00:08:45 -0800 (PST)
Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Thu, 17 Mar 2005 17:09:35 +0900
Priority: normal
X-ReadCheckName: rbridge%40postel.org
Thread-Topic: Re: [rbridge] text on hop-count in updated charter
X-ReadCheckMessageID: <[e-mail]>
thread-index: AcUqyKflTldNMxW7SsiFSWqJbPVz2Q==
Content-Transfer-Encoding: 7bit
From: =?ks_c_5601-1987?B?wbbA58f8?= <[e-mail]>
To: <[e-mail]>
Cc: 
Date: Thu, 17 Mar 2005 17:09:34 +0900
Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCBCY06x4rz6utC8rsbALCC047Tn?=
Message-ID: <11fb501c52ac8$a7e75a70$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_11FB6_01C52B14.17CF0270"
X-Mailer: Microsoft CDO for Exchange 2000
Content-Class: urn:content-classes:message
Importance: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181
X-OriginalArrivalTime: 17 Mar 2005 08:09:35.0074 (UTC) FILETIME=[A8065420:01C52AC8]
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] text on hop-count in updated charter
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: =?ks_c_5601-1987?B?wbbA58f8?= <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 17 Mar 2005 08:09:47 -0000
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

PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt
RkFNSUxZOiCxvLiyIj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkRlYXIg
Sm9lIFRvdWNoLDwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jmd0
OzxCUj4mZ3Q7Jmd0OyZndDtXaXRoIHRoaXMgcmVnYXJkLCBJIHdvdWxkIGxp
a2UgdG8gYXNrIHdoYXQgYXJlIHRoZSBzZXJ2aWNlIG9iamVjdGl2ZXM8QlI+
Jmd0OyZndDsmZ3Q7b2YgcmJyaWRnZSBnaXZlbiB0byBlbmQtdXNlcnM/IEl0
IHNlZW1zIHJicmlkZ2UgbGFja3MgY29tbWVyY2lhbGx5PEJSPiZndDsmZ3Q7
Jmd0O21lYW5pbmdmdWwgYmVuZWZpdHMgdG8gZW5kLXVzZXJzLCBzdWNoIGFz
IFFvUywgYXV0aGVudGljYXRpb24sPEJSPiZndDsmZ3Q7Jmd0O21ldGVyaW5n
ICZhbXA7IGNoYXJnaW5nLCBldGMuPEJSPiZndDsmZ3Q7Jmd0O0hvdyB3aWxs
IHJicmlkZ2UgcHJvdGVjdCBndWFyYW50ZWVkIGZsb3dzIGZyb20gYWJ1c2l2
ZSB1c2VyIG9yPEJSPiZndDsmZ3Q7Jmd0O21hc3F1ZXJhZGluZyBvZiBzZXJ2
aWNlIGNsYXNzPzxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0O1BsZWFzZSBiZWdp
biBieSBleHBsYWluaW5nIGhvdyBhbnkgb2YgdGhlc2UgYXJlIGN1cnJlbnRs
eSBwcm92aWRlZCBieTxCUj4mZ3Q7Jmd0O2FyYml0cmFyeSBsaW5rIGxheWVy
cy48QlI+Jmd0OzxCUj4mZ3Q7Jmd0OyBRb1Mgc2VydmljZSBpcyB0aGUgcHJp
bWUgcmVxdWlzaXRlIGluIGFueSBvZiB1cGNvbWluZyBuZXR3b3JrLjxCUj4m
Z3Q7Jmd0OyBSRkMyODE0LCAyODE1LCAyODE2IHByb3Bvc2VzIGEgUlNWUCBh
cHBsaWNhdGlvbiBvdmVyIDgwMiBuZXR3b3JrczxCUj4mZ3Q7Jmd0OyAoaS5l
LiBicmlkZ2VkIGxvY2FsIG5ldHdvcmspIGZvciByZXNvdXJjZSBjb250cm9s
LjxCUj4mZ3Q7Jmd0OyBBbHRob3VnaCBub3Qgd2lkZWx5IGRlcGxveWVkLCBz
b21lIGNvbXBhbnk8QlI+Jmd0OyZndDsgc3VwcG9ydHMgdXNlIG9mIFJTVlAg
aW4gbG9jYWwgbmV0d29yay4gSWYgeW91IGFyZSBpbnRlcmVzdGVkLCB5b3Ug
bWF5IHJlYWQ8QlI+Jmd0OyZndDsgPEJSPiZndDsmZ3Q7IDxBIGhyZWY9Imh0
dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWphaWh5
dW5nLWNjYW1wLWxzZWZyYW1ld29yay0wMC50eHQiPmh0dHA6Ly93d3cuaWV0
Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWphaWh5dW5nLWNjYW1wLWxz
ZWZyYW1ld29yay0wMC50eHQ8L0E+PEJSPiZndDsmZ3Q7IDxBIGhyZWY9Imh0
dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWphaWh5
dW5nLWNjYW1wLWFycHNpZ25hbC0wMC50eHQiPmh0dHA6Ly93d3cuaWV0Zi5v
cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWphaWh5dW5nLWNjYW1wLWFycHNp
Z25hbC0wMC50eHQ8L0E+PEJSPiZndDsmZ3Q7PEJSPiZndDsmZ3Q7IFdoYXQg
cmJyaWRnZSBsYWNrcyBpcyB0aGUgUW9TIHNlcnZpY2UuPEJSPiZndDs8QlI+
Jmd0O1RoZXNlIGFyZSBfcHJvcG9zZWRfIGFwcGxpY2F0aW9ucyBvZiBSU1ZQ
IG92ZXIgODAyLCBhcyB3ZWxsIGFzIF9kcmFmdF88QlI+Jmd0O2RvY3VtZW50
cywgc28gSU1PIGJyaWRnZXMgbGFjayB0aGlzIHNlcnZpY2UgcmlnaHQgbm93
LjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEJSPlRoZSBSRkNz
IGFyZSBwcm9wb3NlZCBzdGFuZGFyZCBmb3IgcmVzb3VyY2UgY29udHJvbCBv
dmVyIGJyaWRnZWQgbmV0d29yay48QlI+UkZDMjgxNiBoYXMgUW9TIG1lY2hh
bmlzbSBvbiBicmlkZ2UsIElFRUUgcGJyaWRnZSBhbHNvIGhhcyBjbGFzcyBv
ZiBzZXJ2aWNlLDxCUj5idXQgcmJyaWRnZSBkb2Vzbid0IGhhdmUgc3VjaCBj
b25jZXB0IG9mIHNlcnZpY2UgZGlmZmVyZW50aWF0aW9uLjxCUj5zaW1wbGUg
aXRlbSB0byBhZGQgd2hlbiBwZW9wbGUgY29tcGFyZSByZWxhdGVkIHdvcmtz
IG9uIGJyaWRnZSBRb1Ohpi48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8
RElWPjxCUj4mZ3Q7Jmd0OyBJZiByYnJpZGdlIGlzIGFpbWluZyB0aGUgcGxh
Y2Ugb2Y8QlI+Jmd0OyZndDsgbmV4dC1nZW5lcmF0aW9uIGJyaWRnZSB0byBy
ZXBsYWNlIGxlZ2FjeSBicmlkZ2VzLCByYnJpZGdlIG11c3Q8QlI+Jmd0OyZn
dDsgaW5jbHVkZSBzdWNoIGluZHVzdHJ5IHJlcXVpcmVtZW50IHdoZXRoZXIg
dGhpcyBncm91cCBsaWtlcyBpdCBvciBub3QuPEJSPiZndDs8QlI+Jmd0O0kg
ZG9uJ3Qgc2VlIGEgc2NyZWFtaW5nIGluZHVzdHJ5IHJlcXVpcmVtZW50IGZv
ciB0aGlzIGF0IHRoZSA4MDIgbGV2ZWwsPEJSPiZndDt3aGVyZSBvdmVycHJv
dmlzaW9uaW5nIGlzIHRoZSBub3JtLiBOb3RlIHRoYXQgcmJyaWRnZXMgd291
bGQgaGF2ZSBtdWNoPEJSPiZndDtoaWdoZXIgaW50ZXJuYWwgYmFuZHdpZHRo
LCBiZWNhdXNlIHRoZXkgY2FuIHVzZSBtdWx0aXBsZSBpbnRlcm5hbCBwYXRo
czxCUj4mZ3Q7cmF0aGVyIHRoYW4ganVzdCBhIHNpbmdsZSBzcGFubmluZyB0
cmVlLCBzbyBhbXBsaWZ5IHRoZSBvdmVycHJvdmlzaW9uaW5nPEJSPiZndDt0
aGF0IGlzIGFscmVhZHkgaW4gdXNlLjwvRElWPg0KPERJVj48QlI+aGF2ZSB5
b3UgZXZlciB0YWxrZWQgd2l0aCBhY3R1YWwgaW5kdXN0cnk/PEJSPmhvdyBt
dWNoIG92ZXItcHJvdmlzaW9uaW5nIGRvIHlvdSB0aGluayB5b3UgY2FuICpn
dWFyYW50ZWUqIHJlbGlhYmxlPEJSPmNvbW1lcmNpYWwgc2VydmljZSB2aWEg
Y2FtcHVzIG5ldHdvcmsuIDxCUj50aGUgY29ycmVjdCBhbnN3ZXIgaXMgTk9U
IEFUIEFMTCwgYmVjYXVzZSB5b3UgaGF2ZSBOTyBzdWNoIG1lY2hhbmlzbS48
QlI+aW4gZnV0dXJlIG5ldHdvcmssIHBlb3BsZSB3aWxsIHJlY2VpdmUgVFYs
IHZvaWNlIGFuZCBkYXRhIHNlcnZpY2UgdmlhPEJSPnNpbmdsZSBpbnRlZ3Jh
dGVkIG5ldHdvcmsuIElTUHMgd2lsbCBjaGFyZ2UgYnkgdXNhZ2UgcGVyIHNl
cnZpY2UuPEJSPml0IGlzIG9idmlvdXMgdGhhdCBuZXR3b3JrIGJ1aWxkZXJz
IHdpbGwgY2hvb3NlIGVxdWlwbWVudCB0aGF0IGhhczxCUj5hdCBsZWFzdCBh
IFFvUyBzb2x1dGlvbi4geW91IGNhbid0IHNlbGwgYW55dGhpbmcgd2l0aG91
dCBRb1MgaW4gZnV0dXJlIG1hcmtldC48QlI+b3Zlci1wcm92aXNpb25pbmcg
aXMgc2ltcGx5IG5vdCBhbiBhbnN3ZXIgdG8gbWFya2V0LjwvRElWPg0KPERJ
Vj48QlI+Jmd0OyZndDsgT3RoZXJ3aXNlLCBJRUVFIHBicmlkZ2Ugb3Igb3Ro
ZXIgYWx0ZXJuYXRpdmVzIHdpbGwgYmUgZmF2b3JlZCBieSBtYXJrZXQuPEJS
PiZndDsmZ3Q7IENvbnRyYXN0IHRvIG9yaWdpbmFsIHNjb3BlIG9mIHdvcmsg
b24gY2FtcHVzIG5ldHdvcmssIEkgdGhpbmsgcmJyaWRnZTxCUj4mZ3Q7Jmd0
OyBpcyBtb3JlIG1lYW5pbmdmdWwgdG8gbWV0cm8tRXRoZXJuZXQuIFRoZXJl
J3MgY2xlYXIgbmVlZCBmb3IgTDIgc29sdXRpb24uPEJSPiZndDsmZ3Q7IHJi
cmlkZ2UgbWF5IGhlbHAgSVNQcyByZWR1Y2luZyBDQVBFWCBpZiBpdCBpcyBj
aGVhcGVyIHRoYW4gTDMgc3dpdGNoZXMuPEJSPiZndDsmZ3Q7IHJicmlkZ2Ug
bWF5IGFsc28gaGVscCB0byByZWR1Y2UgT1BFWCBpZiBtYW5hZ2VtZW50IGlz
IHNpbXBsZS48QlI+Jmd0OzxCUj4mZ3Q7VGhlIHByaW1hcnkgcmVhc29uIHRv
IHVzZSBhbiByYnJpZGdlIHZzLiBhbiBMMyBkZXZpY2UgaXMgdG8gYXZvaWQ8
QlI+Jmd0O3JlbnVtYmVyaW5nIHdoaWxlIG1vdmluZy4gSWYgdGhhdCBpc24n
dCBhIGdvYWwsIElNTywgYW4gTDMgZGV2aWNlIGlzPEJSPiZndDttb3JlIHVz
ZWZ1bCBiZWNhdXNlIHJvdXRpbmcgdGFibGVzIGNhbiBiZSBtb3JlIGVhc2ls
eSBwYXJ0aXRpb25lZCBhbmQ8QlI+Jmd0O2Jyb2FkY2FzdHMgYXZvaWRlZC48
QlI+Jmd0OzwvRElWPg0KPERJVj48QlI+ZG8geW91IHRoaW5rIG5ldHdvcmsg
YnVpbGRlcnMgd2lsbCByZXBsYWNlIEwzIHN3aXRjaCB0byByYnJpZGdlPEJS
PmJlY2F1c2UgaW4tY2FtcHVzIG1vYmlsaXR5IGluIHJicmlkZ2VkIG5ldHdv
cmsgaXMgYmV0dGVyIHRoYW4gPEJSPmFueSBtb2JpbGl0eSBzb2x1dGlvbiBp
bXBsZW1lbnRlZCBpbiBMMyBwcm9kdWN0PzxCUj55b3UgaGF2ZW4ndCBwcm9w
b3NlZCBhbnkgbW9iaWxpdHkgbWVjaGFuaXNtIHRoYXQgY2FuIGNvbnZpbmNl
PEJSPnBlb3BsZSByYnJpZGdlIG1vYmlsaXR5IGlzIHN1cGVyaW9yIHRvIG1v
YmlsZSBJUC48QlI+VGhlIGxhc3QgZmFjdG9yIGRldGVybWluaW5nIG1hcmtl
dCBpcyBhbHdheXMgbW9uZXkuIDxCUj5JZiBpdCBpcyBub3QgY2hlYXBlciwg
aXQgY2FuJ3QgcmVwbGFjZSBzb21ldGhpbmcuPEJSPmJ1dCBpZiBpdCBkb2Vz
bid0IGhhdmUgYSBmdW5jdGlvbiwgaXQgbWF5IHN0aWxsIHJlcGxhY2UgaWYg
aXQgaXMgY2hlYXBlci48L0RJVj4NCjxESVY+PEJSPiZndDsmZ3Q7IEl0IHdp
bGw8QlI+Jmd0OyZndDsgZ2l2ZSBncmVhdCBwcm9maXQgdG8gSVNQIGlmIHJi
cmlkZ2UgaGFzIGEgY2FwYWJpbGl0eSB0byBwcm92aWRlIFFvUzxCUj4mZ3Q7
Jmd0OyBzZXJ2aWNlIGFuZCBjaGFyZ2UgcGVyIHVzYWdlLjxCUj4mZ3Q7PEJS
PiZndDtCZWNhdXNlIHRoZXkncmUgY3VycmVudGx5IHByb3ZpZGluZyB0aGF0
IHNlcnZpY2UgYW5kIHRoZXkgd2FudCBpdCB0bzxCUj4mZ3Q7c2NhbGU/IFdo
YXQgSSBzZWUgaXMgSVNQcyBub3Qgb2ZmZXJpbmcgUW9TIC0gYnV0IG5vdCBi
ZWNhdXNlIGJyaWRnZXM8QlI+Jmd0O2Rvbid0IHN1cHBvcnQgaXQuPEJSPiZn
dDs8L0RJVj4NCjxESVY+PEJSPnlvdSBrZWVwIHRoaW5raW5nIHJicmlkZ2Ug
Y2FuIG9ubHkgYmUgYnJpZGdlLCBidXQgSSBrZWVwIHNheWluZzxCUj5yYnJp
ZGdlIG11c3QgYmUgY2FtcHVzIGJhY2tib25lIG1hY2hpbmUuPEJSPnlvdSBr
ZWVwIHNheWluZyByYnJpZGdlIGRvZXNuJ3QgbmVlZCBRb1MgYmVjYXVzZSBi
cmlkZ2VzIGRvbid0IGhhdmUuPEJSPmhvd2V2ZXIgSSBrZWVwIHNheWluZyBy
YnJpZGdlIG5lZWQgUW9TIGJlY2F1c2UgYmFja2JvbmUgcm91dGVyczxCUj5o
YXZlIFFvUy48QlI+YW5kIEkgc2F5IHRoYXQgaWYgcmJyaWRnZSBjYW4ndCBy
ZXBsYWNlIGJhY2tib25lIHJvdXRlcnMsIG5vIG1hcmtldCBhdCBhbGwuPC9E
SVY+DQo8RElWPjxCUj4mZ3Q7Jmd0OyBUaGUgcmVxdWlyZW1lbnRzIGluIHBy
b3ZpZGVyIG5ldHdvcms8QlI+Jmd0OyZndDsgYXJlIGEgbG90IGRpZmZlcmVu
dCB0aGFuIGNhbXB1cyBuZXR3b3JrLiBJdCBuZWVkcyB0byBiZSBkZWZpbmVk
IGluIHRoaXM8QlI+Jmd0OyZndDsgZ3JvdXAgcHJpb3IgdG8gd29yay48QlI+
Jmd0OzxCUj4mZ3Q7SSBkb24ndCBhZ3JlZSB0aGF0IEwyIHN5c3RlbXMgcnVu
IGFzIGEgc2VydmljZSBuZWVkIGZ1bmRhbWVudGFsbHk8QlI+Jmd0O2RpZmZl
cmVudCBjYXBhYmlsaXRlcyB0aGFuIEwyIHN5c3RlbXMgcnVuIGJ5IHRoZWly
IHVzZXIgb3JnYW5pemF0aW9uLjwvRElWPg0KPERJVj48QlI+cmVhZCBhbnkg
bGlzdCBvZiBmdW5jdGlvbmFsIHJlcXVpcmVtZW50cyB3cml0dGVuIGJ5IHBy
aXZhdGUgb3JnYW5pemF0aW9uPEJSPmFuZCBjb21tZXJjaWFsIHByb3ZpZGVy
cy4gdGhleSBhcmUgYSBsb3QgZGlmZmVyZW50LjxCUj5pdCBpcyB1bmZvcnR1
bmF0ZSBJIGNhbid0IHNob3cgeW91IGV2aWRlbmNlIGJlY2F1c2UgbW9zdCBv
ZiBkb2N1bWVudHM8QlI+YXJlIGNvbmZpZGVudGlhbC4gSSBob3BlIHNvbWVv
bmUgaW4gdGhpcyBtYWlsaW5nIGxpc3QgbWF5IHNob3cgc29tZTxCUj5leGFt
cGxlLjwvRElWPg0KPERJVj48QlI+Jmd0OyZndDsmZ3Q7RnVydGhlciwgSSBo
YXZlbid0IHNlZW4gYW55b25lIGVsc2UgbWVudGlvbiBjaXJjdWl0cyBoZXJl
LiBDaXJjdWl0cyBhcmU8QlI+Jmd0OyZndDsmZ3Q7bm90IHVzZWQgZm9yIHN3
aXRjaGluZyBwYWNrZXRzIHRvIHRoZSBlbmRzeXN0ZW0gKG1heWJlIHRoYXQg
d2FzIHRoZWlyPEJSPiZndDsmZ3Q7Jmd0O2ludGVudCwgYnV0IHRoZXkncmUg
dXNlZCBtb3JlIGluIHRoZSBjb3JlIGZvciBwcm92aXNpb25pbmcpLiBSYnJp
ZGdlczxCUj4mZ3Q7Jmd0OyZndDt3b3JrIG1vcmUgYXQgdGhlIGVuZHN5c3Rl
bSwgd2hlcmUgYnJpZGdlcyB3b3JrLiBBcyBzdWNoLCBJIGRvdWJ0PEJSPiZn
dDsmZ3Q7Jmd0O2NpcmN1aXRzIHdpbGwgYmUgZWl0aGVyIGFwcHJvcHJpYXRl
IG9yIHVzZWZ1bCBhbnl3YXkuPEJSPiZndDsmZ3Q7IDxCUj4mZ3Q7Jmd0OyBJ
IGJlbGlldmUgYnkgbm93LCB5b3Ugd2lsbCBub3RpY2Ugd2hhdCAqdmlydHVh
bCBjaXJjdWl0KiB0ZWNobm9sb2d5PEJSPiZndDsmZ3Q7IEkgYW0gdHJ5aW5n
IHRvIHNheS4gVGhlIGNpcmN1aXQgSSByZWZlcnJlZCBpcyBhIGR5bmFtaWMg
KG9uLWRlbWFuZCk8QlI+Jmd0OyZndDsgZnJhbWUgdHJhbnNtaXNzaW9uIHBh
dGggZXN0YWJsaXNoZWQgYWNyb3NzIGJyaWRnZWQgbmV0d29yazxCUj4mZ3Q7
Jmd0OyB1c2luZyBhbiBpbnRlcmFjdGl2ZSBzaWduYWxpbmcgYmV0d2VlbiB0
d28gY29tbXVuaWNhdGluZyBwYXJ0eS48QlI+Jmd0OyZndDsgSW4gYnJpZGdl
ZCBuZXR3b3Jrcyw8QlI+Jmd0OzxCUj4mZ3Q7WWVzIC0gdGhhdCB3YXMgd2hh
dCBBVE0gd2FzIHN1cHBvc2VkIHRvIGJlLCBhbmQgQVRNIGlzIGJhc2ljYWxs
eSAoSU1PKTxCUj4mZ3Q7ZGVhZC4gSSBkb24ndCBiZWxpZXZlIGl0IG1ha2Vz
IHNlbnNlIHRvIGNvbnNpZGVyIE1QTFMgZm9yIG9uLWRlbWFuZCBFMkU8QlI+
Jmd0O2NpcmN1aXRzLCBidXQgcmF0aGVyIGZvciBhZ2dyZWdhdGUgcHJvdmlz
aW9uaW5nLjxCUj4mZ3Q7PEJSPiZndDtBZ2FpbiwgSSBoYXZlbid0IHNlZW4g
YW55b25lIGVsc2UgbWVudGlvbiB0aGUgdXNlIG9mIGNpcmN1aXRzIGluIGFu
PEJSPiZndDtyYnJpZGdlIHN5c3RlbS4gRXZlbiBfaWZfIHRoZXJlIHdlcmUg
aW50ZXJlc3QsIGF0IGJlc3QgYW4gcmJyaWRnZSBzeXN0ZW08QlI+Jmd0O3dv
dWxkIG5lZWQgdG8gc3VwcG9ydCBjaXJjdWl0cyBBTkQgY29udmVudGlvbmFs
IEwzIHJvdXRpbmcgaW4gaXRzIGludGVyaW9yLjxCUj4mZ3Q7PEJSPiZndDtK
b2U8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElW
Pg0KPERJVj5iZWNhdXNlIG5vLW9uZSBpbiByYnJpZGdlIGhhcyB0YWxrZWQg
YWJvdXQgUW9TLjwvRElWPg0KPERJVj48QlI+Jm5ic3A7PC9ESVY+DQo8RElW
PiZuYnNwOzwvRElWPg0KPERJVj48QlI+DQo8RElWIHN0eWxlPSJGT05ULVNJ
WkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiCxvLiyIj4NCjxESVY+DQo8RElWIHN0
eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiCxvLiyIj4NCjxE
SVY+RHIuIEphaWh5dW5nIENobzwvRElWPg0KPERJVj5FVFJJLCBLb3JlYTwv
RElWPg0KPERJVj5waG9uZSA6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IDA0MikgODYwLTU1MTQ8L0RJVj4NCjxESVY+b3ZlcnNlYTog
KzgyLTQyLTg2MC01NTE0PC9ESVY+DQo8RElWPmZheDombmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsrODIt
NDItODYxLTU1NTAmbmJzcDs8L0RJVj48L0RJVj48L0RJVj48L0RJVj4NCjxE
SVY+DQo8UD4mbmJzcDs8L1A+PC9ESVY+PC9ESVY+PC9ESVY+PGltZyBzcmM9
Ik1haWxTY2FubmVyV2ViQnVnIiB3aWR0aD0iMCIgaGVpZ2h0PSIwIiBhbHQ9
IldlYiBCdWcgZnJvbSBodHRwOi8vdW1haWwuZXRyaS5yZS5rci9FeHRlcm5h
bF9SZWFkQ2hlY2suYXNweD9lbWFpbD1yYnJpZGdlQHBvc3RlbC5vcmcmbmFt
ZT1yYnJpZGdlJTQwcG9zdGVsLm9yZyZmcm9tZW1haWw9amFpaHl1bmdAZXRy
aS5yZS5rciZtZXNzYWdlaWQ9JTNDMWI0NTBhYzEtZGViMC00YTY2LTg2MmYt
ZjhmNmMwY2YzMDIwQGV0cmkucmUua3IlM0UiIC8+

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


Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2H85nq08099 for <[e-mail]>; Thu, 17 Mar 2005 00:05:49 -0800 (PST)
Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC;  Thu, 17 Mar 2005 17:06:37 +0900
priority: normal
Thread-Topic: Re: [rbridge] End station discovery/liveness detection
thread-index: AcUqyD2VTiY9GftlSBiyrd3SiC4mSQ==
From: "CHO, JAI HYUNG" <[e-mail]>
To: <[e-mail]>
Cc: 
Date: Thu, 17 Mar 2005 17:06:36 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Message-ID: <11f1701c52ac8$3db67280$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft CDO for Exchange 2000
Content-Class: urn:content-classes:message
Importance: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181
X-OriginalArrivalTime: 17 Mar 2005 08:06:37.0806 (UTC) FILETIME=[3E5D60E0:01C52AC8]
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] End station discovery/liveness detection
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "CHO, JAI HYUNG" <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 17 Mar 2005 08:06:44 -0000
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.. 
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?

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.

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.

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.

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. 
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). 
>

For your information, the goal of Pbridge is briefly stated in section 
1.1 Scope of 802.1ad as following;

"......  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.

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

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 :       [phone]
oversea: [phone]
fax:         [phone] 










Received: from [70.213.95.219] (219.sub-70-213-95.myvzw.com [70.213.95.219]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2FEdo610232; Tue, 15 Mar 2005 06:39:50 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 15 Mar 2005 06:39:41 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "CHO, JAI HYUNG" <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
References: <2add801c52931$6267bff0$[e-mail]>
In-Reply-To: <2add801c52931$6267bff0$[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC40DC071B2E2A5D77FBD94C9"
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] End station discovery/liveness detection
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 15 Mar 2005 14:40:45 -0000
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).

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

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"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCNvOtE5f5cImnZrsRAu4EAKDmCH8Bs4ADMoqjnJGg8MYUdKoAvwCgt5uV
HtTO8pnLDWxFbx30PoPFc2Q=
=9hc2
-----END PGP SIGNATURE-----

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


Received: from [70.213.95.219] (219.sub-70-213-95.myvzw.com [70.213.95.219]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2FE20626723; Tue, 15 Mar 2005 06:02:00 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 15 Mar 2005 06:01:53 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "CHO, JAI HYUNG" <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
References: <2c88f01c5293e$36a177f0$[e-mail]>
In-Reply-To: <2c88f01c5293e$36a177f0$[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig83FF6321D5DF7EDFB43BC344"
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] text on hop-count in updated charter
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 15 Mar 2005 14:02:14 -0000
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 :       [phone]
> oversea: [phone]
> fax:         [phone] 
> 
> 
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> 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"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCNurSE5f5cImnZrsRAkL9AKCqPkK4auGodULeRFtDQ5/5RXMyCQCfWWza
6xu/LGpG9XfQ+JCLwFYpyi8=
=mMdQ
-----END PGP SIGNATURE-----

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


Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2F95E604487 for <[e-mail]>; Tue, 15 Mar 2005 01:05:14 -0800 (PST)
Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC;  Tue, 15 Mar 2005 18:06:03 +0900
priority: normal
Thread-Topic: [rbridge] text on hop-count in updated charter
thread-index: AcUpPjafxvdikXTJTiy4TN999DSgow==
From: "CHO, JAI HYUNG" <[e-mail]>
To: <[e-mail]>
Cc: 
Date: Tue, 15 Mar 2005 18:06:03 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Message-ID: <2c88f01c5293e$36a177f0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft CDO for Exchange 2000
Content-Class: urn:content-classes:message
Importance: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181
X-OriginalArrivalTime: 15 Mar 2005 09:06:03.0322 (UTC) FILETIME=[36C071A0:01C5293E]
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] text on hop-count in updated charter
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "CHO, JAI HYUNG" <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 15 Mar 2005 09:06:14 -0000
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 :       [phone]
oversea: [phone]
fax:         [phone] 







Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2F7XN608781 for <[e-mail]>; Mon, 14 Mar 2005 23:33:24 -0800 (PST)
Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC;  Tue, 15 Mar 2005 16:34:13 +0900
priority: normal
Thread-Topic: [rbridge] End station discovery/liveness detection
thread-index: AcUpMWJl3Jkd2Z2ARbaYpt+RyL9CeQ==
From: "CHO, JAI HYUNG" <[e-mail]>
To: <[e-mail]>
Cc: 
Date: Tue, 15 Mar 2005 16:34:13 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Message-ID: <2add801c52931$6267bff0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft CDO for Exchange 2000
Content-Class: urn:content-classes:message
Importance: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181
X-OriginalArrivalTime: 15 Mar 2005 07:34:13.0212 (UTC) FILETIME=[627861C0:01C52931]
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] End station discovery/liveness detection
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "CHO, JAI HYUNG" <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 15 Mar 2005 07:34:07 -0000
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 :       [phone]
oversea: [phone]
fax:         [phone] 







Received: from [166.153.56.144] (144.sub-166-153-56.myvzw.com [166.153.56.144]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2EETm613748; Mon, 14 Mar 2005 06:29:48 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 14 Mar 2005 06:29:43 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "CHO, JAI HYUNG" <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
References: <23aad01c528a0$efc83140$[e-mail]>
In-Reply-To: <23aad01c528a0$efc83140$[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5A2C41D06BB8A8BF7459CA84"
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] End station discovery/liveness detection
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 14 Mar 2005 14:30:29 -0000
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 :       [phone]
> oversea: [phone]
> fax:         [phone] 
> 
> 
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> 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"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCNZ/XE5f5cImnZrsRAlj7AKCzFK2MXdy6ajbTdyM+bojRGc609gCg8avt
eVBVB0Otiui1C+/4OVJclic=
=ibqu
-----END PGP SIGNATURE-----

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


Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2EEJO610700 for <[e-mail]>; Mon, 14 Mar 2005 06:19:24 -0800 (PST)
Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC;  Mon, 14 Mar 2005 23:20:13 +0900
priority: normal
Thread-Topic: [rbridge] End station discovery/liveness detection
thread-index: AcUooO/FjsKo+B/zS8mPCQq21fk7IA==
From: "CHO, JAI HYUNG" <[e-mail]>
To: <[e-mail]>
Cc: 
Date: Mon, 14 Mar 2005 23:20:13 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Message-ID: <23aad01c528a0$efc83140$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft CDO for Exchange 2000
Content-Class: urn:content-classes:message
Importance: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181
X-OriginalArrivalTime: 14 Mar 2005 14:20:13.0455 (UTC) FILETIME=[EFE4B9F0:01C528A0]
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] End station discovery/liveness detection
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "CHO, JAI HYUNG" <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 14 Mar 2005 14:20:00 -0000
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 :       [phone]
oversea: [phone]
fax:         [phone] 







Received: from [70.212.15.174] (174.sub-70-212-15.myvzw.com [70.212.15.174]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2EDDj618508; Mon, 14 Mar 2005 05:13:45 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 14 Mar 2005 05:13:40 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "CHO, JAI HYUNG" <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
References: <22a4b01c5287c$b1164690$[e-mail]>
In-Reply-To: <22a4b01c5287c$b1164690$[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig56BDD6D0842FC760E227EB18"
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] text on hop-count in updated charter
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 14 Mar 2005 13:14:05 -0000
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"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCNY4FE5f5cImnZrsRAhAfAJ9NpcQTJnX8NvA8eSv5gbvpSGUucgCdE/cF
aBpGz2KqjIAki2+KuHBaUx0=
=1Z8f
-----END PGP SIGNATURE-----

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


Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2E9xv617513 for <[e-mail]>; Mon, 14 Mar 2005 01:59:57 -0800 (PST)
Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC;  Mon, 14 Mar 2005 19:00:46 +0900
priority: normal
Thread-Topic: [rbridge] text on hop-count in updated charter
thread-index: AcUofLETWKzjavOASgCAa8arKasP3g==
From: "CHO, JAI HYUNG" <[e-mail]>
To: <[e-mail]>
Cc: 
Date: Mon, 14 Mar 2005 19:00:46 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Message-ID: <22a4b01c5287c$b1164690$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft CDO for Exchange 2000
Content-Class: urn:content-classes:message
Importance: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181
X-OriginalArrivalTime: 14 Mar 2005 10:00:46.0404 (UTC) FILETIME=[B1354040:01C5287C]
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] text on hop-count in updated charter
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "CHO, JAI HYUNG" <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 14 Mar 2005 10:01:25 -0000
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 :       [phone]
oversea: [phone]
fax:         [phone] 







Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2E89G612355 for <[e-mail]>; Mon, 14 Mar 2005 00:09:16 -0800 (PST)
Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC;  Mon, 14 Mar 2005 17:10:04 +0900
priority: normal
Thread-Topic: [rbridge] text on hop-count in updated charter
thread-index: AcUobTpQArU/KwLzRKeC6Hp+Bf2qiQ==
From: "CHO, JAI HYUNG" <[e-mail]>
To: <[e-mail]>
Cc: 
Date: Mon, 14 Mar 2005 17:10:04 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Message-ID: <20d1e01c5286d$3a52ac10$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft CDO for Exchange 2000
Content-Class: urn:content-classes:message
Importance: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181
X-OriginalArrivalTime: 14 Mar 2005 08:10:04.0700 (UTC) FILETIME=[3A71A5C0:01C5286D]
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] text on hop-count in updated charter
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "CHO, JAI HYUNG" <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 14 Mar 2005 08:10:33 -0000
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 :       [phone]
oversea: [phone]
fax:         [phone] 







Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2C3it611576 for <[e-mail]>; Fri, 11 Mar 2005 19:44:55 -0800 (PST)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j2C3isRr022091 for <[e-mail]>; Fri, 11 Mar 2005 20:44:54 -0700 (MST)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Fri, 11 Mar 2005 22:44:54 -0500 (EST)
Received: from sun.com (vpn-129-150-25-20.SFBay.Sun.COM [129.150.25.20]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Fri, 11 Mar 2005 22:44:54 -0500 (EST)
Date: Fri, 11 Mar 2005 19:44:54 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
References: <[e-mail]> <[e-mail]>
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Yes, each VLAN must be a different IP subnet
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 12 Mar 2005 03:45:47 -0000
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



Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2BJsb629453 for <[e-mail]>; Fri, 11 Mar 2005 11:54:37 -0800 (PST)
Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <[e-mail]> for [e-mail]; Sat, 12 Mar 2005 06:54:30 +1100
Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 14B93AB542	for <[e-mail]>; Sat, 12 Mar 2005 06:54:30 +1100 (EST)
Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by curly.its.monash.edu.au (Postfix) with ESMTP id 014704FB07	for <[e-mail]>; Sat, 12 Mar 2005 06:54:30 +1100 (EST)
Received: from [130.129.131.162] by mail-store-2.its.monash.edu.au (mshttpd) ; Fri, 11 Mar 2005 19:54:29 +0000 (GMT)
Date: Fri, 11 Mar 2005 19:54:29 +0000 (GMT)
From: Greg Daley <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 Patch 2 (built Jul 14 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Possible new attacks to add for security considerations document
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 11 Mar 2005 19:54:40 -0000
Status: RO
Content-Length: 1090

----- Original Message -----
From: Erik Nordmark <[e-mail]>
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


Received: from [70.212.252.211] (211.sub-70-212-252.myvzw.com [70.212.252.211]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2BF7e626820; Fri, 11 Mar 2005 07:07:40 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 10 Mar 2005 19:39:07 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]>	<[e-mail]> <p06200708be4df8abad1a@[10.0.0.171]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD8DB4EB2C096012CD4139F55"
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Forwarding inside rbridge cloud
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 11 Mar 2005 15:08:43 -0000
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
> [e-mail]
> 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"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCMRLcE5f5cImnZrsRAigLAKCc8WtrW6jQR3+7/TWNFuuANUPRwACgs+Xo
+7NynGCB71/aTn7IWXgVcWs=
=Gx02
-----END PGP SIGNATURE-----

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



Received: from [70.212.252.211] (211.sub-70-212-252.myvzw.com [70.212.252.211]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2BF7O626798; Fri, 11 Mar 2005 07:07:25 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 10 Mar 2005 19:32:58 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Alex Zinin <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]> <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5112C205B7DF9DF4A90D42B3"
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: Radia Perlman <[e-mail]>, Russ White <[e-mail]>
Subject: Re: [rbridge] End station discovery/liveness detection
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 11 Mar 2005 15:08:15 -0000
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"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCMRFqE5f5cImnZrsRAhcWAKCFVUMzn3Zl79I21+tC8P9OtsYXxQCgjfIB
7QAWBF0CdlJE59bM7GFMOR8=
=IBbH
-----END PGP SIGNATURE-----

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



Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2B3BL614990 for <[e-mail]>; Thu, 10 Mar 2005 19:11:21 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.82.37]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j2B3AuX8004484 for <[e-mail]>; Thu, 10 Mar 2005 20:10:57 -0700 (MST)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j2B3AhJI450778; Thu, 10 Mar 2005 19:10:51 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 10 Mar 2005 19:10:20 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Possible new attacks to add for security considerations document
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 11 Mar 2005 03:11:37 -0000
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


Received: from [70.212.234.234] (234.sub-70-212-234.myvzw.com [70.212.234.234]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2B0QA619436; Thu, 10 Mar 2005 16:26:10 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 10 Mar 2005 16:26:03 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: =?EUC-KR?B?wbbA58f8?= <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
References: <b2ee01c525c9$9bf92da0$[e-mail]>
In-Reply-To: <b2ee01c525c9$9bf92da0$[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig80612167F173F9F25861097A"
Content-Transfer-Encoding: 8bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] text on hop-count in updated charter
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 11 Mar 2005 00:26:41 -0000
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 :       [phone]
> oversea: [phone]
> fax:         [phone]
> 
> 
> 
> 
> 
> Web Bug from MailScannerWebBug
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> 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"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCMOWbE5f5cImnZrsRAmRRAKCxQYO9EJkYs7/9ptPHzSAU6xR5twCfZg/h
2/HMNSyuTJ9eUTVIQuHzAmo=
=MFKJ
-----END PGP SIGNATURE-----

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


Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2ANX0627850 for <[e-mail]>; Thu, 10 Mar 2005 15:33:00 -0800 (PST)
Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Fri, 11 Mar 2005 08:33:48 +0900
X-ReadCheckName: rbridge%40postel.org
X-ReadCheckMessageID: <[e-mail]>
From: =?ks_c_5601-1987?B?wbbA58f8?= <[e-mail]>
To: <[e-mail]>
Cc: 
Date: Fri, 11 Mar 2005 08:33:48 +0900
Message-ID: <b2ee01c525c9$9bf92da0$[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft CDO for Exchange 2000
Priority: normal
Thread-Index: AcUlpJNKhimblSh3Q6G6Kq5qsqhOqwAGt5sIAAKKkL4=
Thread-Topic: [rbridge]text on hop-count in updated charter 
Content-Type: multipart/alternative; boundary="----=_NextPart_000_B161_01C5260A.E1B08E60"
Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCBCY06x4rz6utC8rsbALCC047Tn?=
MIME-Version: 1.0
Content-class: urn:content-classes:message
Importance: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181
X-OriginalArrivalTime: 10 Mar 2005 23:33:48.0741 (UTC) FILETIME=[9C182750:01C525C9]
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] text on hop-count in updated charter
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: =?ks_c_5601-1987?B?wbbA58f8?= <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 10 Mar 2005 23:33:36 -0000
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

PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt
RkFNSUxZOiCxvLiyIj4NCjxESVY+DQo8RElWIHN0eWxlPSJGT05ULVNJWkU6
IDEwcHQ7IEZPTlQtRkFNSUxZOiCxvLiyIj4NCjxESVY+DQo8RElWPjxGT05U
IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+PEZPTlQgc2l6ZT0yPjwvRk9O
VD48L0RJVj48Rk9OVCBzaXplPTI+PC9GT05UPjwvRElWPg0KPERJViBzdHls
ZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogsby4siI+PEZPTlQg
c2l6ZT0yPg0KPFA+RGVhciBKb2UgVG91Y2g8L1A+DQo8UD4mbmJzcDs8L1A+
DQo8UD5wbGVhc2UgcmVhZCBmb2xsb3dpbmdzIDwvUD4NCjxQPjxCUj48QlI+
fCBIb3Bjb3VudHMgYXJlIHJlcXVpcmVkIHdoZXJlIHJvdXRpbmcgaXMgbG9j
YWxseSB1cGRhdGVkOyBpbiB0aG9zZSBjYXNlcyw8QlI+fCB0aGUgZ2xvYmFs
IHJvdXRpbmcgc3RhdGUgbWF5IHRlbXBvcmFyaWx5IHBhc3MgdGhyb3VnaCBj
b25maWd1cmF0aW9uczxCUj58IHRoYXQgaGF2ZSB0cmFuc2llbnQgcm91dGlu
ZyBsb29wcy48QlI+PC9QPg0KPFA+Jm5ic3A7PC9QPg0KPFA+PEJSPkkgYmVs
aWV2ZSB5b3UgYXJlIGNvbmZpbmluZyBhcHBsaWNhYmxlIHJvdXRpbmcgdGVj
aG5vbG9neSZuYnNwO2p1c3QgaW48L1A+DQo8UD5saW5rLXN0YXR1cyBwcm90
b2NvbHMuIEkgdGhvdWdodCBUUklMTCBpcyBzdGlsbCBvcGVuIHRvICp0aGUg
dGhpcmQgd2F5KiBvZjwvUD4NCjxQPmRpc3RyaWJ1dGluZyByb3V0aW5nIGlu
Zm9ybWF0aW9uLiBJZiB0aGUgY2hhcnRlciBkb2Vzbid0IGxpbWl0IHRoZSBj
aG9pY2Ugb2Y8L1A+DQo8UD5yb3V0aW5nIGFsZ29yaXRobSwgdGhlcmUgYXJl
IHNvbWUgZGlmZmVyZW50IHJvdXRpbmcgYWxnb3JpdGhtcyB3ZSBjYW48L1A+
DQo8UD5jb25zaWRlci48L1A+DQo8UD5JIGFtIHdvbmRlcmluZy4uLiwgaWYm
bmJzcDtUUklMTCZuYnNwO21heSBnaXZlIHVwIGxpbmstc3RhdHVzIGFsZ29y
aXRobSBhbmQgPC9QPg0KPFA+d2lsbGluZyB0byBleHBlcmltZW50IHlldCB1
bmtub3duIHJvdXRpbmcgYWxnb3JpdGhtLCAuLiBpZiB0aGVyZSBpcyBhPC9Q
Pg0KPFA+Y2xlYXIgYmVuZWZpdCBmcm9tIG5ldyBzb2x1dGlvbi48L1A+DQo8
UD4uLi4gb3IgaXMgdGhlcmUgYSByZWFzb24mbmJzcDtwZW9wbGUgc3RpY2sm
bmJzcDt0byBJUy1JUz88L1A+DQo8UD4mbmJzcDs8L1A+DQo8UD5pZiBpdCBp
cyBub3QuLi4uLCBJIHRoaW5rJm5ic3A7IChyb3V0aW5nIHVwZGF0ZSZuYnNw
Oz0gbG9vcGluZykmbmJzcDsgaXMgbm90IGFsd2F5cyA8L1A+DQo8UD5jb3Jy
ZWN0IGFzc3VtcHRpb24gdG8gYWxsIHJvdXRpbmcgbWV0aG9kLjwvUD4NCjxQ
PiZuYnNwOzwvUD4NCjxQPjxCUj58IEFUTS1NUExTIGlzIGEgY2lyY3VpdC1v
cmllbnRlZCB0ZWNobm9sb2d5IChvbiBib3RoIGNvdW50cykuIFRoZSBjdXJy
ZW50PEJSPnwgY2hhcnRlciBkb2Vzbid0IHdhbnQgdG8gYXNzdW1lIG9ubHkg
Y2lyY3VpdHMgaW5zaWRlIGFuIHJicmlkZ2UgY2FtcHVzLDxCUj48L1A+DQo8
UD4mbmJzcDs8L1A+DQo8UD48QlI+d2hpY2ggcGFydCBvZiBjaGFydGVyIHNw
ZWNpZmljYWxseSBleGNsdWRlJm5ic3A7Y2lyY3VpdCB0ZWNobm9sb2d5IGlu
c2lkZSB0aGUgcmJyaWRnZT88L1A+DQo8UD5NUExTIGlzIGFsc28gYSBjaXJj
dWl0LW9yaWVudGVkIHRlY2hub2xvZ3kuIDwvUD4NCjxQPklzJm5ic3A7TVBM
UyBzdHlsZSBicmlkZ2UgY29udHJvbCZuYnNwO2JlaW5nIGV4Y2x1ZGVkID88
L1A+DQo8UD5JIGJlbGlldmUgZW1wbG95aW5nIE1QTFMgZm9yd2FyZGluZyB0
ZWNobmlxdWUgd2l0aGluIHJicmlkZ2UgbWlnaHQgYmU8L1A+DQo8UD51c2Vm
dWwgZm9yJm5ic3A7bGF5ZXItMiB0cmFmZmljIGVuZ2luZWVyaW5nLCBhbHRo
b3VnaCBpdCBtYXkgcG9zc2libHk8L1A+DQo8UD5jb25mbGljdCB3aXRoIEND
QU1QLjwvUD4NCjxQPklmIHNvbWUgKnZpcnR1YWwgY2lyY3VpdCogdGVjaG5v
bG9neSBjYW4gYmUgY29uc2lkZXJlZCwgdGhlcmUgYXJlPC9QPg0KPFA+c2V2
ZXJhbCZuYnNwO2xvb3AgcHJldmVudGlvbi9kZXRlY3Rpb24gdGVjaGlxdWUg
d2UgY2FuIGRpc2N1c3MuPC9QPg0KPFA+Jm5ic3A7PC9QPg0KPFA+Jm5ic3A7
PC9QPg0KPFA+fGFuZCB3ZSBleHBlY3QgdGhhdCB0aGUgcmJyaWRnZSBoZWFk
ZXIgd2lsbCBub3QgZGVwZW5kIG9uIHRoZSByb3V0aW5nPEJSPnxwcm90b2Nv
bCB1c2VkLiBBcyBhIHJlc3VsdCwgc2luY2UgcGFja2V0IGZvcndhcmRpbmcg
bWF5IGJlIHVzZWQgKGluPEJSPnxmYWN0LCBJTU8gaXMgbW9yZSBsaWtlbHkg
dG8gYmUgdXNlZCksIGhvcGNvdW50cyBhcmUgbmVjZXNzYXJ5LjxCUj48L1A+
DQo8UD5JIHRoaW5rIHRoaXMgaXMgaXJyZWxldmFudCBpc3N1ZS4mbmJzcDtO
byBvbmUgcHJvdmVkIGRlcGVuZGFuY3kgb2Y8L1A+DQo8UD5yb3V0aW5nIGFs
Z29yaXRobSBhbmQgaG9wY291bnQuPC9QPg0KPFA+PEJSPnwodW5sZXNzIHlv
dSBrbm93IG9mIGEgYmV0dGVyIG9yIGRpZmZlcmVudCB3YXkgdG8gZW5mb3Jj
ZSBsb29wIGRldGVjdGlvbjxCUj58dGhhdCBkb2VzIG5vdCBkZXBlbmQgb24g
dGhlIHJvdXRpbmcgcHJvdG9jb2wgdXNlZCkuPEJSPjwvUD4NCjxQPiZuYnNw
OzwvUD4NCjxQPiZuYnNwOzwvUD4NCjxQPnBlcmhhcHNlLCB3ZSBtYXkuLi4u
LjxCUj48QlI+PEJSPkRyLiBKYWloeXVuZyBDaG88QlI+RVRSSSwgS29yZWE8
QlI+cGhvbmUgOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyAwNDIpIDg2MC01NTE0PEJSPm92ZXJzZWE6ICs4Mi00Mi04NjAtNTUxNDxC
Uj5mYXg6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7ICs4Mi00Mi04NjEtNTU1MDxCUj48QlI+PEJSPjxCUj48QlI+
PEJSPjwvUD48L0ZPTlQ+PC9ESVY+PC9ESVY+PC9ESVY+PGltZyBzcmM9Ik1h
aWxTY2FubmVyV2ViQnVnIiB3aWR0aD0iMCIgaGVpZ2h0PSIwIiBhbHQ9Ildl
YiBCdWcgZnJvbSBodHRwOi8vdW1haWwuZXRyaS5yZS5rci9FeHRlcm5hbF9S
ZWFkQ2hlY2suYXNweD9lbWFpbD1yYnJpZGdlQHBvc3RlbC5vcmcmbmFtZT1y
YnJpZGdlJTQwcG9zdGVsLm9yZyZmcm9tZW1haWw9amFpaHl1bmdAZXRyaS5y
ZS5rciZtZXNzYWdlaWQ9JTNDYTg3ZGZiNjgtMWRjMi00MTU2LWIzOTEtZmI4
NDViN2IzNzQ2QGV0cmkucmUua3IlM0UiIC8+

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


Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2ANQO624250 for <[e-mail]>; Thu, 10 Mar 2005 15:26:25 -0800 (PST)
Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC;  Fri, 11 Mar 2005 08:27:12 +0900
priority: normal
Thread-Topic: [rbridge] cheer up!!
thread-index: AcUlyK/pjqGVBsQ8QEuYdyhI6PHAwA==
From: "CHO, JAI HYUNG" <[e-mail]>
To: <[e-mail]>
Cc: 
Date: Fri, 11 Mar 2005 08:27:12 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Message-ID: <b28101c525c8$afee8ae0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft CDO for Exchange 2000
Content-Class: urn:content-classes:message
Importance: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181
X-OriginalArrivalTime: 10 Mar 2005 23:27:12.0730 (UTC) FILETIME=[B00DABA0:01C525C8]
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge]  cheer up!!
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "CHO, JAI HYUNG" <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 10 Mar 2005 23:26:36 -0000
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 :       [phone]
oversea: [phone]
fax:         [phone] 







Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2AK5Z611541 for <[e-mail]>; Thu, 10 Mar 2005 12:05:36 -0800 (PST)
Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <[e-mail]> for [e-mail]; Fri, 11 Mar 2005 07:05:28 +1100
Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6FDD8AB545	for <[e-mail]>; Fri, 11 Mar 2005 07:05:28 +1100 (EST)
Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by curly.its.monash.edu.au (Postfix) with ESMTP id 457ED4FB0A	for <[e-mail]>; Fri, 11 Mar 2005 07:05:28 +1100 (EST)
Received: from [130.129.131.162] by mail-store-2.its.monash.edu.au (mshttpd) ; Thu, 10 Mar 2005 20:05:28 +0000 (GMT)
Date: Thu, 10 Mar 2005 20:05:28 +0000 (GMT)
From: Greg Daley <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 Patch 2 (built Jul 14 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Possible new attacks to add for security considerations document
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 10 Mar 2005 20:06:37 -0000
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





Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2AJmh605060 for <[e-mail]>; Thu, 10 Mar 2005 11:48:43 -0800 (PST)
Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 10 Mar 2005 11:49:05 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.90,154,1107763200";  d="scan'208"; a="166535374:sNHT5007536136"
Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j2AJmLTM029654; Thu, 10 Mar 2005 11:48:21 -0800 (PST)
Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j2AJmL3W015486; Thu, 10 Mar 2005 11:48:21 -0800
Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j2AJmLTg015482; Thu, 10 Mar 2005 11:48:21 -0800
Date: Thu, 10 Mar 2005 11:48:21 -0800
Message-Id: <[e-mail]>
From: Dino Farinacci <[e-mail]>
To: [e-mail]
In-reply-to: <[e-mail]> (message from Radia Perlman on Wed, 09 Mar 2005 07:59:43 -0800)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [rbridge] VLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 10 Mar 2005 19:49:40 -0000
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

 


Received: from mail.rfburst.com (mail.esmartstart.com [66.119.143.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2AJT7628091 for <[e-mail]>; Thu, 10 Mar 2005 11:29:07 -0800 (PST)
Received: from tobermory.localdomain ([66.119.143.202]) by mail.rfburst.com (8.12.8/8.12.8) with ESMTP id j2AJSpFE001050 for <[e-mail]>; Thu, 10 Mar 2005 12:28:52 -0700
Received: from tobermory.localdomain (localhost [127.0.0.1]) by tobermory.localdomain (8.12.10/8.11.6) with ESMTP id j2AJUZe4021560 for <[e-mail]>; Thu, 10 Mar 2005 12:30:35 -0700
Received: (from ho@localhost) by tobermory.localdomain (8.12.10/8.12.10/Submit) id j2AJUZ22021556; Thu, 10 Mar 2005 12:30:35 -0700
Date: Thu, 10 Mar 2005 12:30:35 -0700
Message-Id: <[e-mail]>
From: "The Purple Streak, Hilarie Orman" <[e-mail]>
To: [e-mail]
In-reply-to: Yourmessage <[e-mail]>
X-esmartscan-MailScanner-Information: Please contact the ISP for more information
X-esmartscan-MailScanner: Found to be clean
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] text on hop-count  in updated charter
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 10 Mar 2005 19:30:04 -0000
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


Received: from pollux.ietf62.ietf.org (smtp.ietf62.ietf.org [130.129.16.13]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2AJIR624712 for <[e-mail]>; Thu, 10 Mar 2005 11:18:27 -0800 (PST)
Received: from [127.0.0.1] (wireless-130-129-135-59.ietf62.ietf.org [130.129.135.59]) by pollux.ietf62.ietf.org (Postfix) with ESMTP id 52D4642 for <[e-mail]>; Thu, 10 Mar 2005 11:18:26 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 10 Mar 2005 20:18:25 +0100
From: Loa Andersson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
References: <a98501c52574$46b99a50$[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 8bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] text on hop-count  in updated charter
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 10 Mar 2005 19:18:40 -0000
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 : [phone]
>>oversea: [phone]
>>fax: [phone]
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://www.postel.org/mailman/listinfo/rbridge
>> 
>>
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  [phone]
Isafjordsgatan 22                  mobile: [phone]
Kista, Sweden                      email:  [e-mail]
                                           [e-mail]


Received: from psg.com ([e-mail] [147.28.0.62]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2AIqj613250 for <[e-mail]>; Thu, 10 Mar 2005 10:52:45 -0800 (PST)
Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D9Sm4-000Ih3-Rg; Thu, 10 Mar 2005 18:52:45 +0000
Date: Thu, 10 Mar 2005 12:52:39 -0600
From: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Joe Touch <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] VLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: Alex Zinin <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 10 Mar 2005 18:53:51 -0000
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?

> 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
>> [e-mail]
>> http://www.postel.org/mailman/listinfo/rbridge



Received: from [130.129.132.40] (wireless-130-129-132-40.ietf62.ietf.org [130.129.132.40]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2AIWv606970; Thu, 10 Mar 2005 10:32:57 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 10 Mar 2005 10:32:52 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]> <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC34EFFA477E55C66E8B3CCC5"
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] VLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 10 Mar 2005 18:34:05 -0000
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
> [e-mail]
> 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"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCMJLUE5f5cImnZrsRAjlZAJ419Kj4eoqmpMM5BvkMK47CQZLrlgCeK5Fc
qe7FcHgshNEDkLGAFsbzb5o=
=p0zl
-----END PGP SIGNATURE-----

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


Received: from [130.129.132.40] (wireless-130-129-132-40.ietf62.ietf.org [130.129.132.40]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2AITf605819; Thu, 10 Mar 2005 10:29:41 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 10 Mar 2005 10:29:33 -0800
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: =?EUC-KR?B?wbbA58f8?= <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
References: <a98501c52574$46b99a50$[e-mail]>
In-Reply-To: <a98501c52574$46b99a50$[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7CBC213427F8F560E43EF433"
Content-Transfer-Encoding: 8bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] text on hop-count  in updated charter
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 10 Mar 2005 18:30:47 -0000
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"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCMJIRE5f5cImnZrsRAmmUAJ91lnwD4xg0a5nHboEJ/n8zei3f+gCdF6ho
UBZDdRXzJMjgqnSbNKUFRYg=
=Rhs4
-----END PGP SIGNATURE-----

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


Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2AI4Y627308 for <[e-mail]>; Thu, 10 Mar 2005 10:04:34 -0800 (PST)
Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC;  Fri, 11 Mar 2005 03:05:22 +0900
priority: normal
Thread-Topic: [rbridge] test... please ignore and delete it.... sorry
thread-index: AcUlm7o2vopMF9qVQbima9DKYYZNyg==
From: =?ks_c_5601-1987?B?wbbA58f8?= <[e-mail]>
To: <[e-mail]>
Cc: 
Date: Fri, 11 Mar 2005 03:05:22 +0900
Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCBCY06x4rz6utC8rsbALCC047Tn?=
Message-ID: <b04501c5259b$ba450050$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="ks_c_5601-1987"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft CDO for Exchange 2000
Content-Class: urn:content-classes:message
Importance: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181
X-OriginalArrivalTime: 10 Mar 2005 18:05:22.0720 (UTC) FILETIME=[BA63FA00:01C5259B]
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge]  test... please ignore and delete it.... sorry
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: =?ks_c_5601-1987?B?wbbA58f8?= <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 10 Mar 2005 18:05:35 -0000
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 :       [phone]
oversea: [phone]
fax:         [phone] 







Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2AGf4624556 for <[e-mail]>; Thu, 10 Mar 2005 08:41:04 -0800 (PST)
Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Fri, 11 Mar 2005 01:41:52 +0900
Priority: normal
X-ReadCheckName: rbridge%40postel.org
Thread-Topic: [rbridge] text on hop-count  in updated charter
X-ReadCheckMessageID: <[e-mail]>
thread-index: AcUlkA/lqkIA9c52Qgul09p2wy0VwA==
Content-Transfer-Encoding: 7bit
From: "CHO, JAI HYUNG" <[e-mail]>
To: <[e-mail]>
Date: Fri, 11 Mar 2005 01:41:52 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Message-ID: <afb401c52590$0fe7b950$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_AFB5_01C525DB.7FCF6150"
X-Mailer: Microsoft CDO for Exchange 2000
Content-Class: urn:content-classes:message
Importance: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181
X-OriginalArrivalTime: 10 Mar 2005 16:41:52.0432 (UTC) FILETIME=[1006B300:01C52590]
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] text on hop-count  in updated charter
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "CHO, JAI HYUNG" <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 10 Mar 2005 16:41:35 -0000
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

PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt
RkFNSUxZOiBTeXN0ZW0iPg0KPERJVj4NCjxESVYgc3R5bGU9IkZPTlQtU0la
RTogMTBwdDsgRk9OVC1GQU1JTFk6ID8/Ij4NCjxESVY+PFNQQU4gbGFuZz1F
Ti1VUz48P3htbDpuYW1lc3BhY2UgcHJlZml4ID0gbyBucyA9ICJ1cm46c2No
ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIC8+PG86cD48Rk9O
VCBmYWNlPT8/PjwvRk9OVD48L286cD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8
RElWPjxTUEFOIGxhbmc9RU4tVVM+PG86cD5Tb3JyeSB0byBzZW5kIGl0IGFn
YWluLjwvbzpwPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gbGFuZz1FTi1V
Uz48bzpwPlNvbWUgcGVvcGxlIHNheSBpdCdzIHdyb25nbHkgZW5jb2RlZC4u
LjwvbzpwPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gbGFuZz1FTi1VUz48
bzpwPkl0IHNob3VsZCBiZSByZWFkIGluIGVuZ2xpc2ggd2luZG93Li4uLjwv
bzpwPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gbGFuZz1FTi1VUz48bzpw
PjwvbzpwPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gbGFuZz1F
Ti1VUz48bzpwPkphaWh5dW5nPC9vOnA+PC9TUEFOPjwvRElWPg0KPERJVj48
U1BBTiBsYW5nPUVOLVVTPjxvOnA+PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PC9vOnA+PC9TUEFOPjwvRElWPg0KPERJ
Vj48U1BBTiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9TUEFOPiZuYnNwOzwv
RElWPg0KPERJVj48U1BBTiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+
PC9TUEFOPjwvRElWPg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHls
ZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48Rk9O
VCBmYWNlPT8/PkRlYXIgQWxsLDwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xh
c3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BB
TiBsYW5nPUVOLVVTPjxvOnA+PEZPTlQgZmFjZT0/Pz4mbmJzcDs8L0ZPTlQ+
PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0i
TUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBm
YWNlPT8/PkkgYW0gbmV3IHRvIHRoaXMgQk9GIGFuZCBJIGZvdW5kIGZyb20g
UmFkaWE8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZP
TlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWFzY2lpLWZvbnQt
ZmFtaWx5OiA/PyI+JzwvU1BBTj48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZh
Y2U9Pz8+cyBwYXBlciwgdGhlIGFwcHJvYWNoIDwvRk9OVD48L1NQQU4+PC9Q
Pg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20g
MHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9Pz8+YW5kIGdvYWwg
b2YgcmJyaWRnZSBpcyBzb21ld2hhdCByZWxhdGVkIHRvIHdoYXQgSSBoYXZl
IHJlc2VhcmNoZWQgZm9yIDwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9
TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBs
YW5nPUVOLVVTPjxGT05UIGZhY2U9Pz8+c2V2ZXJhbCB5ZWFycy48L0ZPTlQ+
PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lO
OiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNlPT8/
PkkmbmJzcDtlYWdlciZuYnNwO3RvIHNoYXJlIG15IGlkZWEgd2l0aCBUUklM
TCBwZW9wbGUuPC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3Jt
YWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4t
VVM+PG86cD48Rk9OVCBmYWNlPT8/PiZuYnNwOzwvRk9OVD48L286cD48L1NQ
QU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBj
bSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9Pz8+Qnkg
dGhlIHdheSwgSSBicmllZmx5IHJlYWQgaW5pdGlhbCBkcmFmdCBvZiBUUklM
TCBjaGFydGVyIGFuZCBzaG91bGQ8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNs
YXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQ
QU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNlPT8/PmV4cHJlc3Mgc29tZSB3b3Jy
eSBvbiA8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZP
TlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWFzY2lpLWZvbnQt
ZmFtaWx5OiA/PyI+JzwvU1BBTj48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZh
Y2U9Pz8+ZW5jYXBzdWxhdGlvbjwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1F
Ti1VUyBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nOyBt
c28tYXNjaWktZm9udC1mYW1pbHk6ID8/Ij4nPC9TUEFOPjxTUEFOIGxhbmc9
RU4tVVM+PEZPTlQgZmFjZT0/Pz4gYW5kIDwvRk9OVD48L1NQQU4+PFNQQU4g
bGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9t
YW4nOyBtc28tYXNjaWktZm9udC1mYW1pbHk6ID8/Ij4nPC9TUEFOPjxTUEFO
IGxhbmc9RU4tVVM+PEZPTlQgZmFjZT0/Pz5UVEw8L0ZPTlQ+PC9TUEFOPjxT
UEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3
IFJvbWFuJzsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiA/PyI+JzwvU1BBTj48
U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9Pz8+IHBhcnQuPC9GT05UPjwv
U1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjog
MGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PG86cD48Rk9OVCBmYWNl
PT8/PiZuYnNwOzwvRk9OVD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9
TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBs
YW5nPUVOLVVTPjxGT05UIGZhY2U9Pz8+SSBmb3VuZCBmb2xsb3dpbmcgdGV4
dCBpbiB0aGUgY2hhcnRlciBkcmFmdCA6PC9GT05UPjwvU1BBTj48L1A+DQo8
UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQi
PjxTUEFOIGxhbmc9RU4tVVM+PG86cD48Rk9OVCBmYWNlPT8/PiZuYnNwOzwv
Rk9OVD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0
eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTIHN0
eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1hc2Np
aS1mb250LWZhbWlseTogPz8iPiI8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUz48
Rk9OVCBmYWNlPT8/Pi4uIHRoZSBwYWNrZXQgaGVhZGVyICpzaG91bGQqIGhh
dmUgYSBob3AgY291bnQgZm9yIHJvYnVzdG5lc3MgPC9GT05UPjwvU1BBTj48
L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBj
bSAwcHQ7IFRFWFQtSU5ERU5UOiAxNXB0OyBtc28tY2hhci1pbmRlbnQtY291
bnQ6IDEuNSI+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNlPT8/PmluIHRo
ZSBwcmVzZW5jZSBvZiB0ZW1wb3Jhcnkgcm91dGluZyBsb29wczwvRk9OVD48
L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1GQU1JTFk6ICdU
aW1lcyBOZXcgUm9tYW4nOyBtc28tYXNjaWktZm9udC1mYW1pbHk6ID8/Ij4i
PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lO
OiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48bzpwPjxGT05UIGZh
Y2U9Pz8+Jm5ic3A7PC9GT05UPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFz
cz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFO
IGxhbmc9RU4tVVM+PEZPTlQgZmFjZT0/Pz5JIGtub3cgVFRMIGhhcyBiZWVu
IGNvbnN0YW50bHkgYW4gaXNzdWUgaW4gVFJJTEwuIEhvd2V2ZXIsPC9GT05U
PjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJ
TjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgZmFjZT0/
Pz5JIGRvIG5vdCB1bmRlcnN0YW5kIHdoeSBwZW9wbGUgdGhpbmsgVFRMIGFz
IGFuIGluZGlzcGVuc2FibGUgcGFydDwvRk9OVD48L1NQQU4+PC9QPg0KPFAg
Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48
U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9Pz8+b2Ygcm91dGluZyBmcm9t
IHRoZSBmaXJzdCBwbGFjZS4gPC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFz
cz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFO
IGxhbmc9RU4tVVM+PEZPTlQgZmFjZT0/Pz5BbHRob3VnaCBUVEwgaXMgYSBz
aW1wbGUsIGFuZCBwcm92ZW4gbWV0aG9kLCA8L0ZPTlQ+PC9TUEFOPjwvUD4N
CjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBw
dCI+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNlPT8/PlRUTCBpcyBub3Qg
dGhlIG9ubHkgdGVjaG5vbG9neSB0YWNrbGluZyBsb29waW5nIHByb2JsZW0u
PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9
Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PG86cD48
Rk9OVCBmYWNlPT8/PiZuYnNwOzwvRk9OVD48L286cD48L1NQQU4+PC9QPg0K
PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0
Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9Pz8+QVRNLU1QTFMgaGFz
IGRvbmUgd2VsbCB3aXRob3V0IFRUTC4gVGhlcmUgYXJlIHBsZW50eSBvZiA8
L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0i
TUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBm
YWNlPT8/PnByb3Bvc2FscyBwcmV2ZW50aW5nIG9yIGV4YW1pbmluZyBsb29w
cy4gSSBhbSB3b25kZXJpbmcgaWYgPC9GT05UPjwvU1BBTj48L1A+DQo8UCBj
bGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxT
UEFOIGxhbmc9RU4tVVM+PEZPTlQgZmFjZT0/Pz50aGVyZSBoYXMgYmVlbiBl
bm91Z2ggZGlzY3Vzc2lvbiBvbiBvdGhlciBvcHRpb25zIGJlZm9yZSA8L0ZP
TlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFS
R0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNl
PT8/PnBlb3BsZSByZWFjaCB0aGUgY29uY2x1c2lvbiBvbiBUVEwuPC9GT05U
PjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJ
TjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PG86cD48Rk9OVCBm
YWNlPT8/PiZuYnNwOzwvRk9OVD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xh
c3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BB
TiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9Pz8+QnkgZml4aW5nIHRoZSBob3At
Y291bnQgcGFydCBpbiBjaGFydGVyIGl0ZW0sIEkgdGhpbmsgdGhpcyBtYXkg
cHJldmVudCA8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1h
bCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1V
Uz48Rk9OVCBmYWNlPT8/PmFueSBmdXR1cmUgYW50aS1sb29waW5nIHRlY2hu
b2xvZ3kgZnJvbSBjb25zaWRlcmF0aW9uIGFuZCBqdXN0aWZ5aW5nIDwvRk9O
VD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJH
SU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9
Pz8+ZW5jYXBzdWxhdGlvbiBvdmVyaGVhZCBmcm9tIHRoZSBmaXJzdC4gSSB0
aGluayB0aGUgbW90aXZhdGlvbiBvZiA8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQ
IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+
PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNlPT8/PnJicmlkZ2UgaXMgdmVy
eSBhdHRyYWN0aXZlLCBob3dldmVyLCBpZiBpdCBpcyBwb3NzaWJsZSwgcGVv
cGxlIG11c3QgZmluZCA8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1z
b05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFu
Zz1FTi1VUz48Rk9OVCBmYWNlPT8/PmEgd2F5IHRvIGFjaGlldmUgdGhlIGdv
YWwgd2l0aG91dCBtb2RpZnlpbmcgY3VycmVudCBmb3JtYXQuIDwvRk9OVD48
L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46
IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxvOnA+PEZPTlQgZmFj
ZT0/Pz4mbmJzcDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNz
PU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4g
bGFuZz1FTi1VUz48Rk9OVCBmYWNlPT8/PkZvciB0aGUgY2hhcnRlciB0ZXh0
LCBJIHRoaW5rIGl0IGlzIGp1c3QgZW5vdWdoIHRvIG1lbnRpb24gdGhhdDwv
Rk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJN
QVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZh
Y2U9Pz8+PC9GT05UPjwvU1BBTj4mbmJzcDs8L1A+DQo8UCBjbGFzcz1Nc29O
b3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9
RU4tVVMgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJzsg
bXNvLWFzY2lpLWZvbnQtZmFtaWx5OiA/PyI+JzwvU1BBTj48U1BBTiBsYW5n
PUVOLVVTPjxGT05UIGZhY2U9Pz8+UmJyaWRnZSBtdXN0IGhhdmUgc3VmZmlj
aWVudCBtZWFzdXJlIHRvIHByZXZlbnQvZGV0ZWN0PC9GT05UPjwvU1BBTj48
L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBj
bSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgZmFjZT0/Pz5wb3NzaWJs
ZSBsb29waW5nIC4uLi48L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMg
c3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWFz
Y2lpLWZvbnQtZmFtaWx5OiA/PyI+JzwvU1BBTj48U1BBTiBsYW5nPUVOLVVT
PjxGT05UIGZhY2U9Pz8+IHdpdGhvdXQgbWVudGlvbmluZyBuZXcgaGVhZGVy
LjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl
PSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxvOnA+
PEZPTlQgZmFjZT0/Pz4mbmJzcDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4N
CjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBw
dCI+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNlPT8/PkhvcGVmdWxseSwg
dGhpcyBtYXkgcHJvdmlkZSBhIGdvb2QgY29uc2lkZXJhdGlvbi48L0ZPTlQ+
PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lO
OiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48bzpwPjxGT05UIGZh
Y2U9Pz8+Jm5ic3A7PC9GT05UPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFz
cz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFO
IGxhbmc9RU4tVVM+PEZPTlQgZmFjZT0/Pz5UaGFuayB5b3UuPG86cD48L286
cD48L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHls
ZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48bzpw
PjxGT05UIGZhY2U9Pz8+Jm5ic3A7PC9GT05UPjwvbzpwPjwvU1BBTj48L1A+
DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAw
cHQiPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgZmFjZT0/Pz5SZWdhcmRzPC9G
T05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1B
UkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PG86cD48Rk9O
VCBmYWNlPT8/PiZuYnNwOzwvRk9OVD48L286cD48L1NQQU4+PC9QPg0KPFAg
Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48
U1BBTiBsYW5nPUVOLVVTPjxvOnA+PEZPTlQgZmFjZT0/Pz48L0ZPTlQ+PC9v
OnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFS
R0lOOiAwY20gMGNtIDBwdCI+Jm5ic3A7PC9QPjwvRElWPg0KPERJVj4NCjxE
SVYgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ID8/Ij4N
CjxESVY+DQo8RElWIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFN
SUxZOiA/PyI+DQo8RElWPkRyLiBKYWloeXVuZyBDaG88L0RJVj4NCjxESVY+
RVRSSSwgS29yZWE8L0RJVj4NCjxESVY+cGhvbmUgOiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwNDIpIDg2MC01NTE0PC9ESVY+DQo8
RElWPm92ZXJzZWE6ICs4Mi00Mi04NjAtNTUxNDwvRElWPg0KPERJVj5mYXg6
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7KzgyLTQyLTg2MS01NTUwJm5ic3A7PC9ESVY+PC9ESVY+PC9E
SVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PGltZyBzcmM9Ik1h
aWxTY2FubmVyV2ViQnVnIiB3aWR0aD0iMCIgaGVpZ2h0PSIwIiBhbHQ9Ildl
YiBCdWcgZnJvbSBodHRwOi8vdW1haWwuZXRyaS5yZS5rci9FeHRlcm5hbF9S
ZWFkQ2hlY2suYXNweD9lbWFpbD1yYnJpZGdlQHBvc3RlbC5vcmcmbmFtZT1y
YnJpZGdlJTQwcG9zdGVsLm9yZyZmcm9tZW1haWw9amFpaHl1bmdAZXRyaS5y
ZS5rciZtZXNzYWdlaWQ9JTNDYTI2NzZjNmUtZWYwOS00M2I2LWFjMjQtMGU2
N2FhOWRkN2E5QGV0cmkucmUua3IlM0UiIC8+

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


Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2AGdM624015 for <[e-mail]>; Thu, 10 Mar 2005 08:39:22 -0800 (PST)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j2AGdHhp024793 for <[e-mail]>; Thu, 10 Mar 2005 09:39:22 -0700 (MST)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 10 Mar 2005 11:39:17 -0500 (EST)
Received: from sun.com (vpn-129-150-29-175.SFBay.Sun.COM [129.150.29.175]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]>; Thu, 10 Mar 2005 11:39:17 -0500 (EST)
Date: Thu, 10 Mar 2005 08:39:15 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <a98501c52574$46b99a50$[e-mail]>
To: =?x-windows-949?B?wbbA58f8?= <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=x-windows-949
Content-transfer-encoding: 8BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
References: <a98501c52574$46b99a50$[e-mail]>
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] text on hop-count  in updated charter
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 10 Mar 2005 16:39:38 -0000
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 : [phone]
> oversea: [phone]
> fax: [phone]
>
>------------------------------------------------------------------------
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>



Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2ADMB612522 for <[e-mail]>; Thu, 10 Mar 2005 05:22:11 -0800 (PST)
Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Thu, 10 Mar 2005 22:22:58 +0900
Priority: normal
X-ReadCheckName: rbridge%40postel.org
Thread-Topic: [rbridge] text on hop-count  in updated charter
X-ReadCheckMessageID: <[e-mail]>
thread-index: AcUldEa3Z8sp+DD/QxO8lW1KH1YFXA==
Content-Transfer-Encoding: 7bit
From: =?ks_c_5601-1987?B?wbbA58f8?= <[e-mail]>
To: <[e-mail]>
Date: Thu, 10 Mar 2005 22:22:58 +0900
Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCBCY06x4rz6utC8rsbALCC047Tn?=
Message-ID: <a98501c52574$46b99a50$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_A986_01C525BF.B6A14250"
X-Mailer: Microsoft CDO for Exchange 2000
Content-Class: urn:content-classes:message
Importance: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181
X-OriginalArrivalTime: 10 Mar 2005 13:22:58.0496 (UTC) FILETIME=[46D89400:01C52574]
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: [rbridge]  text on hop-count  in updated charter
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: =?ks_c_5601-1987?B?wbbA58f8?= <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 10 Mar 2005 13:23:36 -0000
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

PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt
RkFNSUxZOiCxvLiyIj4NCjxESVY+PFNQQU4gbGFuZz1FTi1VUz48P3htbDpu
YW1lc3BhY2UgcHJlZml4ID0gbyBucyA9ICJ1cm46c2NoZW1hcy1taWNyb3Nv
ZnQtY29tOm9mZmljZTpvZmZpY2UiIC8+PG86cD48Rk9OVCBmYWNlPbnZxcE+
Jm5ic3A7PC9GT05UPjwvbzpwPjwvU1BBTj48L0RJVj4NCjxESVY+DQo8UCBj
bGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxT
UEFOIGxhbmc9RU4tVVM+PEZPTlQgZmFjZT252cXBPkRlYXIgQWxsLDwvRk9O
VD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJH
SU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxvOnA+PEZPTlQg
ZmFjZT252cXBPiZuYnNwOzwvRk9OVD48L286cD48L1NQQU4+PC9QPg0KPFAg
Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48
U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9udnFwT5JIGFtIG5ldyB0byB0
aGlzIEJPRiBhbmQgSSBmb3VuZCBmcm9tIFJhZGlhPC9GT05UPjwvU1BBTj48
U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5l
dyBSb21hbic7IG1zby1hc2NpaS1mb250LWZhbWlseTogudnFwSI+oa88L1NQ
QU4+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNlPbnZxcE+cyBwYXBlciwg
dGhlIGFwcHJvYWNoIDwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNv
Tm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5n
PUVOLVVTPjxGT05UIGZhY2U9udnFwT5hbmQgZ29hbCBvZiByYnJpZGdlIGlz
IHNvbWV3aGF0IHJlbGF0ZWQgdG8gd2hhdCBJIGhhdmUgcmVzZWFyY2hlZCBm
b3IgPC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5
bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PEZP
TlQgZmFjZT252cXBPnNldmVyYWwgeWVhcnMuPC9GT05UPjwvU1BBTj48L1A+
DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAw
cHQiPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgZmFjZT252cXBPkkgYW0gdmVy
eSBlYWdlciB0byBzaGFyZSBteSBpZGVhIHdpdGggVFJJTEwgcGVvcGxlLjwv
Rk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJN
QVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxvOnA+PEZP
TlQgZmFjZT252cXBPiZuYnNwOzwvRk9OVD48L286cD48L1NQQU4+PC9QPg0K
PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0
Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9udnFwT5CeSB0aGUgd2F5
LCBJIGJyaWVmbHkgcmVhZCBpbml0aWFsIGRyYWZ0IG9mIFRSSUxMIGNoYXJ0
ZXIgYW5kIGZlbHQgb2JsaWdlZCB0bzwvRk9OVD48L1NQQU4+PC9QPg0KPFAg
Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48
U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9udnFwT5leHByZXNzIHNvbWUg
d29ycnkgb24gPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxl
PSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1hc2NpaS1m
b250LWZhbWlseTogudnFwSI+oa48L1NQQU4+PFNQQU4gbGFuZz1FTi1VUz48
Rk9OVCBmYWNlPbnZxcE+ZW5jYXBzdWxhdGlvbjwvRk9OVD48L1NQQU4+PFNQ
QU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcg
Um9tYW4nOyBtc28tYXNjaWktZm9udC1mYW1pbHk6ILnZxcEiPqGvPC9TUEFO
PjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgZmFjZT252cXBPiBhbmQgPC9GT05U
PjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULUZBTUlMWTog
J1RpbWVzIE5ldyBSb21hbic7IG1zby1hc2NpaS1mb250LWZhbWlseTogudnF
wSI+oa48L1NQQU4+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNlPbnZxcE+
VFRMPC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05U
LUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1hc2NpaS1mb250LWZh
bWlseTogudnFwSI+oa88L1NQQU4+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBm
YWNlPbnZxcE+IHBhcnQuPC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1N
c29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxh
bmc9RU4tVVM+PG86cD48Rk9OVCBmYWNlPbnZxcE+Jm5ic3A7PC9GT05UPjwv
bzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1B
UkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgZmFj
ZT252cXBPkkgZm91bmQgZm9sbG93aW5nIHRleHQgaW4gdGhlIGNoYXJ0ZXIg
ZHJhZnQgOjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFs
IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVT
PjxvOnA+PEZPTlQgZmFjZT252cXBPiZuYnNwOzwvRk9OVD48L286cD48L1NQ
QU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBj
bSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULUZBTUlM
WTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1hc2NpaS1mb250LWZhbWlseTog
udnFwSI+obA8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNlPbnZ
xcE+Li4gdGhlIHBhY2tldCBoZWFkZXIgKnNob3VsZCogaGF2ZSBhIGhvcCBj
b3VudCBmb3Igcm9idXN0bmVzcyA8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNs
YXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVY
VC1JTkRFTlQ6IDE1cHQ7IG1zby1jaGFyLWluZGVudC1jb3VudDogMS41Ij48
U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9udnFwT5pbiB0aGUgcHJlc2Vu
Y2Ugb2YgdGVtcG9yYXJ5IHJvdXRpbmcgbG9vcHM8L0ZPTlQ+PC9TUEFOPjxT
UEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3
IFJvbWFuJzsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiC52cXBIj6hsTwvU1BB
Tj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNt
IDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PG86cD48Rk9OVCBmYWNlPbnZ
xcE+Jm5ic3A7PC9GT05UPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1N
c29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxh
bmc9RU4tVVM+PEZPTlQgZmFjZT252cXBPkkga25vdyBUVEwgaGFzIGJlZW4g
Y29uc3RhbnRseSBhbiBpc3N1ZSBpbiBUUklMTC4gSG93ZXZlciw8L0ZPTlQ+
PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lO
OiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNlPbnZ
xcE+SSBkbyBub3QgdW5kZXJzdGFuZCB3aHkgcGVvcGxlIHRoaW5rIFRUTCBh
cyBhbiBpbmRpc3BlbnNhYmxlIHBhcnQ8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQ
IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+
PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNlPbnZxcE+b2Ygcm91dGluZyBm
cm9tIHRoZSBmaXJzdCBwbGFjZS4gPC9GT05UPjwvU1BBTj48L1A+DQo8UCBj
bGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxT
UEFOIGxhbmc9RU4tVVM+PEZPTlQgZmFjZT252cXBPkFsdGhvdWdoIFRUTCBp
cyBhIHNpbXBsZSwgYW5kIHByb3ZlbiBtZXRob2QsIDwvRk9OVD48L1NQQU4+
PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAw
Y20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9udnFwT5UVEwg
aXMgbm90IHRoZSBvbmx5IHRlY2hub2xvZ3kgdGFja2xpbmcgbG9vcGluZyBw
cm9ibGVtLjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFs
IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVT
PjxvOnA+PEZPTlQgZmFjZT252cXBPiZuYnNwOzwvRk9OVD48L286cD48L1NQ
QU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBj
bSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9udnFwT5B
VE0tTVBMUyBoYXMgZG9uZSB3ZWxsIHdpdGhvdXQgVFRMLiBUaGVyZSBhcmUg
cGxlbnR5IG9mIDwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9y
bWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVO
LVVTPjxGT05UIGZhY2U9udnFwT5wcm9wb3NhbHMgcHJldmVudGluZyBvciBl
eGFtaW5pbmcgbG9vcHMuIEkgYW0gd29uZGVyaW5nIGlmIDwvRk9OVD48L1NQ
QU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBj
bSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9udnFwT50
aGVyZSBoYXMgYmVlbiBlbm91Z2ggZGlzY3Vzc2lvbiBvbiBvdGhlciBvcHRp
b25zIGJlZm9yZSA8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05v
cm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1F
Ti1VUz48Rk9OVCBmYWNlPbnZxcE+cGVvcGxlIHJlYWNoIHRoZSBjb25jbHVz
aW9uIG9uIFRUTC48L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05v
cm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1F
Ti1VUz48bzpwPjxGT05UIGZhY2U9udnFwT4mbmJzcDs8L0ZPTlQ+PC9vOnA+
PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lO
OiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNlPbnZ
xcE+QnkgZml4aW5nIHRoZSBob3AtY291bnQgcGFydCBpbiBjaGFydGVyIGl0
ZW0sIEkgdGhpbmsgdGhpcyBtYXkgcHJldmVudCA8L0ZPTlQ+PC9TUEFOPjwv
UD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNt
IDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNlPbnZxcE+YW55IGZ1
dHVyZSBhbnRpLWxvb3BpbmcgdGVjaG5vbG9neSBmcm9tIGNvbnNpZGVyYXRp
b24gYW5kIGp1c3RpZnlpbmcgPC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFz
cz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFO
IGxhbmc9RU4tVVM+PEZPTlQgZmFjZT252cXBPmVuY2Fwc3VsYXRpb24gb3Zl
cmhlYWQgZnJvbSB0aGUgZmlyc3QuIEkgdGhpbmsgdGhlIG1vdGl2YXRpb24g
b2YgPC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5
bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PEZP
TlQgZmFjZT252cXBPnJicmlkZ2UgaXMgdmVyeSBhdHRyYWN0aXZlLCBob3dl
dmVyLCBpZiBpdCBpcyBwb3NzaWJsZSwgcGVvcGxlIG11c3QgZmluZCA8L0ZP
TlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFS
R0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNl
PbnZxcE+YSB3YXkgdG8gYWNoaWV2ZSB0aGUgZ29hbCB3aXRob3V0IG1vZGlm
eWluZyBjdXJyZW50IGZvcm1hdC4gPC9GT05UPjwvU1BBTj48L1A+DQo8UCBj
bGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxT
UEFOIGxhbmc9RU4tVVM+PG86cD48Rk9OVCBmYWNlPbnZxcE+Jm5ic3A7PC9G
T05UPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5
bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PEZP
TlQgZmFjZT252cXBPkZvciB0aGUgY2hhcnRlciB0ZXh0LCBJIHRoaW5rIGl0
IGlzIGp1c3QgZW5vdWdoIHRvIG1lbnRpb24gdGhhdDwvRk9OVD48L1NQQU4+
PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAw
Y20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9udnFwT48L0ZP
TlQ+PC9TUEFOPiZuYnNwOzwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHls
ZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUyBzdHls
ZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYXNjaWkt
Zm9udC1mYW1pbHk6ILnZxcEiPqGuPC9TUEFOPjxTUEFOIGxhbmc9RU4tVVM+
PEZPTlQgZmFjZT252cXBPlJicmlkZ2UgbXVzdCBoYXZlIHN1ZmZpY2llbnQg
bWVhc3VyZSB0byBwcmV2ZW50L2RldGVjdDwvRk9OVD48L1NQQU4+PC9QPg0K
PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0
Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9udnFwT5wb3NzaWJsZSBs
b29waW5nIC4uLi48L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5
bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWFzY2lp
LWZvbnQtZmFtaWx5OiC52cXBIj6hrzwvU1BBTj48U1BBTiBsYW5nPUVOLVVT
PjxGT05UIGZhY2U9udnFwT4gd2l0aG91dCBtZW50aW9uaW5nIG5ldyBoZWFk
ZXIuPC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5
bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PG86
cD48Rk9OVCBmYWNlPbnZxcE+Jm5ic3A7PC9GT05UPjwvbzpwPjwvU1BBTj48
L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBj
bSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgZmFjZT252cXBPkhvcGVm
dWxseSwgdGhpcyBtYXkgcHJvdmlkZSBhIGdvb2QgY29uc2lkZXJhdGlvbi48
L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0i
TUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48bzpwPjxG
T05UIGZhY2U9udnFwT4mbmJzcDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4N
CjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBw
dCI+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNlPbnZxcE+VGhhbmsgeW91
LjxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29O
b3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9
RU4tVVM+PG86cD48Rk9OVCBmYWNlPbnZxcE+Jm5ic3A7PC9GT05UPjwvbzpw
PjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJ
TjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgZmFjZT25
2cXBPlJlZ2FyZHM8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05v
cm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1F
Ti1VUz48bzpwPjxGT05UIGZhY2U9udnFwT4mbmJzcDs8L0ZPTlQ+PC9vOnA+
PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lO
OiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48bzpwPjxGT05UIGZh
Y2U9udnFwT48L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1z
b05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+Jm5ic3A7PC9Q
PjwvRElWPg0KPERJVj4NCjxESVYgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg
Rk9OVC1GQU1JTFk6ILG8uLIiPg0KPERJVj4NCjxESVYgc3R5bGU9IkZPTlQt
U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ILG8uLIiPg0KPERJVj5Eci4gSmFp
aHl1bmcgQ2hvPC9ESVY+DQo8RElWPkVUUkksIEtvcmVhPC9ESVY+DQo8RElW
PnBob25lIDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
MDQyKSA4NjAtNTUxNDwvRElWPg0KPERJVj5vdmVyc2VhOiArODItNDItODYw
LTU1MTQ8L0RJVj4NCjxESVY+ZmF4OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOys4Mi00Mi04NjEtNTU1
MCZuYnNwOzwvRElWPjwvRElWPjwvRElWPjwvRElWPjwvRElWPjwvRElWPjxp
bWcgc3JjPSJNYWlsU2Nhbm5lcldlYkJ1ZyIgd2lkdGg9IjAiIGhlaWdodD0i
MCIgYWx0PSJXZWIgQnVnIGZyb20gaHR0cDovL3VtYWlsLmV0cmkucmUua3Iv
RXh0ZXJuYWxfUmVhZENoZWNrLmFzcHg/ZW1haWw9cmJyaWRnZUBwb3N0ZWwu
b3JnJm5hbWU9cmJyaWRnZSU0MHBvc3RlbC5vcmcmZnJvbWVtYWlsPWphaWh5
dW5nQGV0cmkucmUua3ImbWVzc2FnZWlkPSUzQ2IzZjQ0YWFlLTgxZWEtNDk5
MS1iNjA5LTNkMDc5YjljOGU3YUBldHJpLnJlLmtyJTNFIiAvPg==

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


Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2A2nN601776 for <[e-mail]>; Wed, 9 Mar 2005 18:49:23 -0800 (PST)
Received: from jurassic.eng.sun.com ([129.146.82.166]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j2A2nMX8026829 for <[e-mail]>; Wed, 9 Mar 2005 19:49:22 -0700 (MST)
Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j2A2nLiX881482; Wed, 9 Mar 2005 18:49:22 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 09 Mar 2005 18:48:54 -0800
From: Erik Nordmark <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Need scribe and jabber scribe for tomorrows TRILL meeting
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 10 Mar 2005 02:49:29 -0000
Status: RO
Content-Length: 32

Who will volunteer?

    Erik



Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j29Fxe624734 for <[e-mail]>; Wed, 9 Mar 2005 07:59:40 -0800 (PST)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j29FxYhn028810 for <[e-mail]>; Wed, 9 Mar 2005 08:59:40 -0700 (MST)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Wed, 09 Mar 2005 10:59:34 -0500 (EST)
Received: from sun.com (vpn-129-150-28-183.SFBay.Sun.COM [129.150.28.183]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]>; Wed, 09 Mar 2005 10:59:34 -0500 (EST)
Date: Wed, 09 Mar 2005 07:59:43 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Alex Zinin <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: [rbridge] VLANs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 09 Mar 2005 16:00:23 -0000
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





Received: from psg.com ([e-mail] [147.28.0.62]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2553H629148 for <[e-mail]>; Fri, 4 Mar 2005 21:03:17 -0800 (PST)
Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7RRZ-000Jeg-Se; Sat, 05 Mar 2005 05:03:14 +0000
Date: Fri, 4 Mar 2005 21:03:11 -0800
From: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Russ White <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] End station discovery/liveness detection
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: Alex Zinin <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 05 Mar 2005 05:03:53 -0000
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




Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2522c624569 for <[e-mail]>; Fri, 4 Mar 2005 18:02:38 -0800 (PST)
Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 04 Mar 2005 21:18:02 -0500
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.90,137,1107752400";  d="scan'208"; a="39350873:sNHT21161376"
Received: from russpc.Whitehouse.intra (rtp-vpn3-317.cisco.com [10.82.217.63]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2522T1k023491; Fri, 4 Mar 2005 21:02:30 -0500 (EST)
Date: Fri, 4 Mar 2005 21:01:47 -0500 (Eastern Standard Time)
From: Russ White <[e-mail]>
To: Alex Zinin <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-X-Sender: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] End station discovery/liveness detection
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: Russ White <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 05 Mar 2005 02:02:51 -0000
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
>
>> __________________________________
>> [e-mail] CCIE <>< Grace Alone
>

__________________________________
[e-mail] CCIE <>< Grace Alone


Received: from psg.com ([e-mail] [147.28.0.62]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j24NdN618446 for <[e-mail]>; Fri, 4 Mar 2005 15:39:23 -0800 (PST)
Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7MOA-0009X0-TZ; Fri, 04 Mar 2005 23:39:23 +0000
Date: Fri, 4 Mar 2005 15:39:17 -0800
From: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Margaret Wasserman <[e-mail]>
In-Reply-To: <p06200714be4e9a4e4b59@[10\.0\.0\.171]>
References: <[e-mail]> <p06200709be4dfb3c4726@[10.0.0.171]> <[e-mail]> <p06200714be4e9a4e4b59@[10.0.0.171]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Control plane scalability
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: Alex Zinin <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2005 23:39:52 -0000
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




Received: from thingmagic.com (tm-gw2.cictr.com [204.9.221.21] (may be forged)) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j24NDo609044 for <[e-mail]>; Fri, 4 Mar 2005 15:13:50 -0800 (PST)
Received: from [10.0.0.171] (account margaret HELO [10.0.0.171]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 300390; Fri, 04 Mar 2005 18:11:41 -0500
Mime-Version: 1.0
Message-Id: <p06200714be4e9a4e4b59@[10.0.0.171]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <p06200709be4dfb3c4726@[10.0.0.171]> <[e-mail]>
Date: Fri, 4 Mar 2005 18:13:33 -0500
To: Alex Zinin <[e-mail]>
From: Margaret Wasserman <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Control plane scalability
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2005 23:14:51 -0000
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



Received: from psg.com ([e-mail] [147.28.0.62]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j24N9q608007 for <[e-mail]>; Fri, 4 Mar 2005 15:09:52 -0800 (PST)
Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7Lvc-0004Qy-8f; Fri, 04 Mar 2005 23:09:52 +0000
Date: Fri, 4 Mar 2005 15:09:50 -0800
From: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Bill Sommerfeld <[e-mail]>
In-Reply-To: <1109966237.18287.29.camel@thunk>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1109966237.18287.29.camel@thunk>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] End station discovery/liveness detection
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: Alex Zinin <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2005 23:10:50 -0000
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
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge



Received: from psg.com ([e-mail] [147.28.0.62]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j24MvA603910 for <[e-mail]>; Fri, 4 Mar 2005 14:57:10 -0800 (PST)
Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7LjJ-0001hK-Ms; Fri, 04 Mar 2005 22:57:09 +0000
Date: Fri, 4 Mar 2005 14:57:07 -0800
From: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Russ White <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Control plane scalability
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: Alex Zinin <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2005 22:57:51 -0000
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




Received: from psg.com ([e-mail] [147.28.0.62]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j24Mcc627539 for <[e-mail]>; Fri, 4 Mar 2005 14:38:38 -0800 (PST)
Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7LRN-000NsK-KK; Fri, 04 Mar 2005 22:38:38 +0000
Date: Fri, 4 Mar 2005 14:38:35 -0800
From: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Margaret Wasserman <[e-mail]>
In-Reply-To: <p06200709be4dfb3c4726@[10\.0\.0\.171]>
References: <[e-mail]> <p06200709be4dfb3c4726@[10.0.0.171]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j24Mcc627539
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Control plane scalability
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: Alex Zinin <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2005 22:38:55 -0000
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





Received: from psg.com ([e-mail] [147.28.0.62]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j24LTk607957 for <[e-mail]>; Fri, 4 Mar 2005 13:29:46 -0800 (PST)
Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7KMi-000Aod-Tq; Fri, 04 Mar 2005 21:29:45 +0000
Date: Fri, 4 Mar 2005 13:29:42 -0800
From: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Bill Sommerfeld <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Control plane scalability
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: Alex Zinin <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2005 21:29:53 -0000
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, [e-mail] 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





Received: from psg.com ([e-mail] [147.28.0.62]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j24KVx621362 for <[e-mail]>; Fri, 4 Mar 2005 12:31:59 -0800 (PST)
Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7JSp-0000QK-CA; Fri, 04 Mar 2005 20:31:59 +0000
Date: Fri, 4 Mar 2005 12:31:57 -0800
From: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Russ White <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>, Radia Perlman <[e-mail]>
Subject: Re: [rbridge] End station discovery/liveness detection
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: Alex Zinin <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2005 20:32:58 -0000
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

> __________________________________
> [e-mail] CCIE <>< Grace Alone



Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j24JvK610563 for <[e-mail]>; Fri, 4 Mar 2005 11:57:20 -0800 (PST)
Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j24JvJNV025302 for <[e-mail]>; Fri, 4 Mar 2005 11:57:19 -0800 (PST)
Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j24JvJQp002385; Fri, 4 Mar 2005 14:57:19 -0500 (EST)
Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j24JvJWV018378; Fri, 4 Mar 2005 14:57:19 -0500 (EST)
Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j24JvI97018377; Fri, 4 Mar 2005 14:57:18 -0500 (EST)
X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to [e-mail] using -f
From: Bill Sommerfeld <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: <1109966237.18287.29.camel@thunk>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6.325 
Date: Fri, 04 Mar 2005 14:57:18 -0500
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] End station discovery/liveness detection
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2005 19:57:49 -0000
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



















Received: from tm3.ca.alcatel.com (kanfw1.ottawa.alcatel.ca [192.75.23.69]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j24Jnj607817 for <[e-mail]>; Fri, 4 Mar 2005 11:49:45 -0800 (PST)
Received: from alcatel.com (localhost [127.0.0.1]) by tm3.ca.alcatel.com (8.13.0/8.13.0) with ESMTP id j24Jnhbu002804; Fri, 4 Mar 2005 14:49:43 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 04 Mar 2005 14:49:42 -0500
From: Cheng-Yin Lee <[e-mail]>
X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Alex Zinin <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: Radia Perlman <[e-mail]>
Subject: Re: [rbridge] End station discovery/liveness detection
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2005 19:49:57 -0000
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




Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j24JMQ629206 for <[e-mail]>; Fri, 4 Mar 2005 11:22:26 -0800 (PST)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j24JMPX8029139 for <[e-mail]>; Fri, 4 Mar 2005 12:22:26 -0700 (MST)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Fri, 04 Mar 2005 14:22:25 -0500 (EST)
Received: from sun.com (vpn-129-150-26-102.SFBay.Sun.COM [129.150.26.102]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]>; Fri, 04 Mar 2005 14:22:25 -0500 (EST)
Date: Fri, 04 Mar 2005 11:22:29 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <p0620070bbe4e63215d2b@[10.0.0.171]>
To: Margaret Wasserman <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p06200708be4df8abad1a@[10.0.0.171]> <[e-mail]> <p0620070bbe4e63215d2b@[10.0.0.171]>
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Forwarding inside rbridge cloud
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2005 19:22:51 -0000
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
>>
>



Received: from thingmagic.com (tm-gw2.cictr.com [204.9.221.21] (may be forged)) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j24JDs626870 for <[e-mail]>; Fri, 4 Mar 2005 11:13:54 -0800 (PST)
Received: from [10.0.0.171] (account margaret HELO [10.0.0.171]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 300186; Fri, 04 Mar 2005 14:11:35 -0500
Mime-Version: 1.0
Message-Id: <p0620070bbe4e63215d2b@[10.0.0.171]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p06200708be4df8abad1a@[10.0.0.171]> <[e-mail]>
Date: Fri, 4 Mar 2005 14:12:03 -0500
To: Radia Perlman <[e-mail]>
From: Margaret Wasserman <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Forwarding inside rbridge cloud
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2005 19:14:50 -0000
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



Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j24Ib0617271 for <[e-mail]>; Fri, 4 Mar 2005 10:37:00 -0800 (PST)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j24IaUX8023443 for <[e-mail]>; Fri, 4 Mar 2005 11:36:30 -0700 (MST)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Fri, 04 Mar 2005 13:36:30 -0500 (EST)
Received: from sun.com (vpn-129-150-26-102.SFBay.Sun.COM [129.150.26.102]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]>; Fri, 04 Mar 2005 13:36:30 -0500 (EST)
Date: Fri, 04 Mar 2005 10:36:33 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <p06200708be4df8abad1a@[10.0.0.171]>
To: Margaret Wasserman <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p06200708be4df8abad1a@[10.0.0.171]>
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Forwarding inside rbridge cloud
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2005 18:37:50 -0000
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




Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j24IWa616162 for <[e-mail]>; Fri, 4 Mar 2005 10:32:36 -0800 (PST)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j24IWZhn000671 for <[e-mail]>; Fri, 4 Mar 2005 11:32:36 -0700 (MST)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Fri, 04 Mar 2005 13:32:35 -0500 (EST)
Received: from sun.com (vpn-129-150-26-102.SFBay.Sun.COM [129.150.26.102]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]>; Fri, 04 Mar 2005 13:32:35 -0500 (EST)
Date: Fri, 04 Mar 2005 10:32:39 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Russ White <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] End station discovery/liveness detection
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2005 18:33:04 -0000
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
>
>__________________________________
>[e-mail] CCIE <>< Grace Alone
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>



Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j24Hqd602603 for <[e-mail]>; Fri, 4 Mar 2005 09:52:41 -0800 (PST)
Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-1.cisco.com with ESMTP; 04 Mar 2005 10:07:05 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.90,135,1107763200";  d="scan'208"; a="617852811:sNHT31172544"
Received: from russpc.Whitehouse.intra (rtp-vpn3-452.cisco.com [10.82.217.198]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j24HqV1k012935;  Fri, 4 Mar 2005 12:52:31 -0500 (EST)
Date: Fri, 4 Mar 2005 12:51:49 -0500 (Eastern Standard Time)
From: Russ White <[e-mail]>
To: Alex Zinin <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
X-X-Sender: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Control plane scalability
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: Russ White <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2005 17:52:53 -0000
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

__________________________________
[e-mail] CCIE <>< Grace Alone


Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j24G98629992 for <[e-mail]>; Fri, 4 Mar 2005 08:09:08 -0800 (PST)
Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j24G8oNV003408;  Fri, 4 Mar 2005 08:08:50 -0800 (PST)
Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j24G8nOp012819; Fri, 4 Mar 2005 11:08:49 -0500 (EST)
From: Bill Sommerfeld <[e-mail]>
To: Alex Zinin <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6.325 
Date: Fri, 04 Mar 2005 11:07:37 -0500
Content-Transfer-Encoding: 7bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Control plane scalability
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2005 16:09:49 -0000
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




Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j24Er9607930 for <[e-mail]>; Fri, 4 Mar 2005 06:53:09 -0800 (PST)
Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 04 Mar 2005 10:08:07 -0500
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.90,135,1107752400";  d="scan'208"; a="39271276:sNHT50158002954"
Received: from russpc.Whitehouse.intra (rtp-vpn3-452.cisco.com [10.82.217.198]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j24EqdjJ017920;  Fri, 4 Mar 2005 09:52:40 -0500 (EST)
Date: Fri, 4 Mar 2005 09:51:58 -0500 (Eastern Standard Time)
From: Russ White <[e-mail]>
To: Alex Zinin <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-X-Sender: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: Radia Perlman <[e-mail]>
Subject: Re: [rbridge] End station discovery/liveness detection
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: Russ White <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2005 14:53:56 -0000
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

__________________________________
[e-mail] CCIE <>< Grace Alone


Received: from thingmagic.com (tm-gw2.cictr.com [204.9.221.21] (may be forged)) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j24Cpm607847 for <[e-mail]>; Fri, 4 Mar 2005 04:51:48 -0800 (PST)
Received: from [24.61.30.237] (account margaret HELO [10.0.0.171]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 299780; Fri, 04 Mar 2005 07:49:41 -0500
Mime-Version: 1.0
Message-Id: <p06200709be4dfb3c4726@[10.0.0.171]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 4 Mar 2005 07:48:21 -0500
To: Alex Zinin <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
From: Margaret Wasserman <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Control plane scalability
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2005 12:52:51 -0000
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




Received: from thingmagic.com (tm-gw2.cictr.com [204.9.221.21] (may be forged)) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j24Bkn622624; Fri, 4 Mar 2005 03:46:49 -0800 (PST)
Received: from [24.61.30.237] (account margaret HELO [10.0.0.171]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 299738; Fri, 04 Mar 2005 06:44:41 -0500
Mime-Version: 1.0
Message-Id: <p06200708be4df8abad1a@[10.0.0.171]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 4 Mar 2005 06:44:51 -0500
To: Alex Zinin <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>, Radia Perlman <[e-mail]>
From: Margaret Wasserman <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Forwarding inside rbridge cloud
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2005 11:47:48 -0000
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


Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j247C0616078 for <[e-mail]>; Thu, 3 Mar 2005 23:12:00 -0800 (PST)
Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j247Bu903681; Fri, 4 Mar 2005 09:11:56 +0200 (EET)
X-Scanned: Fri, 4 Mar 2005 09:10:41 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE
Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j247Afbo003710; Fri, 4 Mar 2005 09:10:41 +0200
Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00NFU6dC; Fri, 04 Mar 2005 09:10:38 EET
Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j247AaM05816; Fri, 4 Mar 2005 09:10:36 +0200 (EET)
Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);  Fri, 4 Mar 2005 09:10:35 +0200
Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);  Fri, 4 Mar 2005 09:10:34 +0200
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Fri, 4 Mar 2005 09:10:34 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rbridge] Control plane scalability
Thread-Index: AcUgVL3jZx/UepVJTda7oE6XxRaZ9wANAPCA
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 04 Mar 2005 07:10:34.0697 (UTC) FILETIME=[426CEB90:01C52089]
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j247C0616078
Subject: Re: [rbridge] Control plane scalability
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2005 07:13:16 -0000
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


Received: from psg.com ([e-mail] [147.28.0.62]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j240vI625278 for <[e-mail]>; Thu, 3 Mar 2005 16:57:18 -0800 (PST)
Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7182-000GWu-10; Fri, 04 Mar 2005 00:57:18 +0000
Date: Thu, 3 Mar 2005 16:57:17 -0800
From: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Radia Perlman <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Forwarding inside rbridge cloud
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: Alex Zinin <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2005 00:57:44 -0000
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




Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j240mn622777 for <[e-mail]>; Thu, 3 Mar 2005 16:48:49 -0800 (PST)
Received: from phys-bur1-1 ([129.148.13.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j240mnNV012391 for <[e-mail]>; Thu, 3 Mar 2005 16:48:49 -0800 (PST)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 03 Mar 2005 19:48:49 -0500 (EST)
Received: from sun.com (vpn-129-150-24-81.SFBay.Sun.COM [129.150.24.81]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]>; Thu, 03 Mar 2005 19:48:49 -0500 (EST)
Date: Thu, 03 Mar 2005 16:48:52 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Alex Zinin <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Forwarding inside rbridge cloud
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2005 00:49:46 -0000
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

>  
>



Received: from psg.com ([e-mail] [147.28.0.62]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j240n7622815 for <[e-mail]>; Thu, 3 Mar 2005 16:49:07 -0800 (PST)
Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7107-000EyI-77 for [e-mail]; Fri, 04 Mar 2005 00:49:07 +0000
Date: Thu, 3 Mar 2005 16:49:06 -0800
From: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Control plane scalability
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: Alex Zinin <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2005 00:49:47 -0000
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



Received: from psg.com ([e-mail] [147.28.0.62]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j240h4621536 for <[e-mail]>; Thu, 3 Mar 2005 16:43:04 -0800 (PST)
Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D70uB-000EAt-BT; Fri, 04 Mar 2005 00:42:59 +0000
Date: Thu, 3 Mar 2005 16:42:56 -0800
From: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Radia Perlman <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] End station discovery/liveness detection
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: Alex Zinin <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2005 00:44:13 -0000
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




Received: from psg.com ([e-mail] [147.28.0.62]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j240GT615596 for <[e-mail]>; Thu, 3 Mar 2005 16:16:29 -0800 (PST)
Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D70UW-000AYJ-QA; Fri, 04 Mar 2005 00:16:28 +0000
Date: Thu, 3 Mar 2005 16:16:28 -0800
From: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Radia Perlman <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Forwarding inside rbridge cloud
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: Alex Zinin <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2005 00:16:44 -0000
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?
>>
>>  
>>




Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2406Y612848 for <[e-mail]>; Thu, 3 Mar 2005 16:06:34 -0800 (PST)
Received: from phys-bur1-1 ([129.148.13.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j2406YNV024760 for <[e-mail]>; Thu, 3 Mar 2005 16:06:34 -0800 (PST)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 03 Mar 2005 19:06:34 -0500 (EST)
Received: from sun.com (vpn-129-150-24-81.SFBay.Sun.COM [129.150.24.81]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]>; Thu, 03 Mar 2005 19:06:34 -0500 (EST)
Date: Thu, 03 Mar 2005 16:06:37 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Alex Zinin <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
References: <[e-mail]>
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] Forwarding inside rbridge cloud
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2005 00:06:54 -0000
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?
>
>  
>



Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2405L612324 for <[e-mail]>; Thu, 3 Mar 2005 16:05:21 -0800 (PST)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j2404gX8028110 for <[e-mail]>; Thu, 3 Mar 2005 17:04:42 -0700 (MST)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 03 Mar 2005 19:04:42 -0500 (EST)
Received: from sun.com (vpn-129-150-24-81.SFBay.Sun.COM [129.150.24.81]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]>; Thu, 03 Mar 2005 19:04:42 -0500 (EST)
Date: Thu, 03 Mar 2005 16:04:45 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Alex Zinin <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] End station discovery/liveness detection
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2005 00:05:46 -0000
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
>  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...
>
>  
>



Received: from psg.com ([e-mail] [147.28.0.62]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j23Nhx605172 for <[e-mail]>; Thu, 3 Mar 2005 15:43:59 -0800 (PST)
Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6zz5-0004kU-JF for [e-mail]; Thu, 03 Mar 2005 23:43:59 +0000
Date: Thu, 3 Mar 2005 15:43:59 -0800
From: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Forwarding inside rbridge cloud
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: Alex Zinin <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 03 Mar 2005 23:44:44 -0000
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



Received: from psg.com ([e-mail] [147.28.0.62]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j23Nan602588 for <[e-mail]>; Thu, 3 Mar 2005 15:36:49 -0800 (PST)
Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6zs9-0003av-5k; Thu, 03 Mar 2005 23:36:49 +0000
Date: Thu, 3 Mar 2005 15:36:48 -0800
From: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Radia Perlman <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] End station discovery/liveness detection
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: Alex Zinin <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 03 Mar 2005 23:38:15 -0000
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?
>>
>>  
>>




Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j23Jhf623262 for <[e-mail]>; Thu, 3 Mar 2005 11:43:41 -0800 (PST)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j23JheX8021768 for <[e-mail]>; Thu, 3 Mar 2005 12:43:40 -0700 (MST)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 03 Mar 2005 14:43:40 -0500 (EST)
Received: from sun.com (vpn-129-150-24-81.SFBay.Sun.COM [129.150.24.81]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]>; Thu, 03 Mar 2005 14:43:40 -0500 (EST)
Date: Thu, 03 Mar 2005 11:43:44 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: Alex Zinin <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
References: <[e-mail]>
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] End station discovery/liveness detection
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 03 Mar 2005 19:44:57 -0000
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?
>
>  
>



Received: from psg.com ([e-mail] [147.28.0.62]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j23J4l606456 for <[e-mail]>; Thu, 3 Mar 2005 11:04:47 -0800 (PST)
Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6vcH-000AhI-Ke for [e-mail]; Thu, 03 Mar 2005 19:04:09 +0000
Date: Thu, 3 Mar 2005 11:04:08 -0800
From: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] End station discovery/liveness detection
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: Alex Zinin <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 03 Mar 2005 19:06:11 -0000
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



Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j22H0TE17440 for <[e-mail]>; Wed, 2 Mar 2005 09:00:29 -0800 (PST)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 0BA2445CC4 for <[e-mail]>; Wed,  2 Mar 2005 18:00:23 +0100 (CET)
Received: from [163.117.139.55] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.55]) by smtp02.uc3m.es (Postfix) with ESMTP id EB1E740812 for <[e-mail]>; Wed,  2 Mar 2005 18:00:22 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: "Developing a hybrid router/bridge." <[e-mail]>
From: marcelo bagnulo braun <[e-mail]>
Date: Wed, 2 Mar 2005 18:00:21 +0100
X-Mailer: Apple Mail (2.619.2)
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] analysis of threats
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 02 Mar 2005 17:00:49 -0000
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



Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j21JI9E19524 for <[e-mail]>; Tue, 1 Mar 2005 11:18:09 -0800 (PST)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j21JI8X8020353 for <[e-mail]>; Tue, 1 Mar 2005 12:18:08 -0700 (MST)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Tue, 01 Mar 2005 14:18:08 -0500 (EST)
Received: from sun.com (vpn-129-150-24-81.SFBay.Sun.COM [129.150.24.81]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Tue, 01 Mar 2005 14:18:08 -0500 (EST)
Date: Tue, 01 Mar 2005 11:18:12 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 8BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] forwarding of IP packets to off-campus destiantions
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 01 Mar 2005 19:18:34 -0000
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
>>>[e-mail]
>>>http://www.postel.org/mailman/listinfo/rbridge
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://www.postel.org/mailman/listinfo/rbridge
>>
>>    
>>
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>



Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j21IpuE10175 for <[e-mail]>; Tue, 1 Mar 2005 10:51:57 -0800 (PST)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7D26C496C9 for <[e-mail]>; Tue,  1 Mar 2005 19:51:50 +0100 (CET)
Received: from [163.117.139.55] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.55]) by smtp02.uc3m.es (Postfix) with ESMTP id 69AFA496C5 for <[e-mail]>; Tue,  1 Mar 2005 19:51:50 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <[e-mail]>
From: marcelo bagnulo braun <[e-mail]>
Date: Tue, 1 Mar 2005 19:51:49 +0100
To: "Developing a hybrid router/bridge." <[e-mail]>
X-Mailer: Apple Mail (2.619.2)
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id j21IpuE10175
Subject: Re: [rbridge] forwarding of IP packets to off-campus destiantions
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 01 Mar 2005 18:52:34 -0000
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
>> [e-mail]
>> http://www.postel.org/mailman/listinfo/rbridge
>>
>>
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
>



Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j21HMXE12503 for <[e-mail]>; Tue, 1 Mar 2005 09:22:33 -0800 (PST)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j21HMTX8008459 for <[e-mail]>; Tue, 1 Mar 2005 10:22:33 -0700 (MST)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Tue, 01 Mar 2005 12:22:29 -0500 (EST)
Received: from sun.com (vpn-129-150-24-81.SFBay.Sun.COM [129.150.24.81]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Tue, 01 Mar 2005 12:22:29 -0500 (EST)
Date: Tue, 01 Mar 2005 09:22:33 -0800
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008
References: <[e-mail]>
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: Re: [rbridge] forwarding of IP packets to off-campus destiantions
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 01 Mar 2005 17:23:55 -0000
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
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>



Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j21GPxE24410 for <[e-mail]>; Tue, 1 Mar 2005 08:26:01 -0800 (PST)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id BEE1F49678 for <[e-mail]>; Tue,  1 Mar 2005 17:25:52 +0100 (CET)
Received: from [163.117.139.55] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.55]) by smtp02.uc3m.es (Postfix) with ESMTP id A7D8849637 for <[e-mail]>; Tue,  1 Mar 2005 17:25:52 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: "Developing a hybrid router/bridge." <[e-mail]>
From: marcelo bagnulo braun <[e-mail]>
Date: Tue, 1 Mar 2005 17:25:53 +0100
X-Mailer: Apple Mail (2.619.2)
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] forwarding of IP packets to off-campus destiantions
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6b3
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 01 Mar 2005 16:26:26 -0000
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