Subject: [rbridge] status of IPVLX at IETF

From: touch at ISI.EDU (Joe Touch)
Date: Thu Nov 11 14:04:22 2004

Hi, all,

Various questions have been raised, both on and off this list, why there 
wasn't an IPVLX BOF or WG at this IETF (61).

There is current discussion with the IESG about how best to proceed, 
given the substantial interest An additional BOF was not deemed 
necessary to resolve the currently pending request, and so was not 
requested for this IETF. We hope to have further information soon, and 
will post when it is available.

Joe (& Radia)
-------------- 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/20041111/9ce5348e/signature.bin

---

From: osprey67 at yahoo.com (Fred Templin)
Date: Mon Nov 15 15:59:05 2004

Joe Touch <[email-masked]> wrote:
Hi, all,

Joe (& Radia)

Joe et al,
 
Having asked about this on the list, I would like to provide further clarification.
The sole intention of my message to the list on 11/10/04 was to seek a forum
to demonstrate how [draft-templin-ipvlx] (http://ipvlx.com/IPVLX.txt) supports
the BOF/WG charter (http://www.postel.org/rbridge/ipvlx-bof-prob-stmt.txt).
Since my request may have been poorly articulated and/or too late in the
game for IETF61, I would like to use this message thread as an alternate
forum. Please see below and comment:
 
Fred L. Templin
[email-masked]

> IETF IP Virtual Link eXtension (ipvlx) BOF
> 
> Date:		Monday, August 2, 13:00-15:00
> BOF Chair: 	Erik Nordmark <[email-masked]>
> 
> Organizations with large local networks may wish to administer
> them without the complications of internal IP address assignments.
> Layer 2 addresses provide the unique names, but the most common 
> layer 2 interconnection method (dynamically created spanning tree
> formation using bridges) is not as flexible as layer 3 routing.
 
[draft-templin-ipvlx] proposes mechanisms and operational scenarios for
organizations with large local networks (i.e., "enterprise" networks) using IPv4
as a Layer 2 protocol for any Layer 3 protocol, including IPv6, IPv4 itself, etc.
Layer 2 addresses (i.e., IPv4 addresses) may be automatically assigned and
provide unique L2 names within a subset of the enterprise known as a "site".
 
> The BoF will explore hybrid solutions that retain the simplicity of 
> administration while taking full advantage of complex topologies.

Sites consist of  "IPvLX gateways" and their "associated hosts". IPvLX
gateways are "rbridges" that also determine the Layer 2 addressing plan for
associated hosts in the site in the same fashion as an IPv4 NAT. Associated
hosts may themselves be IPvLX gateways for their own associated hosts in
recursively nested child sites, allowing for arbitrarily-complex enterprise
topologies.     

> Bridges with spanning tree algorithms have obvious disadvantages: routing
> is confined to a spanning tree (precluding pair-wise shortest paths),
> ARP and Neighbor Discovery packets must be carried across all the links,
> the header on which the spanning tree forwards has no hop count,
> spanning tree forwarding in the presence of temporary loops spawns
> exponential copies of packets, nodes can have only a single point of
> attachment, the spanning tree, in order to avoid temporary loops,
> is slow to start forwarding on new ports, and it is not possible to take
> advantage of the rich physical topology for capacity since the packet flows
> are restricted to following the spanning tree.
 
The IPv4 destination address in what [draft-templin-ipvlx] calls an "IPvLX packet"
identifies a next-hop IPvLX gateway on the path to the final destination rather than
the final destination itself. Each IPvLX packet includes "IPvLX flow" information to
identify virtual circuit soft state for next-hop determination in intermediate IPvLX
gateways (Intermediate Systems?) and a Layer 2 hop count (i.e., the IPv4 ttl) to
avoid exponential traffic in the presence of temporary loops. 

> Routers avoid those disadvantages but have their own problems:
> IP addresses are link specific so a host that moves must change 
> its IP address, the routers must be configured with unique link prefixes
> for each of the attached links, and the block of IP address space can not be
> fully utilized because it must be partitioned across the different links.
 
In [draft-templin-ipvlx], only last-hop IPvLX gateways (End Systems?) need
assign unique Layer 3 link prefixes, since intermediate IPvLX gateways deal
only with virtual circuit soft state and Layer 2 addresses. As such, last-hop
IPvLX gateways that move can retain their Layer 3 link prefixes as long as
they inform their home enterprise when "roaming" to a different enterprise.   
 
> The BoF will explore combining 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.
 
[draft-templin-ipvlx] combines the benefits of bridges and routers and supports
incremental deployment and coexsitence with the existing IPv4 Internet. The
design supports both IPv4 and IPv6 via virtual links extended between last
hop IPvLX gateways accross arbitrarily complex paths. (These virtual links
may also be considered as Virtual Private Networks.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/rbridge/attachments/20041115/00519386/attachment.html

Date: Mon, 15 Nov 2004 15:58:09 -0800 (PST)
From: Fred Templin <[email-masked]>
Subject: Re: [rbridge] status of IPVLX at IETF
To: [email-masked]
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 11294

--0-1237915013-1100563089=:9079
Content-Type: text/plain; charset=us-ascii

Joe Touch <[email-masked]> wrote:
Hi, all,

Joe (& Radia)

Joe et al,
 
Having asked about this on the list, I would like to provide further clarification.
The sole intention of my message to the list on 11/10/04 was to seek a forum
to demonstrate how [draft-templin-ipvlx] (http://ipvlx.com/IPVLX.txt) supports
the BOF/WG charter (http://www.postel.org/rbridge/ipvlx-bof-prob-stmt.txt).
Since my request may have been poorly articulated and/or too late in the
game for IETF61, I would like to use this message thread as an alternate
forum. Please see below and comment:
 
Fred L. Templin
[email-masked]

> IETF IP Virtual Link eXtension (ipvlx) BOF
> 
> Date:		Monday, August 2, 13:00-15:00
> BOF Chair: 	Erik Nordmark <[email-masked]>
> 
> Organizations with large local networks may wish to administer
> them without the complications of internal IP address assignments.
> Layer 2 addresses provide the unique names, but the most common 
> layer 2 interconnection method (dynamically created spanning tree
> formation using bridges) is not as flexible as layer 3 routing.
 
[draft-templin-ipvlx] proposes mechanisms and operational scenarios for
organizations with large local networks (i.e., "enterprise" networks) using IPv4
as a Layer 2 protocol for any Layer 3 protocol, including IPv6, IPv4 itself, etc.
Layer 2 addresses (i.e., IPv4 addresses) may be automatically assigned and
provide unique L2 names within a subset of the enterprise known as a "site".
 
> The BoF will explore hybrid solutions that retain the simplicity of 
> administration while taking full advantage of complex topologies.

Sites consist of  "IPvLX gateways" and their "associated hosts". IPvLX
gateways are "rbridges" that also determine the Layer 2 addressing plan for
associated hosts in the site in the same fashion as an IPv4 NAT. Associated
hosts may themselves be IPvLX gateways for their own associated hosts in
recursively nested child sites, allowing for arbitrarily-complex enterprise
topologies.     

> Bridges with spanning tree algorithms have obvious disadvantages: routing
> is confined to a spanning tree (precluding pair-wise shortest paths),
> ARP and Neighbor Discovery packets must be carried across all the links,
> the header on which the spanning tree forwards has no hop count,
> spanning tree forwarding in the presence of temporary loops spawns
> exponential copies of packets, nodes can have only a single point of
> attachment, the spanning tree, in order to avoid temporary loops,
> is slow to start forwarding on new ports, and it is not possible to take
> advantage of the rich physical topology for capacity since the packet flows
> are restricted to following the spanning tree.
 
The IPv4 destination address in what [draft-templin-ipvlx] calls an "IPvLX packet"
identifies a next-hop IPvLX gateway on the path to the final destination rather than
the final destination itself. Each IPvLX packet includes "IPvLX flow" information to
identify virtual circuit soft state for next-hop determination in intermediate IPvLX
gateways (Intermediate Systems?) and a Layer 2 hop count (i.e., the IPv4 ttl) to
avoid exponential traffic in the presence of temporary loops. 

> Routers avoid those disadvantages but have their own problems:
> IP addresses are link specific so a host that moves must change 
> its IP address, the routers must be configured with unique link prefixes
> for each of the attached links, and the block of IP address space can not be
> fully utilized because it must be partitioned across the different links.
 
In [draft-templin-ipvlx], only last-hop IPvLX gateways (End Systems?) need
assign unique Layer 3 link prefixes, since intermediate IPvLX gateways deal
only with virtual circuit soft state and Layer 2 addresses. As such, last-hop
IPvLX gateways that move can retain their Layer 3 link prefixes as long as
they inform their home enterprise when "roaming" to a different enterprise.   
 
> The BoF will explore combining 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.
 
[draft-templin-ipvlx] combines the benefits of bridges and routers and supports
incremental deployment and coexsitence with the existing IPv4 Internet. The
design supports both IPv4 and IPv6 via virtual links extended between last
hop IPvLX gateways accross arbitrarily complex paths. (These virtual links
may also be considered as Virtual Private Networks.)

--0-1237915013-1100563089=:9079
Content-Type: text/html; charset=us-ascii

<DIV><STRONG><EM>Joe Touch &lt;[email-masked]&gt;</EM></STRONG> wrote:
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<P>Hi, all,<BR><BR>Various questions have been raised, both on and off this list, why there <BR>wasn't an IPVLX BOF or WG at this IETF (61).<BR><BR>There is current discussion with the IESG about how best to proceed, <BR>given the substantial interest An additional BOF was not deemed <BR>necessary to resolve the currently pending request, and so was not <BR>requested for this IETF. We hope to have further information soon, and <BR>will post when it is available.<BR><BR>Joe (&amp; Radia)</P></BLOCKQUOTE></DIV>
<DIV>&nbsp;</DIV>
<DIV>Joe et al,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Having asked about this on the list, I would like to provide further clarification.</DIV>
<DIV>The sole intention of my&nbsp;message to the list&nbsp;on 11/10/04 was to seek a forum</DIV>
<DIV>to demonstrate how [draft-templin-ipvlx] (<A href="http://ipvlx.com/IPVLX.txt">http://ipvlx.com/IPVLX.txt</A>) supports</DIV>
<DIV>the BOF/WG charter (<A href="http://www.postel.org/rbridge/ipvlx-bof-prob-stmt.txt">http://www.postel.org/rbridge/ipvlx-bof-prob-stmt.txt</A>).</DIV>
<DIV>Since my&nbsp;request may have been poorly articulated and/or too late in the</DIV>
<DIV>game for IETF61, I would like to use this message thread as an alternate</DIV>
<DIV>forum. Please see below and comment:</DIV>
<DIV>&nbsp;</DIV>
<DIV>Fred L. Templin</DIV>
<DIV><A href="mailto:[email-masked]">[email-masked]</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;</DIV>
<DIV>&gt; IETF IP Virtual Link eXtension (ipvlx) BOF<BR>&gt; <BR>&gt; Date:		Monday, August 2, 13:00-15:00<BR>&gt; BOF Chair: 	Erik Nordmark &lt;[email-masked]&gt;<BR>&gt; <BR>&gt; Organizations with large local networks may wish to administer<BR>&gt; them without the complications of internal IP address assignments.<BR>&gt; Layer 2 addresses provide the unique names, but the most common <BR>&gt; layer 2 interconnection method (dynamically created spanning tree<BR>&gt; formation using bridges) is not as flexible as layer 3 routing.</DIV>
<DIV>&nbsp;</DIV>
<DIV>[draft-templin-ipvlx] proposes mechanisms and operational scenarios for</DIV>
<DIV>organizations with large local networks (i.e., "enterprise" networks) using IPv4</DIV>
<DIV>as a Layer 2 protocol for any Layer 3 protocol, including&nbsp;IPv6, IPv4 itself, etc.</DIV>
<DIV>Layer 2 addresses (i.e., IPv4 addresses) may be automatically assigned and</DIV>
<DIV>provide unique L2 names within a subset of&nbsp;the enterprise known as a "site".</DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt; The BoF will explore hybrid solutions that retain the simplicity of <BR>&gt; administration while taking full advantage of complex topologies.<BR></DIV>
<DIV>Sites&nbsp;consist of&nbsp; "IPvLX gateways" and&nbsp;their "associated hosts". IPvLX</DIV>
<DIV>gateways are "rbridges" that also determine the Layer 2 addressing plan for</DIV>
<DIV>associated hosts in the site in the same fashion as an IPv4 NAT. Associated</DIV>
<DIV>hosts may themselves be IPvLX gateways for their own associated hosts in</DIV>
<DIV>recursively nested child sites, allowing for arbitrarily-complex enterprise</DIV>
<DIV>topologies.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR><BR>&gt; Bridges with spanning tree algorithms have obvious disadvantages: routing<BR>&gt; is confined to a spanning tree (precluding pair-wise shortest paths),<BR>&gt; ARP and Neighbor Discovery packets must be carried across all the links,<BR>&gt; the header on which the spanning tree forwards has no hop count,<BR>&gt; spanning tree forwarding in the presence of temporary loops spawns<BR>&gt; exponential copies of packets, nodes can have only a single point of<BR>&gt; attachment, the spanning tree, in order to avoid temporary loops,<BR>&gt; is slow to start forwarding on new ports, and it is not possible to take<BR>&gt; advantage of the rich physical topology for capacity since the packet flows<BR>&gt; are restricted to following the spanning tree.</DIV>
<DIV>&nbsp;</DIV>
<DIV>The IPv4 destination address in what [draft-templin-ipvlx] calls an "IPvLX packet"</DIV>
<DIV>identifies&nbsp;a next-hop IPvLX gateway on the path to the final destination rather than</DIV>
<DIV>the final destination itself. Each IPvLX packet includes "IPvLX flow" information to</DIV>
<DIV>identify virtual circuit soft state for next-hop determination in intermediate IPvLX</DIV>
<DIV>gateways (Intermediate Systems?) and a Layer 2 hop count (i.e., the IPv4 ttl) to</DIV>
<DIV>avoid exponential traffic in the presence of temporary loops.&nbsp;<BR><BR>&gt; Routers avoid those disadvantages but have their own problems:<BR>&gt; IP addresses are link specific so a host that moves must change <BR>&gt; its IP address, the routers must be configured with unique link prefixes<BR>&gt; for each of the attached links, and the block of IP address space can not be<BR>&gt; fully utilized because it must be partitioned across the different links.</DIV>
<DIV>&nbsp;</DIV>
<DIV>In [draft-templin-ipvlx], only last-hop IPvLX gateways (End Systems?) need</DIV>
<DIV>assign unique Layer 3 link prefixes, since intermediate IPvLX gateways deal</DIV>
<DIV>only with virtual&nbsp;circuit&nbsp;soft state&nbsp;and Layer 2 addresses. As such, last-hop</DIV>
<DIV>IPvLX gateways that move can retain their Layer 3 link prefixes as long as</DIV>
<DIV>they inform their home enterprise when "roaming" to a different enterprise.&nbsp;&nbsp;&nbsp;<BR>&nbsp;<BR>&gt; The BoF will explore combining benefits of bridges and routers in a way <BR>&gt; that will co-exist with existing hosts, IP routers and bridges.&nbsp; The <BR>&gt; design should support both IPv4 and IPv6.</DIV>
<DIV>&nbsp;</DIV>
<DIV>[draft-templin-ipvlx] combines the benefits of bridges and routers and supports</DIV>
<DIV>incremental deployment and coexsitence with the existing IPv4 Internet. The</DIV>
<DIV>design supports both IPv4 and IPv6 via virtual links extended between last</DIV>
<DIV>hop IPvLX gateways accross arbitrarily complex paths. (These virtual links</DIV>
<DIV>may also be&nbsp;considered as Virtual Private Networks.)</DIV>
--0-1237915013-1100563089=:9079--

Date: Thu, 11 Nov 2004 14:03:59 -0800
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] status of IPVLX at IETF
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1159

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

Hi, all,

Joe (& Radia)

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

--------------enig66D0758B2BD1BD10C2DB75AC--

To: Fred Templin <[email-masked]>
Date: Wed, 10 Nov 2004 08:55:22 -0500
From: Thomas Narten <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [rbridge] Re: IPvLX BOF request for IETF61?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 49

No BOF was requested, none is scheduled.

Thomas

Date: Wed, 10 Nov 2004 05:54:50 -0800 (PST)
From: Fred Templin <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: [rbridge] IPvLX BOF request for IETF61?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3791

--0-289757466-1100094890=:95075
Content-Type: text/plain; charset=us-ascii

I have not been able to find an IPvLX BOF on the IETF61 meeting agenda;
have I missed it somehow? In case an IPvLX BOF slot has not already
been requested for IETF61, I would like to make the following request:
 
Sincerely,
 
Fred L. Templin
[email-masked]

IPvLX BOF Request for IETF61:
************************************
    a. Working Group or BOF full name with acronym in brackets:

IP with virtual Link eXtension [IPvLX]

    b. AREA under which Working Group or BOF appears:

Internet

    c. CONFLICTS you wish to avoid, please be as specific as possible:

IPsec, IPv6, Multi6, v6ops, is-is, MIPv6, Routing Area WG

    d. Expected Attendance (figures from the previous IETF are sent when
       WG/BOF scheduling opens)
    e. Special requests (i.e. multicast):
    f. Number of slots:

one

    g. Length of slot:

two hours

       - 1 hour
       - 2 hours
       - 2 1/2 hours

Proposed BoF meeting chair: Fred L. Templin

Web page (which has a reference to the mailing list, archives, papers
and presentations with proposed solutions):

 http://www.ipvlx.org
 
Proposed BOF agenda:
 
Present and discuss the following:
    http://www.ietf.org/internet-drafts/draft-templin-ipvlx-01.txt
    http://www.ietf.org/internet-drafts/draft-templin-ipvlx-errata-04.txt
    Recent updates to the above found at: http://www.ipvlx.org

--0-289757466-1100094890=:95075
Content-Type: text/html; charset=us-ascii

<DIV>I have not been able to find an IPvLX BOF on the IETF61 meeting agenda;</DIV>
<DIV>have I missed it somehow? In case an IPvLX BOF slot has not already</DIV>
<DIV>been requested for IETF61, I would like to&nbsp;make the following request:</DIV>
<DIV>&nbsp;</DIV>
<DIV>Sincerely,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Fred L. Templin</DIV>
<DIV><A href="mailto:[email-masked]">[email-masked]</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>IPvLX BOF Request for IETF61:</DIV>
<DIV>************************************</DIV>
<DIV>&nbsp;&nbsp;&nbsp; a. Working Group or BOF full name with acronym in brackets:<BR><BR>IP&nbsp;with virtual Link&nbsp;eXtension&nbsp;[IPvLX]<BR><BR>&nbsp;&nbsp;&nbsp; b. AREA under which Working Group or BOF appears:<BR><BR>Internet<BR><BR>&nbsp;&nbsp;&nbsp; c. CONFLICTS you wish to avoid, please be as specific as possible:<BR><BR>IPsec, IPv6, Multi6, v6ops, is-is, MIPv6, Routing Area WG<BR><BR>&nbsp;&nbsp;&nbsp; d. Expected Attendance (figures from the previous IETF are sent when<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; WG/BOF scheduling opens)<BR>&nbsp;&nbsp;&nbsp; e. Special requests (i.e. multicast):<BR>&nbsp;&nbsp;&nbsp; f. Number of slots:<BR><BR>one<BR><BR>&nbsp;&nbsp;&nbsp; g. Length of slot:<BR><BR>two hours<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - 1 hour<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - 2 hours<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - 2 1/2 hours<BR><BR>Proposed BoF meeting chair: Fred L. Templin<BR><BR>Web page (which has a reference to the mailing list,
 archives, papers<BR>and presentations with proposed solutions):<BR><BR>&nbsp;<A href="http://www.ipvlx.org">http://www.ipvlx.org</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>Proposed BOF agenda:</DIV>
<DIV>&nbsp;</DIV>
<DIV>Present and discuss the following:</DIV>
<DIV>&nbsp;&nbsp;&nbsp; <A href="http://www.ietf.org/internet-drafts/draft-templin-ipvlx-01.txt">http://www.ietf.org/internet-drafts/draft-templin-ipvlx-01.txt</A></DIV>
<DIV>&nbsp;&nbsp;&nbsp; <A href="http://www.ietf.org/internet-drafts/draft-templin-ipvlx-errata-04.txt">http://www.ietf.org/internet-drafts/draft-templin-ipvlx-errata-04.txt</A></DIV>
<DIV>&nbsp;&nbsp;&nbsp; Recent updates to the above found at: <A href="http://www.ipvlx.org">http://www.ipvlx.org</A></DIV>
--0-289757466-1100094890=:95075--