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

From: townsley at cisco.com (W. Mark Townsley)
Date: Thu, 16 Jun 2005 17:07:04 -0400

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" <iesg-secretary at ietf.org>
> To: <IETF-Announce at ietf.org>
> Cc: <rbridge at postel.org>
> 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 (iesg at ietf.org) by June 22nd.
>>
>>+++
>>
>>Transparent Interconnection of Lots of Links (trill)
>>=====================================================
>>
>>Current Status: Proposed Working Group
>>
>>Chair(s):
>>TBD
>>
>>Internet Area Director(s):
>>Mark Townsley <townsley at cisco.com>
>>Margaret Wasserman <margaret at thingmagic.com>
>>
>>Internet Area Advisor:
>>Mark Townsley <townsley at cisco.com>
>>
>>Technical Advisor:
>>Bill Fenner <fenner at research.att.com>
>>
>>Secretary(ies):
>>TBD
>>
>>Mailing Lists:
>>General Discussion: rbridge at postel.org
>>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
>>IETF-Announce at ietf.org
>>https://www1.ietf.org/mailman/listinfo/ietf-announce
>>
>>
> 
>

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 16 Jun 2005 14:49:39 -0700

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

From:
"Adrian Farrel" <adrian at olddog.co.uk>
Date:
Thu, 16 Jun 2005 22:26:22 +0100
To:
"W. Mark Townsley" <townsley at cisco.com>, "Margaret Wasserman"
<margaret at thingmagic.com>
CC:
<iesg at ietf.org>, <rbridge at postel.org>, "IAB" <iab at ietf.org>, "Kireeti
Kompella" <kireeti at juniper.net>, "dimitri papadimitriou"
<dpapadimitriou at psg.com>

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

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

>> participating in ccamp and trill to do the right thing.

Yup. More drafts to read  ;-)

Thanks,
Adrian

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

>>> > It is not clear to me whether there is any overlap with TRILL, but

there

>>> > means that CCAMP and TRILL need to work together closely to ensure

that

>>> > PS. Lovely acronym, but is "Transparent Interconnection of Lots of

Links"

>>> > Subject: WG Review: Transparent Interconnection of Lots of Links

(trill)

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

>>>> >>Apr 06 Start work with routing area WG(s) to undertake TRILL

extensions.

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

---

From: townsley at cisco.com (W. Mark Townsley)
Date: Fri, 17 Jun 2005 03:02:15 -0400

> 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

---

From: townsley at cisco.com (W. Mark Townsley)
Date: Fri, 17 Jun 2005 09:24:31 -0400

Adrian Farrel wrote:

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

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Fri, 17 Jun 2005 08:53:40 -0700

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:

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

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 17 Jun 2005 09:16:13 -0700

> in place to avoid stepping on one another where it hurts.

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

---

From: zinin at psg.com (Alex Zinin)
Date: Fri, 17 Jun 2005 11:23:49 -0700

Joe,

> or need to differentiate if that's the case.

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

Thanks.
Alex

---

From: margaret at thingmagic.com (Margaret Wasserman)
Date: Thu, 23 Jun 2005 08:19:31 -0400

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:
>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
>
>
>>  ----- Original Message ----- From: "The IESG" <iesg-secretary at ietf.org>