Subject: [rbridge] Conflicts to avoid for BoF/WG?

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Fri Feb 4 12:04:52 2005

Are there other conflicts which we must avoid?

    Erik

This might be approved as a WG before the meeting, but we will schedule
it as a BoF for the time being.

    a. Working Group or BOF full name with acronym in brackets:
	TRansparent Interconnection of Lots of Links (TRILL)
    b. AREA under which Working Group or BOF appears:
	INT
    c. CONFLICTS you wish to avoid, please be as specific as possible:
	multi6, shim6, ipv6, v6ops, is-is, ospf

    d. Expected Attendance (figures from the previous IETF are sent when
       WG/BOF scheduling opens)
	100 (based on IPVLX BoF)

    e. Special requests (i.e. multicast):
    f. Number of slots:
	1

    g. Length of slot:
       	2 1/2 hours

Bof Description: See proposed charter below.
This is a follow-on to the IPVLX BoF in Aug 2004

Bof Chair: Erik Nordmark <[email-masked]>

Mailing list: [email-masked]
Subscribe: http://www.postel.org/mailman/listinfo/rbridge
Web page: http://www.postel.org/rbridge/
	With additional information as well as mailing list archives

Agenda:
-------

  - Welcome and Administrivia			5 minutes	Chair

  - Charter review				10 minutes	Chair

  - Problem statement discussion			30 minutes	Erik Nordmark
	Including the "service" that a cloud of hybrid devices will
	provide, whether it is equivalent to IEEE 802.1D devices, or
	handles IP packets differently
	When is it ok to reorder packets? MTU considerations?

  - Threats and security considerations		10 minutes	???
     	What should the goal be? What can we do better?

  - Requirements on routing protocols		20 minutes	???
     	For zero configuration
     	Carrying MAC addresses
     	Broadcast
     	IS-IS vs. OSPF vs. something else

  - Connecting different L2 types		30 minutes	Radia Perlman?

  - Choices for ARP/ND				10 minutes	???
    	Constraints from security discussion (intentionally duplicate L2
	addresses), mobility, SeND support, etc.

  - Choices for broadcast/multicast		10 minutes	???
	Worth doing any optimizations? Spanning tree between rbridges?

Proposed charter:
-----------------

TRansparent Interconnection of Lots of Links (TRILL)

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
  - possible optimizations for ARP and Neighbor Discovery packets 
(potentially
    avoid flooding all the time)
  - 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)
  - be no less secure than existing bridges (and explore whether the 
protocol
    can make "L2 address theft" harder or easier to detect)

A required piece of the solution is an IP routing protocol which is extended
to carry L2 address reachability, handle broadcast, and is friendly to
zero-configuration. Likely candidate are the link-state routing protocols
since they can easily be extended to provide for broadcast, which is 
believed
to be difficult for distance vector protocols.
This working group will define the requirements on such routing protocol(s),
and select the routing protocol(s) to be used.  The intent is that the 
actual
extensions to the routing protocol(s) be performed in the WGs with 
expertise
in the routing protocol(s).

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.
Whether the same or different address formats are used, there might be a 
need
to handle different MTUs.

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 must support both IPv4 and IPv6

The working group will not work any layer 3 aspects except to provide
  - Possible optimizations for ARP and ND packets (not always
    flooded everywhere)
  - Being able to carry IP broadcast and multicast packets (which might 
just
    fall out from supporting L2 multicast)
  - Defining the L3 operations needed to interconnect different L2 
technologies

The work consists of several, separable pieces:
  - Defining the requirement on the routing protocol(s), and select one or
    more routing protocols. The detailed specification of the extensions to
    a particular 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 trill concept, and other requirements on
    the routing protocols.
  - 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
  - Threat analysis document

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
Dec 05  Threat analysis to IESG for Informational

---

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Fri Feb 4 13:05:12 2005

Is it possible to request that this not be Friday? A lot of people make 
plane reservations
early assuming that they don't want to stay on Friday.

As for the agenda...looks great. I'm happy to lead any of the 
discussions below
if you don't have other volunteers. Though for the one you have me down 
for (mixing
L2 link types) I can talk about some ways of doing it, but I'm still not 
really clear
on why people want this, and what types of links they'd like to mix. Is 
there
someone who would like to talk about the problem statement?

Radia

Erik Nordmark wrote:

> Whether the same or different address formats are used, there might be 
> a need
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://www.postel.org/mailman/listinfo/rbridge

---

From: fltemplin at acm.org (Fred L. Templin)
Date: Fri Feb 4 13:09:25 2005

> Are there other conflicts which we must avoid?

Only that the name 'TRILL' is already taken - by a *birdseed* company!
(See: http://www.trill.com.)

Fred L. Templin
American Kestrel Consulting
[email-masked]
[email-masked]
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Erik Nordmark
Sent: Friday, February 04, 2005 12:04 PM
To: Developing a hybrid router/bridge.
Subject: [rbridge] Conflicts to avoid for BoF/WG?

    Erik

    g. Length of slot:
       	2 1/2 hours

Agenda:
-------

  - Problem statement discussion			30 minutes
Erik Nordmark

  - Connecting different L2 types		30 minutes	Radia
Perlman?

Proposed charter:
-----------------

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.

  - it should be possible to forward packets using pair-wise shortest
paths,
  - the packet header should have a hop count for robustness in the
presence

A required piece of the solution is an IP routing protocol which is
extended to carry L2 address reachability, handle broadcast, and is
friendly to zero-configuration. Likely candidate are the link-state
routing protocols since they can easily be extended to provide for
broadcast, which is 
believed
to be difficult for distance vector protocols.
This working group will define the requirements on such routing
protocol(s), and select the routing protocol(s) to be used.  The intent
is that the 
actual
extensions to the routing protocol(s) be performed in the WGs with 
expertise
in the routing protocol(s).

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. Whether the same or different address formats are used, there
might be a 
need
to handle different MTUs.

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 must support both IPv4 and IPv6

The work consists of several, separable pieces:
  - Defining the requirement on the routing protocol(s), and select one
or
    more routing protocols. The detailed specification of the extensions
to
    a particular 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

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
Dec 05  Threat analysis to IESG for Informational

---

_______________________________________________
rbridge mailing list
[email-masked] http://www.postel.org/mailman/listinfo/rbridge

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Fri Feb 4 13:50:43 2005

> early assuming that they don't want to stay on Friday.

I'll try.

> someone who would like to talk about the problem statement?

I know a problem statement has been discussed in the IPv6 WG as part of 
the ndproxy draft, which has two examples related to home networking:
1. The ISP assigns a /64 prefix to the PPP link to the home, but the
    subscriber wants to use the /64 for the home link as well.
    Thus you have PPP on one side of a device, and an IEEE 802 network on
    the other side, and want to share the same /64 subnet prefix.

2. The home subnet is assigned a /64 subnet prefix, but the user also
    has a WIFI AP, and want to hang another wired link of a WIFI client.
    Today such an IPv4 802.11 client might be a NAT box, so the question
    that's been asked in the IPv6 WG is whether something is needed to
    make this less likely for IPv6. (See figures in the ndproxy draft.)

    In this case, the 802.11 client could just be a vanilla 802.11D
    bridge, but the argument is that it is hard to build such a thing
    using a regular 802.11 client NIC (not possible to be promiscious,
    which is required to be a bridge is the main argument I think)

    In any case, a TRILL based solution wouldn't need to connect
    different L2s address formats in this case, since they are both IEEE
    802 ones.

In the past there has been home networking discussions worrying about 
e.g. Ethernet and Firewire both being used for IP.

Perhaps there is someone working on home networking that can help us 
shine some light on this. If the only argument for different L2 address 
formats is the PPP one (#1 above), it probably doesn't fit in TRILL.

    Erik

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri Feb 4 14:03:25 2005

Radia Perlman wrote:
| Is it possible to request that this not be Friday? A lot of people make
| plane reservations
| early assuming that they don't want to stay on Friday.

I'd second that.

Also, if possible, to avoid BTNS (which may or may not be scheduled ;-),
as well as some related groups:
	l2vpn
	rtgarea
	ipv6*

It's hard to avoid the following but would be useful due to some
significant (IMO) overlap:

	tsvwg
	tcpm
	saag

Joe

---

From: fltemplin at acm.org (Fred L. Templin)
Date: Fri Feb 4 14:13:18 2005

Radia,

I would be happy to volunteer to talk about mixing L2 link types,
but my attendance at IETF-62 is looking doubtful at the moment since
I am currently under a budget crunch and I have been summoned for jury
duty on March 1st. (The first issue has an obvious solution, but the
second is a wait-and-see scenario as to whether I would be picked for
a jury). So, I guess I am volunteering(*) with an asterisk, i.e.,
provided I am somehow able to attend.

Fred L. Templin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: Friday, February 04, 2005 1:03 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Conflicts to avoid for BoF/WG?

really clear

Radia

Erik Nordmark wrote:

> This might be approved as a WG before the meeting, but we will 
> schedule it as a BoF for the time being.
>
> extended
> protocol(s),

> different

> and routers in a way that will co-exist with existing hosts, IP 
> routers and bridges. The design must support both IPv4 and IPv6
>
or

> 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

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Fri Feb 4 15:08:51 2005

> Also, if possible, to avoid BTNS (which may or may not be scheduled ;-),

Is this a prospective BoF? I don't find a WG by that name.

 >    ipv6*

I had ipv6, v6ops, multi6, shim6.
Any other specific WG?

I didn't want to add the mobility WGs that do v6 work since we'd either 
have to meet at 4pm or on the weekend with such a long list of conflicts :-)

   Erik

---

From: alper.yegin at samsung.com (Alper Yegin)
Date: Fri Feb 4 15:10:43 2005

> e.g. Ethernet and Firewire both being used for IP.

I don't have more detailed data points, but this is what I heard earlier
too (I'll see if I can get more concrete data). Besides, how can we
ensure that LANs will stick to a uniform 48-bit address space for the
foreseeable future? I read that IEEE is already discouraging use of
48-bit identifiers in favor of EUI-64. 

I think it is worth investigating the feasibility and cost of inheriting
that aspect of "routers" for this "hybrid". 

Alper

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri Feb 4 15:29:25 2005

> Is this a prospective BoF? I don't find a WG by that name.

The first BTNS happened last IETF; we requested a slot for this one to 
do charter bashing (not yet widely announced, since we didn't get the 
ACK for the slot yet).

> I had ipv6, v6ops, multi6, shim6.

Those were the ones I was thinking of.

> have to meet at 4pm or on the weekend with such a long list of conflicts 

Agreed.
-------------- 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/20050204/b29e5784/signature.bin

---

From: fltemplin at acm.org (Fred L. Templin)
Date: Fri Feb 4 15:56:42 2005

Erik,

> e.g. Ethernet and Firewire both being used for IP.

If we can say that Firewire devices will only occur along the
network edges (rather than somewhere in the middle) and will
always sit behind a router (rather than a bridge) doesn't that
make things more simple and secure? Am I being unrealistic here?

Fred
[email-masked]

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Fri Feb 4 16:18:42 2005

> make things more simple and secure? Am I being unrealistic here?

The issue that folks bring up is that random consumers can be expected 
to know how to configure the IP subnets into a router. Hence the desire 
for something that has the property of a bridge of not needing 
configuration.

    Erik

---

From: fltemplin at acm.org (Fred L. Templin)
Date: Fri Feb 4 23:40:44 2005

Erik,

Understood, but what I meant to ask is whether Firewire devices
will always sit behind a router *interface* for simplicity and
security? The device with the router interface might have many
other interfaces that act as Rbridge or even simple bridge
interfaces, so the device itself would still be a hybrid. The
zeroconf considerations would really be no different than what
we have been discussing for generic RBridges, then - i.e., the
goal is for no manual config needed.

Fred
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Erik Nordmark
Sent: Friday, February 04, 2005 4:18 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Conflicts to avoid for BoF/WG?

Fred L. Templin wrote:

> If we can say that Firewire devices will only occur along the network 
> edges (rather than somewhere in the middle) and will always sit behind

> a router (rather than a bridge) doesn't that make things more simple 
> and secure? Am I being unrealistic here?

    Erik