Subject: [rbridge] Ingress Rbridge and FTAG again

From: sgai at nuovasystems.com (Silvano Gai)
Date: Mon, 23 Oct 2006 09:08:49 -0700

Joe,

Let's summarize what we are asking:

1) today proposal has ingress RBridge address and egress RBdridge
address, but they are not carried both in the same frame. The first
request is to always carry both. I have hard time thinking that this
requires a change in the WG charter.

We showed that on a 512 bytes frame the difference in overhead between
the current TRILL solution and what we propose is 0.37%. Difficult to
argue that it should not be done for bandwidth reason.

2) we are asking to add an FTAG field to better support forwarding, with
particular emphasis on Multicast. The current TRILL proposal supports
only ingress trees and not shared trees. Shared trees are the preferred
way to do multicast. I haven't read a single reply on FTAG that
addresses Multicast.

I don't think that to do these two simple changes we need to modify the
WG charter. If the WG chairs think so, please let us know.

-- Silvano

> -----Original Message-----
> From: Joe Touch [mailto:touch at ISI.EDU]
> Sent: Monday, October 23, 2006 8:28 AM
> To: Silvano Gai
> Cc: Dinesh G Dutt; rbridge at postel.org
> Subject: Re: [rbridge] Ingress Rbridge and FTAG again
> 
> 
> 
> Silvano Gai wrote:
> > Joe,
> >
> > Let's get this straight so we don't waste any more time: "are you
saying
> > that the WG charter is written, the A&P statement is drafted" and
> > therefore the WG is no longer interested in listening to other
> > requirements?
> 
> Anything not stated explicitly in the charter is out-of-scope, UNLESS
it
> is needed to support something in the charter indirectly.  This isn't
a
> matter of "permitted unless prohibited" - the point of the charter is
to
> constrain the scope. It's also not a matter of "once you open the
spec,
> anything is on the table"; that's not how charters work.
> 
> I - and Eric - are saying that if you want to add requirements, FIRST
> you need to get the WG consensus on changing the charter. THEN we need
> to get the AD's on board. THEN we do the work to address the
requirements.
> 
> Joe
> 
> >
> > -- Silvano
> >
> >
> >> -----Original Message-----
> >> From: rbridge-bounces at postel.org
[mailto:rbridge-bounces at postel.org]
> > On
> >> Behalf Of Joe Touch
> >> Sent: Monday, October 23, 2006 6:36 AM
> >> To: Dinesh G Dutt
> >> Cc: rbridge at postel.org
> >> Subject: Re: [rbridge] Ingress Rbridge and FTAG again
> >>
> >>
> >>
> >> Dinesh G Dutt wrote:
> >>> Hi Eric,
> >>>
> >>> Gray, Eric wrote:
> >>>> The argument that "You're changing things, and while you're at
it,
> >>>> why not change these other things" is a particularly obnoxious
old
> >>>> Dinosaur.
> >>>>
> >>> I have shown the reasons and with the exception of you and Joe, I
> >>> haven't heard any objection to including the ingress Rbridge (at
> > least)
> >>> or the FTAG. So, from a democratic spirit, it is upto you two to
> > give us
> >>> technical reasons for objecting instead of saying "its not in the
> >>> charter" or "you can't change that". The charter doesn't
explicitly
> >>> forbid doing traceroute, for example.
> >> Charters define what is permitted; that which is not permitted is
> >> prohibited, unless it is needed to support what is permitted.
> >>
> >> Otherwise, charters would be wide-open to anything not prohibited;
we
> >> don't have time to enumerate that list.
> >>
> >> Joe
> >

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 23 Oct 2006 09:17:11 -0700

> requires a change in the WG charter.

It does because they are required to support capabilities not indicated
in the charter, namely traceroute.

Whether they impact performance on the line, or help performance at the
nodes, is orthogonal unless omitting the source address prevents
802-equivalent performance.

> way to do multicast. I haven't read a single reply on FTAG that

Again, the goal of rbridges is 802 equivalence with modern routing.
Multicast might not be a case where there's a benefit for modern routing
at the link layer. If this is a performance issue then it's relevant
only if existing speeds cannot be supported without the FTAG.

> WG charter. If the WG chairs think so, please let us know.

I've given my interpretation of why they are not in the charter; at
best, it's ambiguous given the current arguments. But I'm not the chair
or AD, who are the arbiters.

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/20061023/d58eac87/signature.bin

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Mon, 23 Oct 2006 11:51:39 -0700

rbridge-bounces at postel.org wrote:
> It does because they are required to support capabilities not
> indicated in the charter, namely traceroute.
> 

There is at least one justification that is in scope: namely that
a core RBridge that also supports 802.1au (congestion avoidance)
would benefit from having the source rbridge so that it could
properly encapsulate its BCN response without requiring a lookup
delay.

I am not convinced that the number of cases where this will be
relevant justifies the extra field -- but including to enable
this case would clearly be in scope.

One reason I currently do not estimate this as a worthwhile
feature is that I believe that the ingress and egress rbridge
will be a majority of the rbridges that any given packet 
traverses. But my perceptions are biased towards the edges
and the working group could come to a different assesment.

Without the source rbridge in the shim header there IS a
negative impact on an 802.1au bridge generating a BCN.
Is that not enough to make this an item to be considered?