Subject: [rbridge] Supporting Heterogeneous Link Types

From: alper.yegin at samsung.com (Alper Yegin)
Date: Tue, 28 Jun 2005 13:43:28 -0700

5.3. Supporting Heterogeneous Link Types 

   It is easy to support link types other than 802 links with RBridges. 
   However, mixing link types within a single campus raises 
   complexities, such as packet size, incompatible layer 2 addresses, 
   and other layer 2 features (such as priority) that might be lost when

   trying to "bridge" two different link types.

The TRILL charter is specific to IEEE 802.1 Ethernet networks. Due to
lack of sufficient motivation (interworking incompatible L2s) to
complicate the design, I think we can close this issue. Comments
welcome.

Alper

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Wed, 29 Jun 2005 10:15:58 +0200

I fully agree to close. Today, with the dominancy of Ethernet, this issue
has more to do with the past (compatibility with legacy networks) than with
the near future. 
Guillermo Ib??ez

-----Mensaje original-----
De: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] En nombre
de Alper Yegin
Enviado el: martes, 28 de junio de 2005 22:43
Para: rbridge at postel.org
Asunto: [rbridge] Supporting Heterogeneous Link Types

The TRILL charter is specific to IEEE 802.1 Ethernet networks. Due to lack
of sufficient motivation (interworking incompatible L2s) to complicate the
design, I think we can close this issue. Comments welcome.

Alper

_______________________________________________
rbridge mailing list
rbridge at postel.org http://www.postel.org/mailman/listinfo/rbridge

From: =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Wed, 29 Jun 2005 10:15:58 +0200
Importance: Normal
Subject: Re: [rbridge] Supporting Heterogeneous Link Types
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1159

I fully agree to close. Today, with the dominancy of Ethernet, this issue
has more to do with the past (compatibility with legacy networks) than with
the near future. 
Guillermo Ib??ez

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre
de Alper Yegin
Enviado el: martes, 28 de junio de 2005 22:43
Para: [email-masked]
Asunto: [rbridge] Supporting Heterogeneous Link Types

The TRILL charter is specific to IEEE 802.1 Ethernet networks. Due to lack
of sufficient motivation (interworking incompatible L2s) to complicate the
design, I think we can close this issue. Comments welcome.

Alper

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

Date: Tue, 28 Jun 2005 13:43:28 -0700
From: Alper Yegin <[email-masked]>
To: [email-masked]
Importance: Normal
Subject: [rbridge] Supporting Heterogeneous Link Types
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 591

Alper

Date: Tue, 28 Jun 2005 13:34:26 -0700
From: Alper Yegin <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Importance: Normal
Subject: Re: [rbridge] L3 vs. L2 encapsulation
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1779

The I-D recommends IS-IS, and this is aligned with the use of L2
encapsulation. As Radia brought up, not having to configure IP addresses
is another plus. I guess we could stick with the current default choices
made in the document.

Alper

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Joe Touch
> Sent: Monday, June 27, 2005 8:03 PM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] L3 vs. L2 encapsulation
> 
> The use of L2, L2+shim, or L3 encapsulation doesn't impact what
> protocols can be included, It DOES impact the routing protocols in
use,
> however, so we probably ought to think about it a little.
> 
> Jeo
> 
> Radia Perlman wrote:
> > We've been assuming an L2 encapsulation, and that's what I'd prefer.
> > That not only saves room in the header, but
> > does not a priori require assigning L3 addresses, and also
automatically
> > supports both IPv4 and IPv6.
> >
> > Radia
> >
> > Alper Yegin wrote:
> >
> >
> >>One of the issues listed in draft-perlman-rbridge-03.txt is the
choice
> >>of encapsulation. See Section 5.5 for a detailed discussion.
> >>
> >>Can we close that issue agreeing to a L3 encapsulation?
> >>
> >>This does not prevent anyone designing a L2 encapsulated version by
> >>reusing the base spec(s) as much as possible. That should be outside
the
> >>scope of the WG though.
> >>
> >>Comments welcome.
> >>
> >>Alper
> >>
> >>
> >>
> >>_______________________________________________
> >>rbridge mailing list
> >>[email-masked]
> >>http://www.postel.org/mailman/listinfo/rbridge
> >>
> >>
> >
> >
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://www.postel.org/mailman/listinfo/rbridge

Date: Tue, 28 Jun 2005 09:43:55 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] How many spanning trees?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4701

You are right that paths will not be the same from A to B as from B to A 
with an A-rooted tree (towards B)
vs a B-rooted tree (towards A), at least if we do a straightforward 
calculation of spanning trees. I think trying
to accomplish symmetric routes might
require source/destination pair route computation. So hopefully we won't 
require symmetric routes.

Radia

Guillermo Ib??ez wrote:

>Guillermo Ib??ez wrote:
>This is my feedback on the "how many spanning trees" issue.
>
>
>Radia Perlman wrote:
>
>  
>
>>It would be nice to get opinions on remaining issues, and I think each
>>issue should be in a different email thread, so I'm starting one.
>>
>>How many spanning
>>trees should RBridges compute? Given the link state database, they can 
>>calculate
>>as many as we want without further protocol messages. The possibilities are:
>>
>>a) one spanning tree: This is simplest, obviously. 
>>
>>    
>>
>The poor performance in the core for multicast is an important argument 
>against it. Other possibilities should exist, at least as an option.
>
>  
>
>>b) one per VLAN: How it would work:each RBridge announces, in its link state info, which VLANs that
>>RBridge is attached to.  To calculate a spanning tree for VLAN A, the 
>>RBridges 
>>(all of them...not just those attached to VLAN A) choose the RBridge, 
>>RA, that
>>has the lowest ID, AND that is attached to VLAN A. A spanning tree is 
>>calculated
>>with RA as root. THat spanning tree is pruned so that only branches that 
>>reach
>>other VLAN A links survive.
>>
>>Why bother: If only a few links are VLAN A, then this allows more 
>>optimal delivery
>>of multicast/unknown frames within the VLAN A broadcast domain.
>> 
>>
>>    
>>
>
>It seems that with this implementation  compatibility (interoperability) 
>with bridges running Multiple Spanning Tree Protocol (MSTP) is 
>excluded.  If bridges running MSTP exist  in the campus network, they 
>must be confined in one or several MST regions with their specific 
>VLAN-to-spanning tree instance mappings and,  like happens with STP or 
>RSTP, the trees will end at the region boundary with an rbridge. This 
>means that there could coexist "regions" running MSTP with their own 
>VLANs and multiple spanning trees inside the region, these regions 
>inserted between rbridges that use another type (range or IDs) of VLANs. 
>My understanding is then that the only VLANs capable of traversing the 
>campus end-to-end would be the VLANs handled by Rbridges, as the other 
>would be stopped by Rbridges if they are not known by them. 
>
>c) one per RBridge
>
>  
>
>>Why bother: for IP multicasts, if RBridges do IGMP snooping, then this 
>>allows
>>optimal delivery from source to the receivers of a particular multicast.
>>
>>Another reason is that it minimizes out of order delivery of packets in the
>>case when S it talking to D, and initially D is unknown by the RBridges 
>>and packets
>>have to be sent over a spanning tree rather than on the shortest path 
>>    
>>
>>from S to D.
>  
>
>> 
>>
>>    
>>
>One tree per bridge is very efficient together with IGMP snooping, 
>assuming a core of rbridges. The plus point is that in this case the 
>multiple trees can also perform routing of unicast traffic, if used 
>together with the MAC address learning mechanism. In other words: 
>assuming a core formed by rbridges,  using an spaning tree per rbridge 
>may be enough to perform all the routing via minimum paths. This 
>requires that the  address learning mechanism works over the trees (the 
>trees coincide in opposite directions A to B and B to A, a tricky issue 
>when path costs can be equal).  So it seems that there is some 
>overlapping or overkillling using multiple spanning trees for 
>broadcast/multicast and Dijkstra routing for unicast and simplifications 
>are  possible.
>
>  
>
>>********
>>I personally don't have strong opinions on this. If only a miniscule 
>>amount of
>>the traffic is multicast/unknown, then one spanning tree seems good 
>>enough. If
>>there's high volume IP-derived multicast applications, then perhaps one per
>>RBridge would be worth it.
>>
>>So I guess I'd be inclined to either just have one spanning tree, or one per
>>ingress RBridge.
>>
>>And if we did one per ingress RBridge, would it be worth computing all 
>>those trees
>>in advance just in case, or only computing one when necessary?
>>
>>Radia
>>
>>_______________________________________________
>>rbridge mailing list
>>[email-masked]
>>http://www.postel.org/mailman/listinfo/rbridge
>>
>> 
>>
>>    
>>
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>

Date: Tue, 28 Jun 2005 17:54:24 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] How many spanning trees?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3986

Guillermo Ib??ez wrote:
This is my feedback on the "how many spanning trees" issue.

Radia Perlman wrote:

>It would be nice to get opinions on remaining issues, and I think each
>issue should be in a different email thread, so I'm starting one.
>
>How many spanning
>trees should RBridges compute? Given the link state database, they can 
>calculate
>as many as we want without further protocol messages. The possibilities are:
>
>a) one spanning tree: This is simplest, obviously. 
>
The poor performance in the core for multicast is an important argument 
against it. Other possibilities should exist, at least as an option.

>b) one per VLAN: How it would work:each RBridge announces, in its link state info, which VLANs that
>RBridge is attached to.  To calculate a spanning tree for VLAN A, the 
>RBridges 
>(all of them...not just those attached to VLAN A) choose the RBridge, 
>RA, that
>has the lowest ID, AND that is attached to VLAN A. A spanning tree is 
>calculated
>with RA as root. THat spanning tree is pruned so that only branches that 
>reach
>other VLAN A links survive.
>
>Why bother: If only a few links are VLAN A, then this allows more 
>optimal delivery
>of multicast/unknown frames within the VLAN A broadcast domain.
>  
>

It seems that with this implementation  compatibility (interoperability) 
with bridges running Multiple Spanning Tree Protocol (MSTP) is 
excluded.  If bridges running MSTP exist  in the campus network, they 
must be confined in one or several MST regions with their specific 
VLAN-to-spanning tree instance mappings and,  like happens with STP or 
RSTP, the trees will end at the region boundary with an rbridge. This 
means that there could coexist "regions" running MSTP with their own 
VLANs and multiple spanning trees inside the region, these regions 
inserted between rbridges that use another type (range or IDs) of VLANs. 
My understanding is then that the only VLANs capable of traversing the 
campus end-to-end would be the VLANs handled by Rbridges, as the other 
would be stopped by Rbridges if they are not known by them. 

c) one per RBridge

>Why bother: for IP multicasts, if RBridges do IGMP snooping, then this 
>allows
>optimal delivery from source to the receivers of a particular multicast.
>
>Another reason is that it minimizes out of order delivery of packets in the
>case when S it talking to D, and initially D is unknown by the RBridges 
>and packets
>have to be sent over a spanning tree rather than on the shortest path 
>from S to D.
>
>  
>
One tree per bridge is very efficient together with IGMP snooping, 
assuming a core of rbridges. The plus point is that in this case the 
multiple trees can also perform routing of unicast traffic, if used 
together with the MAC address learning mechanism. In other words: 
assuming a core formed by rbridges,  using an spaning tree per rbridge 
may be enough to perform all the routing via minimum paths. This 
requires that the  address learning mechanism works over the trees (the 
trees coincide in opposite directions A to B and B to A, a tricky issue 
when path costs can be equal).  So it seems that there is some 
overlapping or overkillling using multiple spanning trees for 
broadcast/multicast and Dijkstra routing for unicast and simplifications 
are  possible.

>********
>I personally don't have strong opinions on this. If only a miniscule 
>amount of
>the traffic is multicast/unknown, then one spanning tree seems good 
>enough. If
>there's high volume IP-derived multicast applications, then perhaps one per
>RBridge would be worth it.
>
>So I guess I'd be inclined to either just have one spanning tree, or one per
>ingress RBridge.
>
>And if we did one per ingress RBridge, would it be worth computing all 
>those trees
>in advance just in case, or only computing one when necessary?
>
>Radia
>
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

Date: Mon, 27 Jun 2005 20:02:51 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] L3 vs. L2 encapsulation
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1894

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

The use of L2, L2+shim, or L3 encapsulation doesn't impact what
protocols can be included, It DOES impact the routing protocols in use,
however, so we probably ought to think about it a little.

Jeo

Radia Perlman wrote:
> We've been assuming an L2 encapsulation, and that's what I'd prefer. 
> That not only saves room in the header, but
> does not a priori require assigning L3 addresses, and also automatically 
> supports both IPv4 and IPv6.
> 
> Radia
> 
> Alper Yegin wrote:
> 
> 
>>One of the issues listed in draft-perlman-rbridge-03.txt is the choice
>>of encapsulation. See Section 5.5 for a detailed discussion. 
>>
>>Can we close that issue agreeing to a L3 encapsulation? 
>>
>>This does not prevent anyone designing a L2 encapsulated version by
>>reusing the base spec(s) as much as possible. That should be outside the
>>scope of the WG though.
>>
>>Comments welcome.
>>
>>Alper
>>
>>
>>
>>_______________________________________________
>>rbridge mailing list
>>[email-masked]
>>http://www.postel.org/mailman/listinfo/rbridge
>> 
>>
> 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://www.postel.org/mailman/listinfo/rbridge

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

--------------enigC63F4A3AE755D95285066512--

Date: Mon, 27 Jun 2005 15:58:53 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] L3 vs. L2 encapsulation
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 792

We've been assuming an L2 encapsulation, and that's what I'd prefer. 
That not only saves room in the header, but
does not a priori require assigning L3 addresses, and also automatically 
supports both IPv4 and IPv6.

Radia

Alper Yegin wrote:

>One of the issues listed in draft-perlman-rbridge-03.txt is the choice
>of encapsulation. See Section 5.5 for a detailed discussion. 
>
>Can we close that issue agreeing to a L3 encapsulation? 
>
>This does not prevent anyone designing a L2 encapsulated version by
>reusing the base spec(s) as much as possible. That should be outside the
>scope of the WG though.
>
>Comments welcome.
>
>Alper
>
>
>
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>

Date: Mon, 27 Jun 2005 15:54:48 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] How many spanning trees?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1911

It would be nice to get opinions on remaining issues, and I think each
issue should be in a different email thread, so I'm starting one.

How many spanning
trees should RBridges compute? Given the link state database, they can 
calculate
as many as we want without further protocol messages. The possibilities are:

a) one spanning tree: This is simplest, obviously.

b) one per VLAN: How it would work:
each RBridge announces, in its link state info, which VLANs that
RBridge is attached to.  To calculate a spanning tree for VLAN A, the 
RBridges
(all of them...not just those attached to VLAN A) choose the RBridge, 
RA, that
has the lowest ID, AND that is attached to VLAN A. A spanning tree is 
calculated
with RA as root. THat spanning tree is pruned so that only branches that 
reach
other VLAN A links survive.

Why bother: If only a few links are VLAN A, then this allows more 
optimal delivery
of multicast/unknown frames within the VLAN A broadcast domain.

c) one per RBridge

Why bother: for IP multicasts, if RBridges do IGMP snooping, then this 
allows
optimal delivery from source to the receivers of a particular multicast.

Another reason is that it minimizes out of order delivery of packets in the
case when S it talking to D, and initially D is unknown by the RBridges 
and packets
have to be sent over a spanning tree rather than on the shortest path 
from S to D.

********
I personally don't have strong opinions on this. If only a miniscule 
amount of
the traffic is multicast/unknown, then one spanning tree seems good 
enough. If
there's high volume IP-derived multicast applications, then perhaps one per
RBridge would be worth it.

So I guess I'd be inclined to either just have one spanning tree, or one per
ingress RBridge.

And if we did one per ingress RBridge, would it be worth computing all 
those trees
in advance just in case, or only computing one when necessary?

Radia

Date: Mon, 27 Jun 2005 15:40:27 -0700
From: Alper Yegin <[email-masked]>
To: [email-masked]
Importance: Normal
Subject: [rbridge] L3 vs. L2 encapsulation
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 388

One of the issues listed in draft-perlman-rbridge-03.txt is the choice
of encapsulation. See Section 5.5 for a detailed discussion. 

Can we close that issue agreeing to a L3 encapsulation? 

This does not prevent anyone designing a L2 encapsulated version by
reusing the base spec(s) as much as possible. That should be outside the
scope of the WG though.

Comments welcome.

Alper

Date: Mon, 27 Jun 2005 02:10:32 -0700
From: Erik Nordmark <[email-masked]>
To: [email-masked]
Subject: [rbridge] We have a WG
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 181

The IESG approved the TRILL WG last Thursday.
Now we need to put together an agenda for Paris and start working on the 
charter items.

I'll send out more details later,
    Erik

Date: Thu, 23 Jun 2005 08:19:31 -0400
To: "W. Mark Townsley" <[email-masked]>, Adrian Farrel <[email-masked]>
From: Margaret Wasserman <[email-masked]>
Cc: [email-masked], Kireeti Kompella <[email-masked]>, IAB <[email-masked]>, [email-masked], dimitri papadimitriou <[email-masked]>
Subject: Re: [rbridge] WG Review: Transparent Interconnection of Lots of Links (trill)
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 9821

Hi Mark,

I was about to insert this text into the TRILL charter, but I wanted 
to tune it a bit and was looking at the CCAMP charter for reference, 
and now I am confused...

The CCAMP WG does not have any non-completed charter items, and I 
don't see any of it current charter items that relate to flooding 
topology information for Ethernet networks.  From the public 
appearance of the charter, it seems that CCAMP has completed its work 
and should be shutting down.

What work is currently on-going in CCAMP, and when are we expecting 
to review a charter that contains those work items?

I am somewhat concerned about listing tasks for the CCAMP WG in the 
TRILL charter that are not reflected in the CCAMP charter.   Would it 
be acceptable to work out any overlap between TRILL and future CCAMP 
charter items when/if we charter the CCAMP WG to do that work?

Margaret

At 5:07 PM -0400 6/16/05, W. Mark Townsley wrote:
>Including the IAB, CCAMP chairs, and Dimitri
>
>Adrian,
>
>You're not the first who has brought up possible overlap with CCAMP. 
>Taking some of the wording from your concern in your email and 
>adding to it a bit after talking with Loa, I crafted this sentence 
>as a proposed addition to the charter to help capture the concern:
>
>"It is recognized that CCAMP may be solving similar issues that 
>TRILL may encounter, specifically with respect to the use of routing 
>protocols (in this case OSPF-TE) to flood topology information that 
>pertains to an Ethernet Network. The TRILL WG will work closely with 
>the CCAMP WG to reduce duplication of effort and resolve any 
>interoperability concerns that may arise due to this."
>
>Does this at least satisfy your concern that the potential issues 
>are identified up front? Of course, it is then incumbant for the 
>chairs, ADs, and folks participating in ccamp and trill to do the 
>right thing.
>
>Thanks,
>
>- Mark
>
>
>The TRILL WG will work closely with CCAMP
>
>IGPs to flood topology
>information that pertains to the Ethernet network. I suggest that this
>means that CCAMP and TRILL need to work together closely to ensure that
>there is no duplication of effort.
>
>
>Adrian Farrel wrote:
>
>>  Hi,
>>  I do not oppose the creation of this WG, but I would like to draw to your
>>  attention that CCAMP covers (through GMPLS) the installation of forwarding
>>  state on devices within Ethernet arbitrary networks. This is (of course)
>>  not limited to shortest path, but includes constrained shortest path such
>>  as might be used to achieve traffic engineering within an Ethernet
>>  network. CCAMP currently has a design team looking at the necessary
>>  framework and deployment scenarios with the following charter:
>>    Charter for the CCAMP Layer 2 Ethernet Design Team
>>        GMPLS signaling and routing is applicable to Layer 2.
>>        However, up to now, very little attention has been given to the
>>        control of Ethernet switches using GMPLS protocols.
>>        This Design Team is chartered to start the work of applying
>>        GMPLS to Ethernet devices by developing a framework draft that
>>        covers possible deployment scenarios, identifies the consequent
>>        requirements, and highlights possible interactions with other
>>        SDOs.
>>        The sole objective of the Design Team is to produce this
>>        framework draft which should be around 10 pages in length.
>>        Solutions work is out of scope at this time.
>>        The draft will be ready for discussion at the Paris IETF.
>>  It is not clear to me whether there is any overlap with TRILL, but there
>>  may be since both WGs are proposing to use IGPs to flood topology
>>  information that pertains to the Ethernet network. I suggest that this
>>  means that CCAMP and TRILL need to work together closely to ensure that
>>  there is no duplication of effort.
>>  Thanks,
>>  Adrian
>>  PS. Lovely acronym, but is "Transparent Interconnection of Lots of Links"
>>  really a good description of what the WG is chartered to do?
>>
>>  ----- Original Message ----- From: "The IESG" <[email-masked]>
>>  To: <[email-masked]>
>>  Cc: <[email-masked]>
>>  Sent: Wednesday, June 15, 2005 7:52 PM
>>  Subject: WG Review: Transparent Interconnection of Lots of Links (trill)
>>
>>
>>>A new IETF working group has been proposed in the Internet Area. The
>>  IESG has
>>
>>>not made any determination as yet. The following draft charter was
>>  submitted,
>>
>>>and is provided for informational purposes only. Please send your
>>  comments to
>>
>>>the IESG mailing list ([email-masked]) by June 22nd.
>>>
>>>+++
>>>
>>>Transparent Interconnection of Lots of Links (trill)
>>>=====================================================
>>>
>>>Current Status: Proposed Working Group
>>>
>>>Chair(s):
>>>TBD
>>>
>>>Internet Area Director(s):
>>>Mark Townsley <[email-masked]>
>>>Margaret Wasserman <[email-masked]>
>>>
>>>Internet Area Advisor:
>>>Mark Townsley <[email-masked]>
>>>
>>>Technical Advisor:
>>>Bill Fenner <[email-masked]>
>>>
>>>Secretary(ies):
>>>TBD
>>>
>>>Mailing Lists:
>>>General Discussion: [email-masked]
>>>To Subscribe: http://www.postel.org/mailman/listinfo/rbridge
>>>Archive: http://www.postel.org/pipermail/rbridge
>>>
>>>Description of Working Group:
>>>
>>>The TRILL WG will design a solution for shortest-path frame routing in
>>>multi-hop IEEE 802.1 Ethernet networks with arbitrary topologies,
>>>using the link-state routing protocol technology.
>>>
>>>This work will initially be based on draft-perlman-rbridge-03.txt.
>>>
>>>The design should have the following properties:
>>>
>>>- Minimal or no configuration required
>>>- Load-splitting among multiple paths
>>>- Routing loop mitigation (possibly through a TTL field)
>>>- Support of multiple points of attachment
>>>- Support for broadcast and multicast
>>>- No significant service delay after attachment
>>>- No less secure than existing bridged solutions
>>>
>>>Any changes introduced to the Ethernet service model should be
>>>analyzed and clearly documented. To ensure compatibility with IEEE
>>>VLANs and the Ethernet service model, the WG will request an IEEE
>>>liaison relationship with IEEE 802.1.
>>>
>>>It is not an explicit requirement that the solution should be able to
>>>run on existing IP routers or IEEE 802 switches as a software upgrade.
>>>However, the working group should take deployment considerations into
>>>account, to ensure that the solution can interwork with bridges in a
>>>flexible manner (e.g., to allow incremental deployment into LANs that
>>>currently use 802.1D bridges).
>>>
>>>The TRILL working will work with the L2VPN WG and IEEE 802.1 to
>>>develop interworking between TRILL and 802.1D bridges at the edge, such
>>>that a bridged sub-cloud could be attached to TRILL devices in more than
>>>one place for redundancy.
>>>
>>>The solution must not interfere with the end-to-end transparency of
>>>the Internet architecture or with end-to-end congestion control and
>>>QOS mechanisms.
>>>
>>>The WG will work on the following items:
>>>
>>>(1) Develop a problem statement and architecture document that
>>>describes the high-level TRILL architecture, discusses the
>>>scalability of that architecture, describe the threat model
>>>and security impacts of the TRILL solution, and describes the
>>>expected impacts (if any) of the TRILL solution on the Ethernet
>>>service model.
>>>
>>>(2) Define the requirements for a TRILL-capable routing protocol, and
>>>select one or more existing routing protocols that could meet
>>>those requirements.
>>>
>>>(3) Work with the appropriate Routing area working group to extend an
>>>existing routing protocol to meet the TRILL working group
>>>requirements.
>>>
>>>Note: The TRILL working group is not chartered to develop a new
>>>routing protocol or to make substantial modifications to an
>>>existing routing protocol. If, during the requirements definition
>>>and selection phase, the TRILL working group discovers that no
>>>existing routing protocol will meet their needs, we will need to
>>>re-assess the TRILL WG charter to determine how/if this work
>>>should proceed.
>>>
>>>(4) Produce a (set of) TRILL specification(s) for standards track
>>>publication that defines what information must be carried in an
>>>encapsulation header for data packets, and determine how to map
>>>that information to various link types (only IEEE 802 links
>>>initially)
>>>
>>>The TRILL working group is chartered to undertake all of the above
>>>tasks and may begin work on more than one of these tasks in parallel.
>>>However, the problem statement and architecture document should be
>>>completed before the details of the base protocol are finalized, while
>>>there is still time to consider changes to the architecture without
>>>major impacts on established specifications.
>>>
>>>Goals and Milestones:
>>>
>>>Aug 05 Accept Problem statement and architecture document as a WG
>>>work item
>>>Aug 05 Accept base protocol specification as a WG document
>>>Oct 05 Accept routing protocol requirements as a WG work item
>>>Dec 05 Submit problem statement and architecture document to the IESG
>>>for publication as an Informational RFC
>>>Mar 06 Submit routing protocol requirements to the IESG for
>>>publication as an Informational RFC
>>>Mar 06 Choose routing protocol(s) that can meet the requirements.
>>>Apr 06 Start work with routing area WG(s) to undertake TRILL extensions.
>>>Sep 06 Base protocol specification submitted to the IESG for
>>>publication as a Proposed Standard RFC
>>>Dec 06 Re-charter or shut down the WG
>>>
>>>
>>>_______________________________________________
>>>IETF-Announce mailing list
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/ietf-announce
>>>
>>>
>>

Date: Thu, 23 Jun 2005 17:03:11 +1000
From: Greg Daley <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Priority: normal
Cc: "Manfredi, Albert E" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [rbridge] Fwd: Re: WG Review: Transparent Interconnection of Lots ofLinks (trill)
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3006

Hi Pekka, 

----- Original Message -----
From: Pekka Savola <[email-masked]>
Date: Thursday, June 23, 2005 2:08 pm
Subject: Re: [rbridge] Fwd: Re: WG Review: Transparent Interconnection 
of Lots ofLinks (trill)

> On Wed, 22 Jun 2005, Manfredi, Albert E wrote:
> > But this seems to create confusion. Maybe I'm confused, but I don't
> > think TRILL is going after creating larger layer 2 nets at all, 
> right?> Just attempting to do something more clever than a 
> spanning tree for the
> > layer 2 catenet.
> 
> Maybe not intentionally, but I think that will be the result.  A 
> usage 
> case that has been shown has been a hospital whose network (with 
> thousands of hosts) is a single broadcast domain.
> 
> I think everyone can agree that instead of making such large 
> broadcast 
> domains, the network should be split up by routing instead.

Apart from this particular network, there has been a progression
of activities in IPv6, MAGMA etc, which aim at providing better
link size scalability (actually stability).

The availability of link-local multicast in IPv6 and multicast
snooping has effectively removed the broadcast domain size bottleneck
which was present in IPX, and to some extent in IPv4.

The bottleneck has begun to move to the spanning tree, which 
can benefit from hierarchical division, in order to isolate
the bulk of the network from low-reliability edge device failure.
 
This is not saying that trill is for making huge networks, 
but for the size networks people are likely to want to run, there
are stability (and possible scalability) advantages gained from
using a separate SPF core for shipping packets.

> While TRILL would "fix" the usage case above so that using a 
> single 
> broadcast domain would still "work", that would still be very bad 
> network design, and in the longer term, it would probably be 
> counter-productive.

That is if the goal is to make very large networks.
Within the Trill and Rbridge BoFs this was particularly mentioned
as not being a goal.

> (In our environment, what we've seen recently is *decrease* in the 
> size of broadcast domains/subnets due to the requirements to 
> isolate 
> and filter the traffic from other hosts at the site.  Using a 
> single 
> domain makes this security issue much worse.)

Certainly, there's a different security model for single LANs and
routed networks which provide configuration stability.
The cost is that you need to have per-subnet addressing assignments,
and additional configuration for the filtering.

In environments which do not require this level of differentiation 
between
classes of hosts (single security domain, for example) the cost of
dividing subnets seems to be a lot higher than plugging in a new trill
router.

It's reasonable that if Trill is adopted as a WG, its documents should
mention these restrictions (which are inherent to LANs rather than 
TRILL), but I don't see them as a reason to not develop rbridges,
since deployment scenarios vary widely.

Greg Daley

Date: Thu, 23 Jun 2005 07:08:11 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: "Manfredi, Albert E" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [rbridge] Fwd: Re: WG Review: Transparent Interconnection of Lots ofLinks (trill)
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1270

On Wed, 22 Jun 2005, Manfredi, Albert E wrote:
> But this seems to create confusion. Maybe I'm confused, but I don't
> think TRILL is going after creating larger layer 2 nets at all, right?
> Just attempting to do something more clever than a spanning tree for the
> layer 2 catenet.

Maybe not intentionally, but I think that will be the result.  A usage 
case that has been shown has been a hospital whose network (with 
thousands of hosts) is a single broadcast domain.

I think everyone can agree that instead of making such large broadcast 
domains, the network should be split up by routing instead.

While TRILL would "fix" the usage case above so that using a single 
broadcast domain would still "work", that would still be very bad 
network design, and in the longer term, it would probably be 
counter-productive.

(In our environment, what we've seen recently is *decrease* in the 
size of broadcast domains/subnets due to the requirements to isolate 
and filter the traffic from other hosts at the site.  Using a single 
domain makes this security issue much worse.)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Date: Fri, 17 Jun 2005 11:23:49 -0700
From: Alex Zinin <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, IAB <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], dimitri papadimitriou <[email-masked]>, Adrian Farrel <[email-masked]>
Subject: Re: [rbridge] WG Review: Transparent Interconnection of Lots of Links (trill)
Reply-To: Alex Zinin <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 278

Joe,

> My impression is that TRILL is an architecture into which CCAMP might be
> plugged, but not necessarily exclusively CCAMP. I don't see any conflict
> or need to differentiate if that's the case.

I don't quite understand this. Could you please elaborate?

Thanks.
Alex

Date: Fri, 17 Jun 2005 09:16:13 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Cc: Kireeti Kompella <[email-masked]>, Adrian Farrel <[email-masked]>, IAB <[email-masked]>, [email-masked], dimitri papadimitriou <[email-masked]>
Subject: Re: [rbridge] WG Review: Transparent Interconnection of Lots of Links (trill)
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2046

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

My impression is that TRILL is an architecture into which CCAMP might be
plugged, but not necessarily exclusively CCAMP. I don't see any conflict
or need to differentiate if that's the case.

Joe

Date: Fri, 17 Jun 2005 08:53:40 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Cc: Kireeti Kompella <[email-masked]>, Adrian Farrel <[email-masked]>, IAB <[email-masked]>, [email-masked], dimitri papadimitriou <[email-masked]>
Subject: Re: [rbridge] WG Review: Transparent Interconnection of Lots of Links (trill)
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2289

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

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

Radia

W. Mark Townsley wrote:

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

Date: Fri, 17 Jun 2005 09:24:31 -0400
From: "W. Mark Townsley" <[email-masked]>
To: Adrian Farrel <[email-masked]>
Cc: [email-masked], IAB <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], dimitri papadimitriou <[email-masked]>
Subject: Re: [rbridge] WG Review: Transparent Interconnection of Lots of Links (trill)
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1475

Adrian Farrel wrote:

>  > In any case, given that ISIS is not mentioned in the TRILL charter, and
>  > presumably that we haven't actually made the choice of *which* routing
>  > protocol TRILL will use at the charter level, I agree that this reference
>  > should be removed.
>  
> OK, that makes sense. Thanks.
>  
> It occurs to me that a fundamental difference between CCAMP and TRILL 
> may be that (at this stage) CCAMP assumes the existence of an IP-based 
> control plane. TRILL will (presumably? possibly?)

I believe  "presumably," at least that is my understanding thus far. The idea 
that there is at least one mode of operation that passes packets right "out of 
the box" is fundamental. Certainly, an IP address needs to exist on the node for 
it to be properly managed, but it seems that this is *after* its connection to 
the network has started to cause big problems ;-)

 > determine that the
> routing protocol should be carried direct over the MAC layer. 
> Nevertheless, we will probably want to flood the same or similar 
> information about the links.

Yes, I think that this is the part that we should be sure to collaborate on. If 
CCAMP has already provided extensions to routing protocols to flood MACs, we 
should probably try and do it as similarly as possible for the poor coders out 
there that will end up doing both, while ensuring we have the proper code-points 
in place to avoid stepping on one another where it hurts.

Thanks,

- Mark

Date: Fri, 17 Jun 2005 03:02:15 -0400
From: "W. Mark Townsley" <[email-masked]>
To: Adrian Farrel <[email-masked]>
Cc: [email-masked], IAB <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], dimitri papadimitriou <[email-masked]>
Subject: Re: [rbridge] WG Review: Transparent Interconnection of Lots of Links (trill)
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 9685

Adrian Farrel wrote:

> Hi Mark,
> 
> Thanks for being responsive.
> 
> 
>>"It is recognized that CCAMP may be solving similar issues that TRILL
> 
> may
> 
>>encounter, specifically with respect to the use of routing protocols (in
> 
> this
> 
>>case OSPF-TE) to flood topology information that pertains to an Ethernet
>>Network. The TRILL WG will work closely with the CCAMP WG to reduce
> 
> duplication
> 
>>of effort and resolve any interoperability concerns that may arise due
> 
> to this."
> 
> This looks good.
> I think we should remove "(in this case OSPF-TE)" from the paragraph since
> I don't see any mention of OSPF in the TRILL charter.

Loa's main concern as voiced to me was that TRILL, which is perhaps already 
posed to gravitate towards ISIS, and CCAMP, which uses OSPF-TE, may in the end 
cause some problems - particularly, I suppose, if the two actually tried to work 
together.

In any case, given that ISIS is not mentioned in the TRILL charter, and 
presumably that we haven't actually made the choice of *which* routing protocol 
TRILL will use at the charter level, I agree that this reference should be removed.

Thanks,

- Mark

> 
> 
>>Does this at least satisfy your concern that the potential issues are
> 
> identified
> 
>>up front? Of course, it is then incumbant for the chairs, ADs, and folks
>>participating in ccamp and trill to do the right thing.
> 
> 
> Yup. More drafts to read ;-)
> 
> Thanks,
> Adrian
> 
> 
>>Thanks,
>>
>>- Mark
>>
>>
>>The TRILL WG will work closely with CCAMP
>>
>>IGPs to flood topology
>>information that pertains to the Ethernet network. I suggest that this
>>means that CCAMP and TRILL need to work together closely to ensure that
>>there is no duplication of effort.
>>
>>
>>Adrian Farrel wrote:
>>
>>
>>>Hi,
>>>
>>>I do not oppose the creation of this WG, but I would like to draw to
> 
> your
> 
>>>attention that CCAMP covers (through GMPLS) the installation of
> 
> forwarding
> 
>>>state on devices within Ethernet arbitrary networks. This is (of
> 
> course)
> 
>>>not limited to shortest path, but includes constrained shortest path
> 
> such
> 
>>>as might be used to achieve traffic engineering within an Ethernet
>>>network. CCAMP currently has a design team looking at the necessary
>>>framework and deployment scenarios with the following charter:
>>>
>>>  Charter for the CCAMP Layer 2 Ethernet Design Team
>>>
>>>      GMPLS signaling and routing is applicable to Layer 2.
>>>      However, up to now, very little attention has been given to the
>>>      control of Ethernet switches using GMPLS protocols.
>>>
>>>      This Design Team is chartered to start the work of applying
>>>      GMPLS to Ethernet devices by developing a framework draft that
>>>      covers possible deployment scenarios, identifies the consequent
>>>      requirements, and highlights possible interactions with other
>>>      SDOs.
>>>
>>>      The sole objective of the Design Team is to produce this
>>>      framework draft which should be around 10 pages in length.
>>>      Solutions work is out of scope at this time.
>>>
>>>      The draft will be ready for discussion at the Paris IETF.
>>>
>>>It is not clear to me whether there is any overlap with TRILL, but
> 
> there
> 
>>>may be since both WGs are proposing to use IGPs to flood topology
>>>information that pertains to the Ethernet network. I suggest that this
>>>means that CCAMP and TRILL need to work together closely to ensure
> 
> that
> 
>>>there is no duplication of effort.
>>>
>>>Thanks,
>>>Adrian
>>>
>>>PS. Lovely acronym, but is "Transparent Interconnection of Lots of
> 
> Links"
> 
>>>really a good description of what the WG is chartered to do?
>>>
>>>
>>>
>>>----- Original Message ----- 
>>>From: "The IESG" <[email-masked]>
>>>To: <[email-masked]>
>>>Cc: <[email-masked]>
>>>Sent: Wednesday, June 15, 2005 7:52 PM
>>>Subject: WG Review: Transparent Interconnection of Lots of Links
> 
> (trill)
> 
>>>
>>>
>>>>A new IETF working group has been proposed in the Internet Area. The
>>>
>>>IESG has
>>>
>>>
>>>>not made any determination as yet. The following draft charter was
>>>
>>>submitted,
>>>
>>>
>>>>and is provided for informational purposes only. Please send your
>>>
>>>comments to
>>>
>>>
>>>>the IESG mailing list ([email-masked]) by June 22nd.
>>>>
>>>>+++
>>>>
>>>>Transparent Interconnection of Lots of Links (trill)
>>>>=====================================================
>>>>
>>>>Current Status: Proposed Working Group
>>>>
>>>>Chair(s):
>>>>TBD
>>>>
>>>>Internet Area Director(s):
>>>>Mark Townsley <[email-masked]>
>>>>Margaret Wasserman <[email-masked]>
>>>>
>>>>Internet Area Advisor:
>>>>Mark Townsley <[email-masked]>
>>>>
>>>>Technical Advisor:
>>>>Bill Fenner <[email-masked]>
>>>>
>>>>Secretary(ies):
>>>>TBD
>>>>
>>>>Mailing Lists:
>>>>General Discussion: [email-masked]
>>>>To Subscribe: http://www.postel.org/mailman/listinfo/rbridge
>>>>Archive: http://www.postel.org/pipermail/rbridge
>>>>
>>>>Description of Working Group:
>>>>
>>>>The TRILL WG will design a solution for shortest-path frame routing in
>>>>multi-hop IEEE 802.1 Ethernet networks with arbitrary topologies,
>>>>using the link-state routing protocol technology.
>>>>
>>>>This work will initially be based on draft-perlman-rbridge-03.txt.
>>>>
>>>>The design should have the following properties:
>>>>
>>>>- Minimal or no configuration required
>>>>- Load-splitting among multiple paths
>>>>- Routing loop mitigation (possibly through a TTL field)
>>>>- Support of multiple points of attachment
>>>>- Support for broadcast and multicast
>>>>- No significant service delay after attachment
>>>>- No less secure than existing bridged solutions
>>>>
>>>>Any changes introduced to the Ethernet service model should be
>>>>analyzed and clearly documented. To ensure compatibility with IEEE
>>>>VLANs and the Ethernet service model, the WG will request an IEEE
>>>>liaison relationship with IEEE 802.1.
>>>>
>>>>It is not an explicit requirement that the solution should be able to
>>>>run on existing IP routers or IEEE 802 switches as a software upgrade.
>>>>However, the working group should take deployment considerations into
>>>>account, to ensure that the solution can interwork with bridges in a
>>>>flexible manner (e.g., to allow incremental deployment into LANs that
>>>>currently use 802.1D bridges).
>>>>
>>>>The TRILL working will work with the L2VPN WG and IEEE 802.1 to
>>>>develop interworking between TRILL and 802.1D bridges at the edge,
> 
> such
> 
>>>>that a bridged sub-cloud could be attached to TRILL devices in more
> 
> than
> 
>>>>one place for redundancy.
>>>>
>>>>The solution must not interfere with the end-to-end transparency of
>>>>the Internet architecture or with end-to-end congestion control and
>>>>QOS mechanisms.
>>>>
>>>>The WG will work on the following items:
>>>>
>>>>(1) Develop a problem statement and architecture document that
>>>>describes the high-level TRILL architecture, discusses the
>>>>scalability of that architecture, describe the threat model
>>>>and security impacts of the TRILL solution, and describes the
>>>>expected impacts (if any) of the TRILL solution on the Ethernet
>>>>service model.
>>>>
>>>>(2) Define the requirements for a TRILL-capable routing protocol, and
>>>>select one or more existing routing protocols that could meet
>>>>those requirements.
>>>>
>>>>(3) Work with the appropriate Routing area working group to extend an
>>>>existing routing protocol to meet the TRILL working group
>>>>requirements.
>>>>
>>>>Note: The TRILL working group is not chartered to develop a new
>>>>routing protocol or to make substantial modifications to an
>>>>existing routing protocol. If, during the requirements definition
>>>>and selection phase, the TRILL working group discovers that no
>>>>existing routing protocol will meet their needs, we will need to
>>>>re-assess the TRILL WG charter to determine how/if this work
>>>>should proceed.
>>>>
>>>>(4) Produce a (set of) TRILL specification(s) for standards track
>>>>publication that defines what information must be carried in an
>>>>encapsulation header for data packets, and determine how to map
>>>>that information to various link types (only IEEE 802 links
>>>>initially)
>>>>
>>>>The TRILL working group is chartered to undertake all of the above
>>>>tasks and may begin work on more than one of these tasks in parallel.
>>>>However, the problem statement and architecture document should be
>>>>completed before the details of the base protocol are finalized, while
>>>>there is still time to consider changes to the architecture without
>>>>major impacts on established specifications.
>>>>
>>>>Goals and Milestones:
>>>>
>>>>Aug 05 Accept Problem statement and architecture document as a WG
>>>>work item
>>>>Aug 05 Accept base protocol specification as a WG document
>>>>Oct 05 Accept routing protocol requirements as a WG work item
>>>>Dec 05 Submit problem statement and architecture document to the IESG
>>>>for publication as an Informational RFC
>>>>Mar 06 Submit routing protocol requirements to the IESG for
>>>>publication as an Informational RFC
>>>>Mar 06 Choose routing protocol(s) that can meet the requirements.
>>>>Apr 06 Start work with routing area WG(s) to undertake TRILL
> 
> extensions.
> 
>>>>Sep 06 Base protocol specification submitted to the IESG for
>>>>publication as a Proposed Standard RFC
>>>>Dec 06 Re-charter or shut down the WG
>>>>
>>>>
>>>>_______________________________________________
>>>>IETF-Announce mailing list
>>>>[email-masked]
>>>>https://www1.ietf.org/mailman/listinfo/ietf-announce
>>>>
>>>>
>>>
>>>
>>
> 

Date: Thu, 16 Jun 2005 19:56:10 -0400
To: "Developing a hybrid router/bridge." <[email-masked]>
From: Margaret Wasserman <[email-masked]>
Cc: Joe Touch <[email-masked]>
Subject: Re: [rbridge] forwarded for IETF secretariat
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 6194

Hi Joe,

Thanks for forwarding this to the group. You beat me to it!!  :-)

The IESG will be considering the formation of this WG on our June 
23rd telechat.  If you have any input, positive or negative, 
regarding whether the IESG should charter this working group, please 
send it to [email-masked].

The second BOF was inconclusive regarding whether there is sufficient 
support in the IETF to charter this work, so we would like to see 
positive feedback in support of this work from people who think that 
it should be chartered.  Of course, we are also interested in any 
concerns or objections.

Thanks!
Margaret

At 1:12 PM -0700 6/15/05, Joe Touch wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>A new IETF working group has been proposed in the Internet Area. The
>IESG has not made any determination as yet. The following draft charter
>was submitted, and is provided for informational purposes only. Please
>send your comments to the IESG mailing list ([email-masked]) by June 22nd.
>
>+++
>
>Transparent Interconnection of Lots of Links (trill)
>=====================================================
>
>Current Status: Proposed Working Group
>
>Chair(s):
>TBD
>
>Internet Area Director(s):
>Mark Townsley <[email-masked]>
>Margaret Wasserman <[email-masked]>
>
>Internet Area Advisor:
>Mark Townsley <[email-masked]>
>
>Technical Advisor:
>Bill Fenner <[email-masked]>
>
>Secretary(ies):
>TBD
>
>Mailing Lists:
>General Discussion: [email-masked]
>To Subscribe: http://www.postel.org/mailman/listinfo/rbridge
>Archive: http://www.postel.org/pipermail/rbridge
>
>Description of Working Group:
>
>The TRILL WG will design a solution for shortest-path frame routing in
>multi-hop IEEE 802.1 Ethernet networks with arbitrary topologies,
>using the link-state routing protocol technology.
>
>This work will initially be based on draft-perlman-rbridge-03.txt.
>
>The design should have the following properties:
>
>- - Minimal or no configuration required
>- - Load-splitting among multiple paths
>- - Routing loop mitigation (possibly through a TTL field)
>- - Support of multiple points of attachment
>- - Support for broadcast and multicast
>- - No significant service delay after attachment
>- - No less secure than existing bridged solutions
>
>Any changes introduced to the Ethernet service model should be
>analyzed and clearly documented. To ensure compatibility with IEEE
>VLANs and the Ethernet service model, the WG will request an IEEE
>liaison relationship with IEEE 802.1.
>
>It is not an explicit requirement that the solution should be able to
>run on existing IP routers or IEEE 802 switches as a software upgrade.
>However, the working group should take deployment considerations into
>account, to ensure that the solution can interwork with bridges in a
>flexible manner (e.g., to allow incremental deployment into LANs that
>currently use 802.1D bridges).
>
>The TRILL working will work with the L2VPN WG and IEEE 802.1 to
>develop interworking between TRILL and 802.1D bridges at the edge, such
>that a bridged sub-cloud could be attached to TRILL devices in more than
>one place for redundancy.
>
>The solution must not interfere with the end-to-end transparency of
>the Internet architecture or with end-to-end congestion control and
>QOS mechanisms.
>
>The WG will work on the following items:
>
>(1) Develop a problem statement and architecture document that
>describes the high-level TRILL architecture, discusses the
>scalability of that architecture, describe the threat model
>and security impacts of the TRILL solution, and describes the
>expected impacts (if any) of the TRILL solution on the Ethernet
>service model.
>
>(2) Define the requirements for a TRILL-capable routing protocol, and
>select one or more existing routing protocols that could meet
>those requirements.
>
>(3) Work with the appropriate Routing area working group to extend an
>existing routing protocol to meet the TRILL working group
>requirements.
>
>Note: The TRILL working group is not chartered to develop a new
>routing protocol or to make substantial modifications to an
>existing routing protocol. If, during the requirements definition
>and selection phase, the TRILL working group discovers that no
>existing routing protocol will meet their needs, we will need to
>re-assess the TRILL WG charter to determine how/if this work
>should proceed.
>
>(4) Produce a (set of) TRILL specification(s) for standards track
>publication that defines what information must be carried in an
>encapsulation header for data packets, and determine how to map
>that information to various link types (only IEEE 802 links
>initially)
>
>The TRILL working group is chartered to undertake all of the above
>tasks and may begin work on more than one of these tasks in parallel.
>However, the problem statement and architecture document should be
>completed before the details of the base protocol are finalized, while
>there is still time to consider changes to the architecture without
>major impacts on established specifications.
>
>Goals and Milestones:
>
>Aug 05 Accept Problem statement and architecture document as a WG
>work item
>Aug 05 Accept base protocol specification as a WG document
>Oct 05 Accept routing protocol requirements as a WG work item
>Dec 05 Submit problem statement and architecture document to the IESG
>for publication as an Informational RFC
>Mar 06 Submit routing protocol requirements to the IESG for
>publication as an Informational RFC
>Mar 06 Choose routing protocol(s) that can meet the requirements.
>Apr 06 Start work with routing area WG(s) to undertake TRILL extensions.
>Sep 06 Base protocol specification submitted to the IESG for
>publication as a Proposed Standard RFC
>Dec 06 Re-charter or shut down the WG
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFCsIuvE5f5cImnZrsRAt8/AKDe36PZ3DPvlTh88c7WidevER2sRgCg1qVS
>BMjgml/pko8Zo9jx+1fVqPQ=
>=UBLl
>-----END PGP SIGNATURE-----
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://www.postel.org/mailman/listinfo/rbridge

Date: Thu, 16 Jun 2005 14:49:39 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] WG Review: Transparent Interconnection of Lots of Links (trill)
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 10738

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

Subject:
Re: WG Review: Transparent Interconnection of Lots of Links (trill)
Forwarded reply:

From:
"Adrian Farrel" <[email-masked]>
Date:
Thu, 16 Jun 2005 22:26:22 +0100
To:
"W. Mark Townsley" <[email-masked]>, "Margaret Wasserman"
<[email-masked]>
CC:
<[email-masked]>, <[email-masked]>, "IAB" <[email-masked]>, "Kireeti
Kompella" <[email-masked]>, "dimitri papadimitriou"
<[email-masked]>

Hi Mark,

Thanks for being responsive.

>> "It is recognized that CCAMP may be solving similar issues that TRILL

may

>> encounter, specifically with respect to the use of routing protocols (in

this

>> case OSPF-TE) to flood topology information that pertains to an Ethernet
>> Network. The TRILL WG will work closely with the CCAMP WG to reduce

duplication

>> of effort and resolve any interoperability concerns that may arise due

to this."

This looks good.
I think we should remove "(in this case OSPF-TE)" from the paragraph since
I don't see any mention of OSPF in the TRILL charter.

>> Does this at least satisfy your concern that the potential issues are

identified

>> up front? Of course, it is then incumbant for the chairs, ADs, and folks
>> participating in ccamp and trill to do the right thing.

Yup. More drafts to read  ;-)

Thanks,
Adrian

>>
>> Thanks,
>>
>> - Mark
>>
>>
>> The TRILL WG will work closely with CCAMP
>>
>> IGPs to flood topology
>> information that pertains to the Ethernet network. I suggest that this
>> means that CCAMP and TRILL need to work together closely to ensure that
>> there is no duplication of effort.
>>
>>
>> Adrian Farrel wrote:
>>
>
>>> > Hi,
>>> >
>>> > I do not oppose the creation of this WG, but I would like to draw to

your

>>> > attention that CCAMP covers (through GMPLS) the installation of

forwarding

>>> > state on devices within Ethernet arbitrary networks. This is (of

course)

>>> > not limited to shortest path, but includes constrained shortest path

such

>>> > as might be used to achieve traffic engineering within an Ethernet
>>> > network. CCAMP currently has a design team looking at the necessary
>>> > framework and deployment scenarios with the following charter:
>>> >
>>> >   Charter for the CCAMP Layer 2 Ethernet Design Team
>>> >
>>> >       GMPLS signaling and routing is applicable to Layer 2.
>>> >       However, up to now, very little attention has been given to the
>>> >       control of Ethernet switches using GMPLS protocols.
>>> >
>>> >       This Design Team is chartered to start the work of applying
>>> >       GMPLS to Ethernet devices by developing a framework draft that
>>> >       covers possible deployment scenarios, identifies the consequent
>>> >       requirements, and highlights possible interactions with other
>>> >       SDOs.
>>> >
>>> >       The sole objective of the Design Team is to produce this
>>> >       framework draft which should be around 10 pages in length.
>>> >       Solutions work is out of scope at this time.
>>> >
>>> >       The draft will be ready for discussion at the Paris IETF.
>>> >
>>> > It is not clear to me whether there is any overlap with TRILL, but

there

>>> > may be since both WGs are proposing to use IGPs to flood topology
>>> > information that pertains to the Ethernet network. I suggest that this
>>> > means that CCAMP and TRILL need to work together closely to ensure

that

>>> > there is no duplication of effort.
>>> >
>>> > Thanks,
>>> > Adrian
>>> >
>>> > PS. Lovely acronym, but is "Transparent Interconnection of Lots of

Links"

>>> > really a good description of what the WG is chartered to do?
>>> >
>>> >
>>> >
>>> > ----- Original Message -----
>>> > From: "The IESG" <[email-masked]>
>>> > To: <[email-masked]>
>>> > Cc: <[email-masked]>
>>> > Sent: Wednesday, June 15, 2005 7:52 PM
>>> > Subject: WG Review: Transparent Interconnection of Lots of Links

(trill)

>>> >
>>> >
>>> >
>>
>>>> >>A new IETF working group has been proposed in the Internet Area. The
>>
>>> >
>>> > IESG has
>>> >
>>
>>>> >>not made any determination as yet. The following draft charter was
>>
>>> >
>>> > submitted,
>>> >
>>
>>>> >>and is provided for informational purposes only. Please send your
>>
>>> >
>>> > comments to
>>> >
>>
>>>> >>the IESG mailing list ([email-masked]) by June 22nd.
>>>> >>
>>>> >>+++
>>>> >>
>>>> >>Transparent Interconnection of Lots of Links (trill)
>>>> >>=====================================================
>>>> >>
>>>> >>Current Status: Proposed Working Group
>>>> >>
>>>> >>Chair(s):
>>>> >>TBD
>>>> >>
>>>> >>Internet Area Director(s):
>>>> >>Mark Townsley <[email-masked]>
>>>> >>Margaret Wasserman <[email-masked]>
>>>> >>
>>>> >>Internet Area Advisor:
>>>> >>Mark Townsley <[email-masked]>
>>>> >>
>>>> >>Technical Advisor:
>>>> >>Bill Fenner <[email-masked]>
>>>> >>
>>>> >>Secretary(ies):
>>>> >>TBD
>>>> >>
>>>> >>Mailing Lists:
>>>> >>General Discussion: [email-masked]
>>>> >>To Subscribe: http://www.postel.org/mailman/listinfo/rbridge
>>>> >>Archive: http://www.postel.org/pipermail/rbridge
>>>> >>
>>>> >>Description of Working Group:
>>>> >>
>>>> >>The TRILL WG will design a solution for shortest-path frame
routing in
>>>> >>multi-hop IEEE 802.1 Ethernet networks with arbitrary topologies,
>>>> >>using the link-state routing protocol technology.
>>>> >>
>>>> >>This work will initially be based on draft-perlman-rbridge-03.txt.
>>>> >>
>>>> >>The design should have the following properties:
>>>> >>
>>>> >>- Minimal or no configuration required
>>>> >>- Load-splitting among multiple paths
>>>> >>- Routing loop mitigation (possibly through a TTL field)
>>>> >>- Support of multiple points of attachment
>>>> >>- Support for broadcast and multicast
>>>> >>- No significant service delay after attachment
>>>> >>- No less secure than existing bridged solutions
>>>> >>
>>>> >>Any changes introduced to the Ethernet service model should be
>>>> >>analyzed and clearly documented. To ensure compatibility with IEEE
>>>> >>VLANs and the Ethernet service model, the WG will request an IEEE
>>>> >>liaison relationship with IEEE 802.1.
>>>> >>
>>>> >>It is not an explicit requirement that the solution should be able to
>>>> >>run on existing IP routers or IEEE 802 switches as a software
upgrade.
>>>> >>However, the working group should take deployment considerations into
>>>> >>account, to ensure that the solution can interwork with bridges in a
>>>> >>flexible manner (e.g., to allow incremental deployment into LANs that
>>>> >>currently use 802.1D bridges).
>>>> >>
>>>> >>The TRILL working will work with the L2VPN WG and IEEE 802.1 to
>>>> >>develop interworking between TRILL and 802.1D bridges at the edge,

such

>>>> >>that a bridged sub-cloud could be attached to TRILL devices in more

than

>>>> >>one place for redundancy.
>>>> >>
>>>> >>The solution must not interfere with the end-to-end transparency of
>>>> >>the Internet architecture or with end-to-end congestion control and
>>>> >>QOS mechanisms.
>>>> >>
>>>> >>The WG will work on the following items:
>>>> >>
>>>> >>(1) Develop a problem statement and architecture document that
>>>> >>describes the high-level TRILL architecture, discusses the
>>>> >>scalability of that architecture, describe the threat model
>>>> >>and security impacts of the TRILL solution, and describes the
>>>> >>expected impacts (if any) of the TRILL solution on the Ethernet
>>>> >>service model.
>>>> >>
>>>> >>(2) Define the requirements for a TRILL-capable routing protocol, and
>>>> >>select one or more existing routing protocols that could meet
>>>> >>those requirements.
>>>> >>
>>>> >>(3) Work with the appropriate Routing area working group to extend an
>>>> >>existing routing protocol to meet the TRILL working group
>>>> >>requirements.
>>>> >>
>>>> >>Note: The TRILL working group is not chartered to develop a new
>>>> >>routing protocol or to make substantial modifications to an
>>>> >>existing routing protocol. If, during the requirements definition
>>>> >>and selection phase, the TRILL working group discovers that no
>>>> >>existing routing protocol will meet their needs, we will need to
>>>> >>re-assess the TRILL WG charter to determine how/if this work
>>>> >>should proceed.
>>>> >>
>>>> >>(4) Produce a (set of) TRILL specification(s) for standards track
>>>> >>publication that defines what information must be carried in an
>>>> >>encapsulation header for data packets, and determine how to map
>>>> >>that information to various link types (only IEEE 802 links
>>>> >>initially)
>>>> >>
>>>> >>The TRILL working group is chartered to undertake all of the above
>>>> >>tasks and may begin work on more than one of these tasks in parallel.
>>>> >>However, the problem statement and architecture document should be
>>>> >>completed before the details of the base protocol are finalized,
while
>>>> >>there is still time to consider changes to the architecture without
>>>> >>major impacts on established specifications.
>>>> >>
>>>> >>Goals and Milestones:
>>>> >>
>>>> >>Aug 05 Accept Problem statement and architecture document as a WG
>>>> >>work item
>>>> >>Aug 05 Accept base protocol specification as a WG document
>>>> >>Oct 05 Accept routing protocol requirements as a WG work item
>>>> >>Dec 05 Submit problem statement and architecture document to the IESG
>>>> >>for publication as an Informational RFC
>>>> >>Mar 06 Submit routing protocol requirements to the IESG for
>>>> >>publication as an Informational RFC
>>>> >>Mar 06 Choose routing protocol(s) that can meet the requirements.
>>>> >>Apr 06 Start work with routing area WG(s) to undertake TRILL

extensions.

>>>> >>Sep 06 Base protocol specification submitted to the IESG for
>>>> >>publication as a Proposed Standard RFC
>>>> >>Dec 06 Re-charter or shut down the WG
>>>> >>
>>>> >>
>>>> >>_______________________________________________
>>>> >>IETF-Announce mailing list
>>>> >>[email-masked]
>>>> >>https://www1.ietf.org/mailman/listinfo/ietf-announce
>>>> >>
>>>> >>
>>
>>> >
>>> >
>
>>
>>

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

--------------enig104352A1ED4E8E145FD88993--

Date: Thu, 16 Jun 2005 17:07:04 -0400
From: "W. Mark Townsley" <[email-masked]>
To: Adrian Farrel <[email-masked]>, Margaret Wasserman <[email-masked]>
Cc: [email-masked], Kireeti Kompella <[email-masked]>, IAB <[email-masked]>, [email-masked], dimitri papadimitriou <[email-masked]>
Subject: Re: [rbridge] WG Review: Transparent Interconnection of Lots of Links (trill)
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 8695

Including the IAB, CCAMP chairs, and Dimitri

Adrian,

You're not the first who has brought up possible overlap with CCAMP. Taking some 
of the wording from your concern in your email and adding to it a bit after 
talking with Loa, I crafted this sentence as a proposed addition to the charter 
to help capture the concern:

"It is recognized that CCAMP may be solving similar issues that TRILL may 
encounter, specifically with respect to the use of routing protocols (in this 
case OSPF-TE) to flood topology information that pertains to an Ethernet 
Network. The TRILL WG will work closely with the CCAMP WG to reduce duplication 
of effort and resolve any interoperability concerns that may arise due to this."

Does this at least satisfy your concern that the potential issues are identified 
up front? Of course, it is then incumbant for the chairs, ADs, and folks 
participating in ccamp and trill to do the right thing.

Thanks,

- Mark

The TRILL WG will work closely with CCAMP

IGPs to flood topology
information that pertains to the Ethernet network. I suggest that this
means that CCAMP and TRILL need to work together closely to ensure that
there is no duplication of effort.

Adrian Farrel wrote:

> Hi,
> 
> I do not oppose the creation of this WG, but I would like to draw to your
> attention that CCAMP covers (through GMPLS) the installation of forwarding
> state on devices within Ethernet arbitrary networks. This is (of course)
> not limited to shortest path, but includes constrained shortest path such
> as might be used to achieve traffic engineering within an Ethernet
> network. CCAMP currently has a design team looking at the necessary
> framework and deployment scenarios with the following charter:
> 
>   Charter for the CCAMP Layer 2 Ethernet Design Team
> 
>       GMPLS signaling and routing is applicable to Layer 2.
>       However, up to now, very little attention has been given to the
>       control of Ethernet switches using GMPLS protocols.
> 
>       This Design Team is chartered to start the work of applying
>       GMPLS to Ethernet devices by developing a framework draft that
>       covers possible deployment scenarios, identifies the consequent
>       requirements, and highlights possible interactions with other
>       SDOs.
> 
>       The sole objective of the Design Team is to produce this
>       framework draft which should be around 10 pages in length.
>       Solutions work is out of scope at this time.
> 
>       The draft will be ready for discussion at the Paris IETF.
> 
> It is not clear to me whether there is any overlap with TRILL, but there
> may be since both WGs are proposing to use IGPs to flood topology
> information that pertains to the Ethernet network. I suggest that this
> means that CCAMP and TRILL need to work together closely to ensure that
> there is no duplication of effort.
> 
> Thanks,
> Adrian
> 
> PS. Lovely acronym, but is "Transparent Interconnection of Lots of Links"
> really a good description of what the WG is chartered to do?
> 
> 
> 
> ----- Original Message ----- 
> From: "The IESG" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, June 15, 2005 7:52 PM
> Subject: WG Review: Transparent Interconnection of Lots of Links (trill)
> 
> 
> 
>>A new IETF working group has been proposed in the Internet Area. The
> 
> IESG has
> 
>>not made any determination as yet. The following draft charter was
> 
> submitted,
> 
>>and is provided for informational purposes only. Please send your
> 
> comments to
> 
>>the IESG mailing list ([email-masked]) by June 22nd.
>>
>>+++
>>
>>Transparent Interconnection of Lots of Links (trill)
>>=====================================================
>>
>>Current Status: Proposed Working Group
>>
>>Chair(s):
>>TBD
>>
>>Internet Area Director(s):
>>Mark Townsley <[email-masked]>
>>Margaret Wasserman <[email-masked]>
>>
>>Internet Area Advisor:
>>Mark Townsley <[email-masked]>
>>
>>Technical Advisor:
>>Bill Fenner <[email-masked]>
>>
>>Secretary(ies):
>>TBD
>>
>>Mailing Lists:
>>General Discussion: [email-masked]
>>To Subscribe: http://www.postel.org/mailman/listinfo/rbridge
>>Archive: http://www.postel.org/pipermail/rbridge
>>
>>Description of Working Group:
>>
>>The TRILL WG will design a solution for shortest-path frame routing in
>>multi-hop IEEE 802.1 Ethernet networks with arbitrary topologies,
>>using the link-state routing protocol technology.
>>
>>This work will initially be based on draft-perlman-rbridge-03.txt.
>>
>>The design should have the following properties:
>>
>>- Minimal or no configuration required
>>- Load-splitting among multiple paths
>>- Routing loop mitigation (possibly through a TTL field)
>>- Support of multiple points of attachment
>>- Support for broadcast and multicast
>>- No significant service delay after attachment
>>- No less secure than existing bridged solutions
>>
>>Any changes introduced to the Ethernet service model should be
>>analyzed and clearly documented. To ensure compatibility with IEEE
>>VLANs and the Ethernet service model, the WG will request an IEEE
>>liaison relationship with IEEE 802.1.
>>
>>It is not an explicit requirement that the solution should be able to
>>run on existing IP routers or IEEE 802 switches as a software upgrade.
>>However, the working group should take deployment considerations into
>>account, to ensure that the solution can interwork with bridges in a
>>flexible manner (e.g., to allow incremental deployment into LANs that
>>currently use 802.1D bridges).
>>
>>The TRILL working will work with the L2VPN WG and IEEE 802.1 to
>>develop interworking between TRILL and 802.1D bridges at the edge, such
>>that a bridged sub-cloud could be attached to TRILL devices in more than
>>one place for redundancy.
>>
>>The solution must not interfere with the end-to-end transparency of
>>the Internet architecture or with end-to-end congestion control and
>>QOS mechanisms.
>>
>>The WG will work on the following items:
>>
>>(1) Develop a problem statement and architecture document that
>>describes the high-level TRILL architecture, discusses the
>>scalability of that architecture, describe the threat model
>>and security impacts of the TRILL solution, and describes the
>>expected impacts (if any) of the TRILL solution on the Ethernet
>>service model.
>>
>>(2) Define the requirements for a TRILL-capable routing protocol, and
>>select one or more existing routing protocols that could meet
>>those requirements.
>>
>>(3) Work with the appropriate Routing area working group to extend an
>>existing routing protocol to meet the TRILL working group
>>requirements.
>>
>>Note: The TRILL working group is not chartered to develop a new
>>routing protocol or to make substantial modifications to an
>>existing routing protocol. If, during the requirements definition
>>and selection phase, the TRILL working group discovers that no
>>existing routing protocol will meet their needs, we will need to
>>re-assess the TRILL WG charter to determine how/if this work
>>should proceed.
>>
>>(4) Produce a (set of) TRILL specification(s) for standards track
>>publication that defines what information must be carried in an
>>encapsulation header for data packets, and determine how to map
>>that information to various link types (only IEEE 802 links
>>initially)
>>
>>The TRILL working group is chartered to undertake all of the above
>>tasks and may begin work on more than one of these tasks in parallel.
>>However, the problem statement and architecture document should be
>>completed before the details of the base protocol are finalized, while
>>there is still time to consider changes to the architecture without
>>major impacts on established specifications.
>>
>>Goals and Milestones:
>>
>>Aug 05 Accept Problem statement and architecture document as a WG
>>work item
>>Aug 05 Accept base protocol specification as a WG document
>>Oct 05 Accept routing protocol requirements as a WG work item
>>Dec 05 Submit problem statement and architecture document to the IESG
>>for publication as an Informational RFC
>>Mar 06 Submit routing protocol requirements to the IESG for
>>publication as an Informational RFC
>>Mar 06 Choose routing protocol(s) that can meet the requirements.
>>Apr 06 Start work with routing area WG(s) to undertake TRILL extensions.
>>Sep 06 Base protocol specification submitted to the IESG for
>>publication as a Proposed Standard RFC
>>Dec 06 Re-charter or shut down the WG
>>
>>
>>_______________________________________________
>>IETF-Announce mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/ietf-announce
>>
>>
> 
> 

Date: Wed, 15 Jun 2005 15:13:57 -0700
From: Joe Touch <[email-masked]>
To: [email-masked]
Subject: [rbridge] forwarded feedback on TRILL announcement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 7787

Subject:
Re: WG Review: Transparent Interconnection of Lots of Links (trill)
From:
"Adrian Farrel" <[email-masked]>
Date:
Wed, 15 Jun 2005 22:33:24 +0100
To:
<[email-masked]>
CC:
<[email-masked]>

Hi,

I do not oppose the creation of this WG, but I would like to draw to your
attention that CCAMP covers (through GMPLS) the installation of forwarding
state on devices within Ethernet arbitrary networks. This is (of course)
not limited to shortest path, but includes constrained shortest path such
as might be used to achieve traffic engineering within an Ethernet
network. CCAMP currently has a design team looking at the necessary
framework and deployment scenarios with the following charter:

  Charter for the CCAMP Layer 2 Ethernet Design Team

      GMPLS signaling and routing is applicable to Layer 2.
      However, up to now, very little attention has been given to the
      control of Ethernet switches using GMPLS protocols.

      This Design Team is chartered to start the work of applying
      GMPLS to Ethernet devices by developing a framework draft that
      covers possible deployment scenarios, identifies the consequent
      requirements, and highlights possible interactions with other
      SDOs.

      The sole objective of the Design Team is to produce this
      framework draft which should be around 10 pages in length.
      Solutions work is out of scope at this time.

      The draft will be ready for discussion at the Paris IETF.

It is not clear to me whether there is any overlap with TRILL, but there
may be since both WGs are proposing to use IGPs to flood topology
information that pertains to the Ethernet network. I suggest that this
means that CCAMP and TRILL need to work together closely to ensure that
there is no duplication of effort.

Thanks,
Adrian

PS. Lovely acronym, but is "Transparent Interconnection of Lots of Links"
really a good description of what the WG is chartered to do?

- ----- Original Message -----
From: "The IESG" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, June 15, 2005 7:52 PM
Subject: WG Review: Transparent Interconnection of Lots of Links (trill)

>> A new IETF working group has been proposed in the Internet Area. The

IESG has

>> not made any determination as yet. The following draft charter was

submitted,

>> and is provided for informational purposes only. Please send your

comments to

>> the IESG mailing list ([email-masked]) by June 22nd.
>>
>> +++
>>
>> Transparent Interconnection of Lots of Links (trill)
>> =====================================================
>>
>> Current Status: Proposed Working Group
>>
>> Chair(s):
>> TBD
>>
>> Internet Area Director(s):
>> Mark Townsley <[email-masked]>
>> Margaret Wasserman <[email-masked]>
>>
>> Internet Area Advisor:
>> Mark Townsley <[email-masked]>
>>
>> Technical Advisor:
>> Bill Fenner <[email-masked]>
>>
>> Secretary(ies):
>> TBD
>>
>> Mailing Lists:
>> General Discussion: [email-masked]
>> To Subscribe: http://www.postel.org/mailman/listinfo/rbridge
>> Archive: http://www.postel.org/pipermail/rbridge
>>
>> Description of Working Group:
>>
>> The TRILL WG will design a solution for shortest-path frame routing in
>> multi-hop IEEE 802.1 Ethernet networks with arbitrary topologies,
>> using the link-state routing protocol technology.
>>
>> This work will initially be based on draft-perlman-rbridge-03.txt.
>>
>> The design should have the following properties:
>>
>> - Minimal or no configuration required
>> - Load-splitting among multiple paths
>> - Routing loop mitigation (possibly through a TTL field)
>> - Support of multiple points of attachment
>> - Support for broadcast and multicast
>> - No significant service delay after attachment
>> - No less secure than existing bridged solutions
>>
>> Any changes introduced to the Ethernet service model should be
>> analyzed and clearly documented. To ensure compatibility with IEEE
>> VLANs and the Ethernet service model, the WG will request an IEEE
>> liaison relationship with IEEE 802.1.
>>
>> It is not an explicit requirement that the solution should be able to
>> run on existing IP routers or IEEE 802 switches as a software upgrade.
>> However, the working group should take deployment considerations into
>> account, to ensure that the solution can interwork with bridges in a
>> flexible manner (e.g., to allow incremental deployment into LANs that
>> currently use 802.1D bridges).
>>
>> The TRILL working will work with the L2VPN WG and IEEE 802.1 to
>> develop interworking between TRILL and 802.1D bridges at the edge, such
>> that a bridged sub-cloud could be attached to TRILL devices in more than
>> one place for redundancy.
>>
>> The solution must not interfere with the end-to-end transparency of
>> the Internet architecture or with end-to-end congestion control and
>> QOS mechanisms.
>>
>> The WG will work on the following items:
>>
>> (1) Develop a problem statement and architecture document that
>> describes the high-level TRILL architecture, discusses the
>> scalability of that architecture, describe the threat model
>> and security impacts of the TRILL solution, and describes the
>> expected impacts (if any) of the TRILL solution on the Ethernet
>> service model.
>>
>> (2) Define the requirements for a TRILL-capable routing protocol, and
>> select one or more existing routing protocols that could meet
>> those requirements.
>>
>> (3) Work with the appropriate Routing area working group to extend an
>> existing routing protocol to meet the TRILL working group
>> requirements.
>>
>> Note: The TRILL working group is not chartered to develop a new
>> routing protocol or to make substantial modifications to an
>> existing routing protocol. If, during the requirements definition
>> and selection phase, the TRILL working group discovers that no
>> existing routing protocol will meet their needs, we will need to
>> re-assess the TRILL WG charter to determine how/if this work
>> should proceed.
>>
>> (4) Produce a (set of) TRILL specification(s) for standards track
>> publication that defines what information must be carried in an
>> encapsulation header for data packets, and determine how to map
>> that information to various link types (only IEEE 802 links
>> initially)
>>
>> The TRILL working group is chartered to undertake all of the above
>> tasks and may begin work on more than one of these tasks in parallel.
>> However, the problem statement and architecture document should be
>> completed before the details of the base protocol are finalized, while
>> there is still time to consider changes to the architecture without
>> major impacts on established specifications.
>>
>> Goals and Milestones:
>>
>> Aug 05 Accept Problem statement and architecture document as a WG
>> work item
>> Aug 05 Accept base protocol specification as a WG document
>> Oct 05 Accept routing protocol requirements as a WG work item
>> Dec 05 Submit problem statement and architecture document to the IESG
>> for publication as an Informational RFC
>> Mar 06 Submit routing protocol requirements to the IESG for
>> publication as an Informational RFC
>> Mar 06 Choose routing protocol(s) that can meet the requirements.
>> Apr 06 Start work with routing area WG(s) to undertake TRILL extensions.
>> Sep 06 Base protocol specification submitted to the IESG for
>> publication as a Proposed Standard RFC
>> Dec 06 Re-charter or shut down the WG

Date: Wed, 15 Jun 2005 13:12:31 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] forwarded for IETF secretariat
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5253

A new IETF working group has been proposed in the Internet Area. The
IESG has not made any determination as yet. The following draft charter
was submitted, and is provided for informational purposes only. Please
send your comments to the IESG mailing list ([email-masked]) by June 22nd.

+++

Transparent Interconnection of Lots of Links (trill)
=====================================================

Current Status: Proposed Working Group

Chair(s):
TBD

Internet Area Director(s):
Mark Townsley <[email-masked]>
Margaret Wasserman <[email-masked]>

Internet Area Advisor:
Mark Townsley <[email-masked]>

Technical Advisor:
Bill Fenner <[email-masked]>

Secretary(ies):
TBD

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: http://www.postel.org/mailman/listinfo/rbridge
Archive: http://www.postel.org/pipermail/rbridge

Description of Working Group:

The TRILL WG will design a solution for shortest-path frame routing in
multi-hop IEEE 802.1 Ethernet networks with arbitrary topologies,
using the link-state routing protocol technology.

This work will initially be based on draft-perlman-rbridge-03.txt.

The design should have the following properties:

- - Minimal or no configuration required
- - Load-splitting among multiple paths
- - Routing loop mitigation (possibly through a TTL field)
- - Support of multiple points of attachment
- - Support for broadcast and multicast
- - No significant service delay after attachment
- - No less secure than existing bridged solutions

Any changes introduced to the Ethernet service model should be
analyzed and clearly documented. To ensure compatibility with IEEE
VLANs and the Ethernet service model, the WG will request an IEEE
liaison relationship with IEEE 802.1.

It is not an explicit requirement that the solution should be able to
run on existing IP routers or IEEE 802 switches as a software upgrade.
However, the working group should take deployment considerations into
account, to ensure that the solution can interwork with bridges in a
flexible manner (e.g., to allow incremental deployment into LANs that
currently use 802.1D bridges).

The TRILL working will work with the L2VPN WG and IEEE 802.1 to
develop interworking between TRILL and 802.1D bridges at the edge, such
that a bridged sub-cloud could be attached to TRILL devices in more than
one place for redundancy.

The solution must not interfere with the end-to-end transparency of
the Internet architecture or with end-to-end congestion control and
QOS mechanisms.

The WG will work on the following items:

(1) Develop a problem statement and architecture document that
describes the high-level TRILL architecture, discusses the
scalability of that architecture, describe the threat model
and security impacts of the TRILL solution, and describes the
expected impacts (if any) of the TRILL solution on the Ethernet
service model.

(2) Define the requirements for a TRILL-capable routing protocol, and
select one or more existing routing protocols that could meet
those requirements.

(3) Work with the appropriate Routing area working group to extend an
existing routing protocol to meet the TRILL working group
requirements.

Note: The TRILL working group is not chartered to develop a new
routing protocol or to make substantial modifications to an
existing routing protocol. If, during the requirements definition
and selection phase, the TRILL working group discovers that no
existing routing protocol will meet their needs, we will need to
re-assess the TRILL WG charter to determine how/if this work
should proceed.

(4) Produce a (set of) TRILL specification(s) for standards track
publication that defines what information must be carried in an
encapsulation header for data packets, and determine how to map
that information to various link types (only IEEE 802 links
initially)

The TRILL working group is chartered to undertake all of the above
tasks and may begin work on more than one of these tasks in parallel.
However, the problem statement and architecture document should be
completed before the details of the base protocol are finalized, while
there is still time to consider changes to the architecture without
major impacts on established specifications.

Goals and Milestones:

Aug 05 Accept Problem statement and architecture document as a WG
work item
Aug 05 Accept base protocol specification as a WG document
Oct 05 Accept routing protocol requirements as a WG work item
Dec 05 Submit problem statement and architecture document to the IESG
for publication as an Informational RFC
Mar 06 Submit routing protocol requirements to the IESG for
publication as an Informational RFC
Mar 06 Choose routing protocol(s) that can meet the requirements.
Apr 06 Start work with routing area WG(s) to undertake TRILL extensions.
Sep 06 Base protocol specification submitted to the IESG for
publication as a Proposed Standard RFC
Dec 06 Re-charter or shut down the WG