[802SEC] FW: Internal WG Review: IP Virtual Link Extensions (ipvlx)
A new WG in the IETF is being proposed and people from IEEE 802 may wish
to comment or at least be aware. Please forward to your working group
members if you believe there is appropriate interest.
Paul
-----Original Message-----
From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
Sent: Friday, February 04, 2005 9:07 PM
To: Congdon, Paul T (ProCurve)
Subject: FW: Internal WG Review: IP Virtual Link Extensions (ipvlx)
FYI -
The proposed IPVLX charter has now been sent out for comment.
>From: iesg-secretary@ietf.org
>To: iesg@ietf.org, iab@iab.org, Erik Nordmark <erik.nordmark@sun.com>
>Subject: Internal WG Review: IP Virtual Link Extensions (ipvlx)
>Date: Wed, 02 Feb 2005 11:25:13 -0500
>
>A new IETF working group is being considered in the Internet Area. The
>draft charter for this working group is provided below for your review
>and comment.
>
>The IETF Secretariat
>
>+++
>
>IP Virtual Link Extensions (ipvlx)
>====================================
>
>Last Modified: 2005-2-1
>
>Current Status: Proposed Working Group
>
>Chair(s):
>Erik Nordmark <erik.nordmark@sun.com>
><TBD>
>
>Internet Area Directors:
>Thomas Narten <narten@us.ibm.com>
>Margaret Wasserman <margaret@thngmagic.com>
>
>Internet Area Advisor:
>Margaret Wasserman <margaret@thingmagic.com>
>
>Description of Working Group:
>
>While IEEE 802 bridges are attractive due to not needing explicit
>configuration and allowing hosts to move within the bridged topology,
>they are more limited than IP routers since bridges only support IEEE
>802 technologies, and the most common layer 2 interconnection method
>(dynamically created spanning tree formation using bridges) is not as
>flexible and robust as layer 3 routing.
>
>The WG will design a hybrid solution that combines the simplicity of
>configuration while taking full advantage of complex topologies.
>
>The design should have the following properties:
>- zero configuration of the hybrid devices
>- ability for hosts to move without changing their IP address
>- it should be possible to forward packets using pair-wise shortest
>paths, and exploit the redundant paths through the network for
>increased aggregate bandwidth
>- ARP and Neighbor Discovery packets should be optimized and not
>necessarily be flooded everywhere
>- support Secure Neighbor Discovery
>- the packet header should have a hop count for robustness in the
>presence of temporary routing loops
>- nodes should be able to have multiple attachments to the network
>- no delay when a new node is attached to the network
>- multicast should work (and after a re-charter it might make sense to
>look at optimizations for IP multicast)
>
>The working group will look into solutions that can interconnect
>different layer 2 technologies, and also look at providing support for
>non-IP protocols, even though one can not combine those two features
>together; the interconnection of different layer 2 technologies (with
>different layer 2 address formats) will most likely only work for the
>IP family of protocols.
>
>The WG will design a protocol that combines the benefits of bridges and
>routers in a way that will co-exist with existing hosts, IP routers and
>bridges. The design should support both IPv4 and IPv6
>
>The working group will not work any layer 3 aspects except to provide
>- Optimizations so that ARP and ND packets are not always flooded
>everywhere
>- Being able to carry IP multicast packets using flooding (which will
>presumably fall out by being able to flood L2 multicast packets, so
>there might not be any specific work needed here).
>- Defining the L3 operations needed to interconnect different L2
>technologies
>
>The work consists of several, separable pieces:
>- Defining what information should be carried in routing protocols in
>order to support this concept. The encoding of this information within
>the routing protocol will be left as an action item for the specific
>routing protocol WG.
>- Defining what information must be carried in an encapsulation header
>for data packets, and how to map that information to various link types
>(e.g., IEEE LAN, Fibrechannel, MPLS)
>- Defining how address resolution (ARP and Neighbor Discovery) is
>performed, taking into account the desire to be compatible with Secure
>Neighbor Discovery.
>- Defining how the solution extends to the case when multiple layer 2
>technologies, that have different address format/length, are
>interconnected.
>
>Deliverables
>- A short draft on the problem statement and goals
>- A document defining what information needs to be carried in routing
>protocols to support the rbridge concept.
>- Encapsulation draft specifying what needs to be carried in general
>and the specific format to use on IEEE LANs
>- ARP and ND draft
>- Draft on interconnecting different types of layer 2 technologies
>
>Goals and Milestones
>
>Jun 05 Problem statement and Goals submitted to IESG for Informational
>Sep 05 Routing protocol support requirements to IESG for Informational
>Dec 05 Encapsulation document to IESG for Proposed Standard Sep 05 ARP
>& ND to IESG for Proposed Standard Mar 06 Interconnecting Layer 2
>Technologies document to IESG for Proposed Standard
>
>
>
----------
This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.