[rbridge] Initial cut at BoF request

[Fred Templin]

Radia Perlman wrote:

> I like vlx. Though perhaps it's not clear what
> a "virtual link" is. So perhaps "extended IP Subnet",
> which might have a pronouncable acronym of EXIPS
> (EXtended IP Subnets)


Would be better than "IP Subnet Extensions", which
would have an unfortunate acronym and pronounciation.

Fred
ftemplin at iprg.nokia.com

> Radia
>
>
> Fred Templin wrote:
>
>> Hello Erik,
>>
>> As to names for the prospective WG, how about:
>>
>>  Virtual Link eXtension (vlx)
>>
>> or, if the above sounds too layer-2 centric:
>>
>>  IP Virtual Link eXtension (ipvlx)
>>
>> Fred
>> ftemplin at iprg.nokia.com
>>
>>
>> Erik Nordmark wrote:
>>
>>> We needed to request a BoF fairly quickly to make sure the IESG has 
>>> time
>>> to review it, so I've submitted a draft BoF request (see below).
>>>
>>> I expect the details to change, especially the name :-)
>>>
>>> Comments on the problem statement and suggestions for a better name
>>> are especially welcome.
>>>
>>> The authors of the rbridge internet-draft asked me if I would chair the
>>> BoF which is fine with me. This does not mean I would necessarily be a
>>> WG chair if a WG is formed as a result of the BoF.
>>>
>>>   Erik
>>>
>>>
>>>  
>>>
>>>> ----- Begin Included Message -----<
>>>>   
>>>
>>>
>>>
>>> Date: Wed, 12 May 2004 15:26:19 -0700 (PDT)
>>> From: "Erik Nordmark" <Erik.Nordmark at sun.com>
>>> Subject: BOF request: ISITFUN
>>> To: agenda at ietf.org, margaret at thingmagic.com, narten at us.ibm.com
>>> Cc: erik.nordmark at sun.com, Radia.Perlman at sun.com
>>>
>>>    a. Working Group or BOF full name with acronym in brackets:
>>>
>>> IP Subnets In Topologies which are Flexible, Universal, and Nice 
>>> [ISITFUN]
>>>
>>> Note: we will almost certainly come up with a better name than this
>>>
>>>    b. AREA under which Working Group or BOF appears:
>>>
>>> Internet
>>>
>>>    c. CONFLICTS you wish to avoid, please be as specific as possible:
>>>
>>> VRRP, routing area meeting, SAAG, IPsec, IPv6, Multi6, v6ops
>>>
>>>    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: Erik Nordmark
>>>
>>> Web page (which has a reference to the mailing list, archives, papers
>>> and presentations with proposed solutions):
>>>
>>>     http://www.postel.org/rbridge/
>>>
>>> Problem statement:
>>>   It is desirable for an organization to have a fairly large campus
>>> with a single IP address prefix, a rich physical topology,
>>> where the network elements do not need to be configured,
>>> where endnodes can move around without changing their IP addresses,
>>> and where ARP and Neighbor Discovery traffic can be confined.
>>>
>>> This functionality is often provided by bridges. However, bridges 
>>> have 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.
>>>
>>> Routers on the other hand avoid those disadvatages but have their own
>>> disadvantages: 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.
>>>
>>> The BoF will explore combining the benefits of bridges and routers 
>>> without
>>> requiring any changes on any of the hosts, IP routers, or bridges.
>>> The design should support both IPv4 and IPv6.
>>>
>>>
>>>
>>>  
>>>
>>>> ----- End Included Message -----<
>>>>   
>>>
>>>
>>>
>>> _______________________________________________
>>> rbridge mailing list
>>> rbridge at postel.org
>>> http://www.postel.org/mailman/listinfo/rbridge
>>>  
>>>
>>
>>
>> _______________________________________________
>> rbridge mailing list
>> rbridge at postel.org
>> http://www.postel.org/mailman/listinfo/rbridge
>
>
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge