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

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

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