[rbridge] Ingress Rbridge and FTAG again

[Alia Atlas]

Hi Dinesh,

On 10/20/06, Dinesh G Dutt <ddutt at cisco.com> 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.

Just because one is content to for Eric to do the work of discussing a
common position doesn't indicate agreement with your position.

I certainly haven't heard a strong enough argument for including the
ingress rbridge.  For instance, if you really want traceroute equiv,
well, the encapsulated Ethernet frame contains  the source MAC from
right before the entrance to the rbridge area.  Why can't that be used
to get replies back?

As to the Ftag, I've not heard why the 3 bits that are equiv to the
EXP bits in an MPLS header coudn't be used to indicate a CoS related
mechanism.

I am particularly against the idea, that hasn't gotten much
discussion, of trying to include info about how the final rbridge
should direct a packet out.  I think this impacts the scalability &
requires additional knowledge be distributed to all the rbridges.  A
similiar thing can be done with the MPLS Layer-3 VPN, where a
different label is used to indicate the outgoing interface, etc.

Alia