Subject: [rbridge] Consensus Check: Point to Point links

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Tue, 2 Oct 2007 23:26:38 -0400

This is a check via the mailing list to confirm or refute an apparent
consensus from the minutes of the Chicago meeting for a change from
protocol draft -05:

   If it is known that a link is a point to point link between two
   RBridges, then the outer header, if it is an Ethernet header, can
   have any source and/or destination addresses, those addresses will
   be ignored on receipt, and the outer VLAN tag can be omitted.

If no particular controversy arises over this in the next two weeks, we
will declare it to be the working group consensus.

Thanks,
Donald & Erik

---

From: eric.gray at ericsson.com (Eric Gray)
Date: Wed, 3 Oct 2007 10:10:51 -0500

Donald,

	Given that it is not crystal clear what you mean by 
"point to point link", I am not sure I agree with this, at
least as you have worded it here.

	If you mean that the link is a full-duplex Ethernet
link and the two end-points have some definitive mechansim
for determining that they are the only entities using the
link between them, there may be issues with doing this.

	For example, if the link is technically an Ethernet 
link, then it is not unlikely that one or the other devices 
may have multiple roles - i.e. - it may be both an RBridge 
for some frames and either a regular bridge or end station
(for example, a router) for others.  It's arguable that, in
this case, the multi-role device is two (or more) separate
entities - thus invalidating a "point to point" definition
for this case (though only two distinct physical devices
are connected via this link).

	Without a clear agreement between involved entities,
this sort of "short-cut" addressing is likely to result in
higher-level (slow path) processing of many (if not all) 
of the frames transiting the link for some implementations.
Moreover, without an unambiguous determination of exactly
when this would apply, it will not be unambiguously clear
when a receiving implementation would have to switch to a
"promiscuous listening" mode.

	I believe omission of the outer VLAN tag suffers from
the same ambiguity.  For instance, it is possible for two
devices to have a "point to point" relationship within a 
VLAN context that would nto be the case without the VLAN
context.

	Hence it appears we would have to be explicit in what
we mean by "point to point" link and how we expect that the
entities (RBridges) involved would be able to disambiguate
this p2p status for any given link.

	If we are saying that two devices - using some means 
out of scope for our specification - are somehow aware of an 
unambiguous point-to-point relationship between them and can
therefore use any MAC DA on transmission, and ignore it on
receipt, we could make the same argument for virtually any 
encapsulation choice we might prefer.  But, it would be as
valid to observe that we don't need to specify what is - in
essence - an out-of-context (mis)behavior between consenting 
implementations...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Tuesday, October 02, 2007 11:27 PM
> To: Rbridge at postel.org
> Subject: [rbridge] Consensus Check: Point to Point links
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Wed, 3 Oct 2007 09:41:13 -0700

I'm OK with this as long as the omission of the
outer VLAN tag is a MAY rather than a MUST.

Anoop

> Sent: Tuesday, October 02, 2007 8:27 PM
> This is a check via the mailing list to confirm or refute an 
> apparent consensus from the minutes of the Chicago meeting 
> for a change from protocol draft -05:
> 
> If no particular controversy arises over this in the next two 
> weeks, we will declare it to be the working group consensus.
> 
> Thanks,
> Donald & Erik
>

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 03 Oct 2007 10:16:28 -0700

Donald, et al.,

I concur with Eric. My concern is why we are defining behavior specific
to pt-pt links for rbridges when they are not similarly defined for
general 802.11 networks.

If there is such a definition, we should point to it, but we should not
create our own. There's no unique need.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20071003/35eb9fd9/signature.bin

---

From: Caitlin.Bestler at neterion.com (Caitlin Bestler)
Date: Wed, 3 Oct 2007 14:17:42 -0400

> create our own. There's no unique need.

I can imagine several scenarios where there is a truly safe
point-to-point
link between two RBridges, and it is indeed safe for them to use a
custom
tunneling between them.

What I don't see is why they need the specification to give them
permission.

If that link is *truly* and securely point-to-point they could just as
easily
declare themselves to be a single RBridge and said link to be a
"inter-processor
bus". When an RBridge is implemented on multiple processors the IETF
does NOT
specify the bus that connects them.

So basically, whenever this sort of optimized encapsulation is valid
there is
no need to explicitly state so. If there is a need for the alternate
encapsulation
to be officially blessed then it probably means that it isn't safe to do
it.

If *nobody* else can see the optimized frames then who is there to
complain
that they are non-compliant?

---

From: eric.gray at ericsson.com (Eric Gray)
Date: Wed, 3 Oct 2007 13:22:08 -0500

Caitlin,

	Please see one comment below...

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> From: Caitlin Bestler [mailto:Caitlin.Bestler at neterion.com] 
> Sent: Wednesday, October 03, 2007 2:18 PM
> To: Joe Touch; Eric Gray
> Cc: Rbridge at postel.org
> Subject: RE: [rbridge] Consensus Check: Point to Point links
> Importance: High
> 
> 
> Joe Touch wrote:
> 

Hence the reference to "consenting implementations" in my earlier
mail.

I get the sense that you're not disagreeing with either Joe or 
myself.

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Wed, 3 Oct 2007 14:24:26 -0400

That's reasonable. "can be omitted" implies MAY to me.

Donald

-----Original Message-----
From: Anoop Ghanwani [mailto:anoop at brocade.com] 
Sent: Wednesday, October 03, 2007 12:41 PM
To: Eastlake III Donald-LDE008; Rbridge at postel.org
Subject: RE: [rbridge] Consensus Check: Point to Point links

Anoop

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Wed, 3 Oct 2007 14:24:58 -0400

Hi Eric,

I believe the generally understood meaning of point-to-point is a link
with exactly two devices on it, in this case RBridges.

It is true that one could always do this sort of thing outside the
standards. But in Chicago the working group appeared to believe this was
sufficiently important to say in the standard and, while the consensus
in the room was not that detailed, I got the general impression that
people would be favorable to, in a later management document, having a
MIB variable that would enable one to configure an interface as being
known point-to-point, possibly point-to-point, or prohibited from using
this point-to-point outer address flexibility, or some such management
configuration feature. There also seemed to have been at least some
interest in an automated way of determining that an interface was
point-to-point, perhaps based on the receive of 802.1AB frames all
containing appropriate indications coupled with the receipt of no native
frames.

Point-to-point links are, in fact, very common in modern 802.3 networks.

Donald

-----Original Message-----
From: Eric Gray [mailto:eric.gray at ericsson.com] 
Sent: Wednesday, October 03, 2007 11:11 AM
To: Eastlake III Donald-LDE008; Rbridge at postel.org
Subject: RE: [rbridge] Consensus Check: Point to Point links

Donald,

--
Eric Gray
Principal Engineer
Ericsson  

> weeks, we

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 03 Oct 2007 11:27:42 -0700

> Caitlin,
...
> I get the sense that you're not disagreeing with either Joe or 

I agree with the nuances Caitlin is raising; the conclusion is that this
need not be in the spec, as far as we three appear to agree.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20071003/a084c356/signature.bin

---

From: eric.gray at ericsson.com (Eric Gray)
Date: Wed, 3 Oct 2007 14:10:04 -0500

Donald,

	Perhaps all of these things are true. 

	So what?

	The argument that a lot of people would like to do X could
be used to do a lot of things.  I'd like us to make maple walnut 
waffle-cones - possibly with caramel on top. 

	Ummm, does that sound good! 

	What does ANY of this have to do with TRILL?

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Wednesday, October 03, 2007 2:25 PM
> Subject: Re: [rbridge] Consensus Check: Point to Point links
> 
> Hi Eric,
>

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Wed, 03 Oct 2007 17:23:45 -0700

The reason this is useful in the spec is that we can have 
interoperability. The situation is common enough that allowing 
interoperability simplifies implementations.

Dinesh
Joe Touch wrote:
> ------------------------------------------------------------------------
>

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 3 Oct 2007 21:15:48 -0700

I totally agree with Dinesh

-- Silvano

> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Dinesh G Dutt
> Sent: Wednesday, October 03, 2007 5:24 PM
> To: Joe Touch
> Cc: Rbridge at postel.org; Caitlin Bestler

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 03 Oct 2007 22:05:56 -0700

I can't speak for others, but I'm completely lost on this point. Rbridge
is defining a layer on top of ethernet. This pt-pt link stuff sounds
like it's redefining the ethernet layer for a special case.

Whether it's useful to have ethernet have a definition for a pt-pt case
is not relevant to this WG, IMO. It seems at best out of scope, even if
it is useful.

Can anyone explain why this shouldn't be already handled by ethernet,
and if it isn't, why we need to handle it as a special case here?

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20071003/44d93aba/signature.bin

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 3 Oct 2007 22:12:07 -0700

Joe,

The majority of RBridges will be deployed in backbone where they will be
connected by point-to-point links. The classical case will be 10GE links
(which are only full-duplex). There will be no bridges between them.

What we are asking is a sentence that guarantees a simplified
interoperability in this case.

I don't see what harm it can do.

-- Silvano

> From: Joe Touch [mailto:touch at ISI.EDU]
> Sent: Wednesday, October 03, 2007 10:06 PM
> To: Silvano Gai
> Cc: Dinesh G Dutt; Rbridge at postel.org; Caitlin Bestler
[mailto:rbridge-bounces at postel.org]
> >>> I agree with the nuances Caitlin is raising; the conclusion is
that
> > this

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 03 Oct 2007 22:25:32 -0700

> I don't see what harm it can do.

I don't see the need to specify a new, non-ethernet link layer.

If this maps to "point to point links can use encapsulation-only
ethernet" (I'm familiar with such a thing; does it ignore addresses and
use the MAC only for the CRC? if so, what is it called exactly?), and we
can point to that, then there's no need for us to define it.

If no such thing exists, then it might be useful to raise this in the
IEEE. I don't see why it is more relevant to rbridges than to any other
kind of bridge - for which pt-pt interconnections are also already used.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20071003/2a20358c/signature-0001.bin

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 3 Oct 2007 22:41:59 -0700

Joe,

Nobody is asking "to specify a new, non-ethernet link layer."

We are just asking to have a reserved MAC address that means "the other
end of the link".

The frame is still 100% compliant with Ethernet.

-- Silvano

> Sent: Wednesday, October 03, 2007 10:26 PM
> To: Silvano Gai
> >> is not relevant to this WG, IMO. It seems at best out of scope,
even
> > if

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 03 Oct 2007 22:47:58 -0700

> The frame is still 100% compliant with Ethernet.

If regular ethernet and regular bridges don't need this, why do rbridges?

(bridges are already connected by such pt-pt links)

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20071003/63bf8d38/signature.bin

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 3 Oct 2007 22:56:27 -0700

Because Bridges are never addressed at the MAC layer,
RBridges instead are!

-- Silvano

> Sent: Wednesday, October 03, 2007 10:48 PM
> To: Silvano Gai

---

From: eric.gray at ericsson.com (Eric Gray)
Date: Thu, 4 Oct 2007 07:23:33 -0500

Silvano,

	This is NOT AT ALL what Donald said.  Having a reserved 
MAC address for the other end of a link is completely different
from saying "any MAC address may be used and MUST be ignored on
receipt."

	As for this - cleary different - proposal, I think it is
quite reasonable, but almost certainly not something for us to
do - HERE.  As Joe points out, this is a general problem that 
should be addresses generally, rather than here and just for
RBridges.

	This should be done via the IEEE.

--
Eric Gray
Principal Engineer
Ericsson  

> [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai
> Sent: Thursday, October 04, 2007 1:42 AM
> To: Joe Touch
> > use the MAC only for the CRC? if so, what is it called 
> exactly?), and
> we
> > >> Whether it's useful to have ethernet have a definition 
> for a pt-pt
> > > case
> > >>>> We make our world significant by the courage of our 
> questions and
> > > by

---

From: eric.gray at ericsson.com (Eric Gray)
Date: Thu, 4 Oct 2007 07:28:36 -0500

Silvano,

	It is not exactly true that bridges are never addressed at the 
MAC layer.  Consider, for example, how bridges are typically managed
using SNMP, or HTML.

	However, the case is still general, because everything you say
about RBridges - and the likelihood that they might be connected via
P2P links - similarly applies to other devices (L2 end-stations, such
as routers, for example.  And objecting that it may (or may not) be
easy for these devices to determine that a link is P2P is an argument
that applies equally to RBridges.

	I think it is not possible at this point to argue that there is
consensus to do this work here, in the TRILL working group.

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Thursday, October 04, 2007 1:56 AM
> To: Joe Touch

---

From: eric.gray at ericsson.com (Eric Gray)
Date: Thu, 4 Oct 2007 07:33:15 -0500

Joe,

	While what Silvano says about bridges not (typically) being
addressed by MAC address is true, and it is even more likely to be
true for neighbor to neighbor communications, I agree that this is
a general problem.

	I can hardly believe that this is the only example ever to
come up of a layer-2 forwarding device wanting to have direct -
neighbor to neighbor - protocol exchanges.

--
Eric Gray
Principal Engineer
Ericsson  

> [mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch
> Sent: Thursday, October 04, 2007 1:48 AM
> To: Silvano Gai
> * PGP Signed: 10/04/2007 at 07:47:58 AM
> 
> 
> Silvano Gai wrote:
> > Joe,
> > 
> * Joe Touch <touch at isi.edu>
> * 0x89A766BB (L)
> 
>

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 4 Oct 2007 07:17:59 -0700

A frame that is switched by a Bridge is NEVER addressed to the Bridge.
An encapsulated frame that is switched by an RBridge is ALWAYS addressed
to the RBridge.

I understand management frames; it is not what we are discussing here.

Using a reserved MAC address or ignoring the MAC address on
point-to-point links achieves the same goal. Pick one, I don't care.

This is a simple and effective solution; I don't understand the need to
deny it.

-- Silvano

> Sent: Thursday, October 04, 2007 5:29 AM
> To: Silvano Gai; Joe Touch
> > > > We are just asking to have a reserved MAC address that means
"the
> > other

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Thu, 04 Oct 2007 08:50:34 -0700

Personally, I need a reminder of what we are trying to accomplish with 
this before I can have
any opinion.

a) Is omitting the outer VLAN tag to save space?
b) Why put in anything for destination address other than the MAC 
address of the next hop
RBridge, or put in anything into the source address other than your own 
MAC address?
It won't save space. So what does it gain?
c) Is there any danger if an RBridge is confused about whether this is a 
pt-to-pt link or not?

I can see the advantage of omitting the entire outer header if it is 
somehow absolutely
known this is a pt-to-pt link, and both ends of the link understand 
this. But that isn't what's
being proposed here. It seems to be only omitting the VLAN tag, and 
allowing insertion of
random addresses into the source and destination fields in the outer 
header, if I'm reading
it correctly.

So anyway, clarification at this point would certainly help me.

---

From: Caitlin.Bestler at neterion.com (Caitlin Bestler)
Date: Thu, 4 Oct 2007 12:58:09 -0400

Why wouldn't a "other end of the link" reserved MAC address be
just as applicable for core Routers that are directly connected
to each other point-to-point?

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Thu, 4 Oct 2007 10:45:47 -0700

> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> Sent: Thursday, October 04, 2007 8:51 AM
> To: Eastlake III Donald-LDE008
> Personally, I need a reminder of what we are trying to 
> accomplish with this before I can have any opinion.
> 
> b) Why put in anything for destination address other than the 
> MAC address of the next hop RBridge, or put in anything into 
> the source address other than your own MAC address?
> c) Is there any danger if an RBridge is confused about 
> whether this is a pt-to-pt link or not?
> 
> I can see the advantage of omitting the entire outer header 
> if it is somehow absolutely known this is a pt-to-pt link, 
> and both ends of the link understand this. 

That wouldn't work because there are other frames that will
have to have MAC addresses, e.g. LACP, LLDP.

> But that isn't 
> what's being proposed here. It seems to be only omitting the 
> VLAN tag, and allowing insertion of random addresses into the 
> source and destination fields in the outer header, if I'm 
> reading it correctly.

I don't like the idea of random addresses (is it that
a big a deal to set them correctly?), but as long as
it's completely optional, I don't really care. 
[By the way, even though the proposal says that it
can be random, it really can't because we have to
say that they cannot be from the BPDU address space
or things like LACP and LLDP will break.]

Anoop

---

From: eric.gray at ericsson.com (Eric Gray)
Date: Thu, 4 Oct 2007 14:08:52 -0500

Anoop,

	Making it completely optional is a problem as well, and this
is where I am having the most difficulty - particular with "random"
addresses that require ignoring.

	The issue is that this is a wrong-way-around unilateral choice
- i.e. - it is the sender that we say might have the option of doing
this, but the receiver that has the complexity of supporting either
way of doing it.

	If the entity making the choice was also the one having to pay
for it, then I would agree that making it a choice would be okay.

	That does not seem to be the case!

--
Eric Gray
Principal Engineer
Ericsson  

> [mailto:rbridge-bounces at postel.org] On Behalf Of Anoop Ghanwani
> Sent: Thursday, October 04, 2007 1:46 PM
> To: Radia Perlman; Eastlake III Donald-LDE008

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Fri, 5 Oct 2007 00:14:14 -0400

Actually, although I'm not entirely sure, I believe that BPDUs, LLDP
PDUs, etc., all start with an Ethertype which identifies them so, in
principle, they could be made to work on a specially equipped point to
point link with no outer MAC addresses. However, I don't think anyone
has proposed that TRILL should consider omitting the outer MAC addresses
except when that suggestion appears as part of a question asking why, if
you want to do some optimization on a point-to-point link, you don't
want to do even more optimization.

Donald

-----Original Message-----
From: Anoop Ghanwani [mailto:anoop at brocade.com] 
Sent: Thursday, October 04, 2007 1:46 PM
To: Radia Perlman; Eastlake III Donald-LDE008
Cc: Rbridge at postel.org
Subject: RE: [rbridge] Consensus Check: Point to Point links

Anoop

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Fri, 5 Oct 2007 00:24:16 -0400

Hi Radia,

See below at @@@

-----Original Message-----
From: Radia Perlman [mailto:Radia.Perlman at sun.com] 
Sent: Thursday, October 04, 2007 11:51 AM
To: Eastlake III Donald-LDE008
Cc: Rbridge at postel.org
Subject: Re: [rbridge] Consensus Check: Point to Point links

@@@ Yes. The outer VLAN tag does nothing for you on a point-to-point
link.

@@@ While no one has given a really crisp response to that question, it
is my impression that some believe it will make it possible to produce
simpler, less expensive, or more efficient hardware for this case.

pt-to-pt link or not?

@@@ I think there might be. And because of this and the extreme
commonness of the point-to-point case, it may be reasonable to consider
this in designing TRILL. For example, if a fixed MAC address were used
(such as the unicast version of the All-Rbridges multicast address (just
turn off the group bit)), then an interface receiving a frame with that
source address would know there was a sender on the link who believes
the link was point-to-point. If the receiver knows it is not
point-to-point or is unwilling to handle such frames, it could take
appropriate action. Also, Rbridge would know to never bother "learning"
the location of that MAC address.

@@@ Thanks,
@@@ Donald

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Fri, 5 Oct 2007 00:28:36 -0400

Eric,

Well, even if a consensus of the working group wanted to do maple walnut
waffle-cones with caramel, there is a problem that, as far as I can see,
that isn't in our Charter. But I think that this is related enough to
TRILL, as I will explain, that it would be OK to include in our output
if the working group wants to do so.

802.3-like interfaces for point-to-point use as indicated here can be
practical for Rbridge but not for 802.1 bridges because of the
characteristics of the TRILL protocol. In TRILL, the outer VLAN tag is
just an artifact for getting to the next Rbridge (or Rbridges) for TRILL
EtherType frames.  In a point-to-point link between Rbridges, that tag
and the outer MAC addresses are not logically necessary for TRILL
frames. Then tag can be omitted and the addresses can be a value ignored
on receipt.

However, whether you could implenent this feature is influenced by the
design of TRILL. For example, I believe the current protocol spec says
that local sources/sinks of frames on an Rbridge (for example SNMP) are
treated as if they were on a virtual port out of the Rbridge. That means
that, between two Rbridges, such frames area always encapsulated, even
if we has an Rbridge with a co-located management station talking to an
SNMP implementtion in a second Rbridge just one point-to-point link
away. If, in this case, such frames were sent in native form, it seems
to me it would at least make it a more difficult to use, for example, a
fixed MAC address interface or to correctly detect when the assumption
that the interface in point-to-point is incorrect. Thus, even if this
feature isn't mentioned in the TRILL effect, the difficulty and perhaps
even the possibility of implementing it could be affected by details of
the TRILL protocol.

There is also the question of whether the use of such an interface for a
link should be indicated in the Rbridge MIB, although if a fixed know
MAC address were used, I believe that could simply be checked for in the
MIB.

Donald

-----Original Message-----
From: Eric Gray [mailto:eric.gray at ericsson.com] 
Sent: Wednesday, October 03, 2007 3:10 PM
To: Eastlake III Donald-LDE008; Rbridge at postel.org
Subject: RE: [rbridge] Consensus Check: Point to Point links

Donald,

	So what?

--
Eric Gray
Principal Engineer
Ericsson  

> VLAN context that would not be the case without the VLAN
> context.
>

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Fri, 5 Oct 2007 00:29:44 -0400

Hi Caitlin,

It is my understanding that some IETF routing protocols do have special
provisions for "un-numbered links" but by that they mean that IP
addresses are not allocated for the ends of the links. This is a
precedent for not allocating layer-N addresses for a layer-N protocol on
a layer-N-point-to-point link, although in this case N=3.

Layer-3 routing protocols generally aren't concerned with layer-2
addresses or even what layer-2 protocol is running on the link...

Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Caitlin Bestler
Sent: Thursday, October 04, 2007 12:58 PM
To: Silvano Gai; Eric Gray; Joe Touch
Cc: Rbridge at postel.org
Subject: Re: [rbridge] Consensus Check: Point to Point links

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 4 Oct 2007 21:53:48 -0700

I agree with Donald on all points.
The saving comes from not having to maintain an adjacency table on high
speed point-to-point links.

-- Silvano

On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Thursday, October 04, 2007 9:24 PM
> To: Radia Perlman
apparent

---

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Thu, 04 Oct 2007 23:05:39 -0700

Hi Donald,

BPDUs in the L2 world (such as STP, LLDP etc.) are typically identified 
by MAC addresses, not ethertype. Some newer protocols such as CFM & OAM 
are identified by ethertype and there is supposedly a move to identify 
newer BPDUs using ethertype.

The frames we're talking of sending with a fixed (or reserved) address 
are the data frames. BPDUs including IS-IS will use the regular MAC 
address.

Dinesh

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 05 Oct 2007 00:04:32 -0700

I do not understand the need to avoid a single entry per link. This is
hyperoptimization at the expense of complexity, and isn't useful.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20071005/9e519f34/signature.bin

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Fri, 5 Oct 2007 08:28:27 -0400

I don't see any inconsistency between your statement and my statement.

Donald 

-----Original Message-----
From: Dinesh G Dutt [mailto:ddutt at cisco.com] 
Sent: Friday, October 05, 2007 2:06 AM
To: Eastlake III Donald-LDE008
Cc: Anoop Ghanwani; Rbridge at postel.org
Subject: Re: [rbridge] Consensus Check: Point to Point links

Hi Donald,

Dinesh

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Fri, 5 Oct 2007 09:52:55 -0700

I agree with Joe on this point.

Anoop 

> Sent: Friday, October 05, 2007 12:05 AM
> To: Silvano Gai
> Cc: Rbridge at postel.org; Radia Perlman
> I do not understand the need to avoid a single entry per 
> link. This is hyperoptimization at the expense of complexity, 
> and isn't useful.
> 
> Joe
> 
> Silvano Gai wrote:
> > The saving comes from not having to maintain an adjacency table on 
> > high speed point-to-point links.
> > 
> > -- Silvano
> > 
> >> Personally, I need a reminder of what we are trying to accomplish 
> >> with this before I can have any opinion.
> >>
> >> address of the next hop RBridge, or put in anything into 
> the source 
> >> address other than your
> > own
> >> MAC address?
> >> @@@ While no one has given a really crisp response to that 
> question,
> > it
> >> is my impression that some believe it will make it possible to 
> >> produce simpler, less expensive, or more efficient 
> hardware for this case.
> >>
> whether this 
> >> is
> > a
> >> this in designing TRILL. For example, if a fixed MAC address were 
> >> used (such as the unicast version of the All-Rbridges multicast 
> >> address
> > (just
> >> somehow absolutely known this is a pt-to-pt link, and both ends of 
> >> the link understand this. But that isn't what's being 
> proposed here. 
> >> It seems to be only omitting the VLAN tag, and allowing 
> insertion of 
> >> header, if I'm reading it correctly.
> >>
> >>> If no particular controversy arises over this in the next 
> two weeks,
> >> we

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Fri, 05 Oct 2007 14:04:10 -0700

I also don't understand why this is important, but to the extent with 
which I do understand the
implementation concern, how about instead of saying you can put whatever 
you want in
source and destination, we instead define two constant MAC addresses, 
one that can
always be used by an RBridge in the source field, say, RBridge-from-MAC,
and another that can always be
used in the destination field, say RBridge-to-MAC.
So if you think it's a pt-to-pt link, and you don't want to keep
track of the MAC address of your neighbor, you can fill out the outer 
header with those
two MAC addresses. If you are confused and there are bridges on the 
link, nobody will
get confused. If "RBridge-from-MAC" is used by multiple RBridges on the 
same layer 2 cloud,
bridges will have confused caches about the location of that address, 
but that won't matter if
it's never used in the destination field.

There is the problem that if there are multiple RBridges on the link 
(and the RBridges haven't
yet figured that out), then packets will get duplicated because both 
RBridges will pick up the
packet. (the same would be true if you think you're on a pt-to-pt link 
with the "allow random
addresses in there proposal). This (constant addresses) is safer because 
you wouldn't have the
problem of a confused RBridge on a link with hundreds of other RBridges 
picking up every
packet that RBridges are trying to forward to each other.

So I'd prefer not having this feature at all, since I don't understand 
its purpose, but if we are
going to do it, because (to the extent to which I understand it) an 
RBridge might not have
a MAC address on a pt-to-pt link to use as the source, and/or the 
RBridge doesn't want
to keep track of the next hop RBridge address to fill out the 
destination address, then having
a constant from and to address would seem a better and less mysterious 
solution than saying
the addresses can be any random value.

Radia

Anoop Ghanwani wrote:
>>>> @@@ Yes. The outer VLAN tag does nothing for you on a 
>>>>         
>> point-to-point 
>>     
>>>> link.
>>>>
>>>> commonness of the point-to-point case, it may be reasonable to
>>>>         
>>> consider
>>>       
>>>> turn off the group bit)), then an interface receiving a frame with
>>>>         
>>> that
>>>       
>>>> source address would know there was a sender on the link 
>>>>         
>> who believes 
>>     
>>>> point-to-point or is unwilling to handle such frames, it 
>>>>         
>> could take 
>>     
>>>> appropriate action. Also, Rbridge would know to never bother
>>>>         
>>> "learning"
>>>       
>>>> I can see the advantage of omitting the entire outer 
>>>>         
>> header if it is 
>>     
>>>> random addresses into the source and destination fields in 
>>>>         
>> the outer 
>>     
>>>>> consensus from the minutes of the Chicago meeting for a 
>>>>>           
>> change from 
>>     
>>>>> protocol draft -05:
>>>>>
>>>>>    RBridges, then the outer header, if it is an Ethernet 
>>>>>           
>> header, can
>>     
>>>>>    have any source and/or destination addresses, those addresses
>>>>>           
>>> will
>>>

---

From: Caitlin.Bestler at neterion.com (Caitlin Bestler)
Date: Fri, 5 Oct 2007 17:39:24 -0400

Radia Perlman wrote:
-----Original Message-----

I also don't understand why this is important, but to the extent with 
which I do understand the implementation concern, how about instead of
saying you can put whatever you want in source and destination, we
instead define two constant MAC addresses, one that can always be used
by an RBridge in the source field, say, RBridge-from-MAC, and another
that can always be used in the destination field, say RBridge-to-MAC.

---------------------------------

What I like about this proposal is that any RBridge that does not
care to implement this feature will just see traffic that is not
addressed to it. I think the only impact beyond the RBridges that
are actually implementing the feature is the need to reserve the
special MAC addresses.

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Fri, 5 Oct 2007 15:58:50 -0700

Joe,

If there is a bridge in between two RBridges you need to have a full
adjacency table.

If the link is point to point, you can save the table.

When the standard will be done, 40 and 100 Gb/s links will start to be
used.
On these links saving the adjacency table is a big deal.
It is not only the silicon cost, but also the memory bandwidth.

I don't see the additional complexity of a statement that says:
"on point-to-point link the MAC address xxxxxxxxx can be used as a
destination MAC".

-- Silvano

> Cc: Eastlake III Donald-LDE008; Radia Perlman; Rbridge at postel.org
high
> >> Personally, I need a reminder of what we are trying to accomplish
with
point-to-point
question,
> >> is my impression that some believe it will make it possible to
produce
> >> c) Is there any danger if an RBridge is confused about whether this
is
> >> this in designing TRILL. For example, if a fixed MAC address were
used
> >>> If no particular controversy arises over this in the next two
weeks,

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 05 Oct 2007 17:24:08 -0700

Radia Perlman wrote:
...
> its purpose, 

I would really like the purpose to be explained before we explore
alternative solutions. And when I say purpose, I mean:

	- why the IETF rbridge WG should be addressing this issue now

vs., e.g., the IEEE, for some future link technology, now or in the future.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20071005/df7c6951/signature.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 05 Oct 2007 17:22:43 -0700

> If the link is point to point, you can save the table.

If the link is point to point, I still need to know what to send over
the link, so each side still needs adjacency information.

> On these links saving the adjacency table is a big deal.

And when those links are defined, such pt-pt links can be usefully
defined within the IEEE.

> "on point-to-point link the MAC address xxxxxxxxx can be used as a

I see absolutely no need for this group to make that recommendation.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20071005/8c0b6273/signature-0001.bin

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Fri, 5 Oct 2007 17:27:58 -0700

Joe,

> Sent: Friday, October 05, 2007 5:23 PM
> To: Silvano Gai

This is not correct; you need to do a lookup to find the port, that is
it.
Otherwise you need to do a lookup to find the MAC address, rewrite the
MAC address and then another lookup to find the port.

-- Silvano

> >>>> RBridge, or put in anything into the source address other than
your
> >>>> (such as the unicast version of the All-Rbridges multicast
address

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 05 Oct 2007 18:00:38 -0700

> MAC address and then another lookup to find the port.

So what do I save again? Yes, on the rewriting and additional lookup.
But space?

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20071005/7b1e62bd/signature.bin

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Fri, 5 Oct 2007 18:39:30 -0700

Joe, 

inline

> Sent: Friday, October 05, 2007 6:01 PM
> To: Silvano Gai

At 100 Gb/s you can send 150 millions frame/s, i.e. you have 6 ns/frame.
Any operation you save it counts. Also the memory bandwidth saved in
retrieving the rewrite information may make the difference from being
able to use off chip memory (larger) or being forced to stay on chip
(smaller).

-- Silvano

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Fri, 5 Oct 2007 19:54:23 -0700

> Sent: Friday, October 05, 2007 6:40 PM
> To: Joe Touch
> Any operation you save it counts. Also the memory bandwidth 
> saved in retrieving the rewrite information may make the 
> difference from being able to use off chip memory (larger) or 
> being forced to stay on chip (smaller).

I don't understand why memory bandwidth would be an issue.  
We are talking a single address per port.

Anoop

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 05 Oct 2007 20:44:24 -0700

Silvano Gai wrote:
...
> At 100 Gb/s you can send 150 millions frame/s, i.e. you have 6 ns/frame.

And solving that problem would be a fine issue for the IEEE 802.3 HSSG.
There would be a similar benefit for any pt-pt 100 gbps link, as an
optimization. However, this is at the level of optimizing a single link;
unless this is a pt-pt  device, there would be other links with similar
lookup requirements, so the benefit would be fractional anyway.

This remains, as a result, (a) in the margins of a (b) future problem.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20071005/fa392bb7/signature.bin

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Sun, 7 Oct 2007 13:24:41 -0400

I don't see why the IEEE would be interested in this. It requires that
the outer MAC addresses (except for certain control frames/addresses) be
insignificant. This is true for point-to-point links between Rbridges
and between routers but not for point-to-point links between Bridges.
The IETF does routers and Rbridges. (I was there when one of the leaders
in 802.1 said in front of the 802.1 working group (not their exact
words) "Oh, RBridges swap the outer addresses on each hop. They are
obviously routers, not bridges.")

Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Joe Touch
Sent: Friday, October 05, 2007 8:24 PM
To: Radia Perlman
Cc: Rbridge at postel.org
Subject: Re: [rbridge] Consensus Check: Point to Point links

Radia Perlman wrote:
...

vs., e.g., the IEEE, for some future link technology, now or in the
future.

Joe