Subject: [rbridge] Ingress Nickname Selection for Known Unicast Packets

From: "Natarajan, Nandakumar" <[email-masked]>
Date: Thu, 15 Oct 2009 05:12:06 +0000

Hi,

I'm a relative newcomer to the world of RBridges and have been looking through version 13 of the RBridge specification as well as the RBridge mailing list archives. I exchanged an email with Radia about Ingress Nickname selection and she suggested that I post the following to the list.

The specification suggests that an RBridge could acquire multiple nicknames in order be able to serve as a root for multiple Distribution Trees. In the case of a native Known Unicast frame that is processed by an Ingress RBridge (that supports multiple nicknames), which of these nicknames does the RBridge select as the Ingress Nickname when encapsulating the packet? Currently the specification does not state anything about how this should be chosen. Choosing the same nickname as the Ingress Nickname every time would seem to be the preferred answer since it simplifies endnode learning. 

Perhaps the spec. could suggest the following:

"If ingress R1 has multiple nicknames, it should always use the same nickname in the ingress field, to simplify endnode learning".

Thanks,
-Nanda

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

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 15 Oct 2009 10:40:32 -0400

Hi Nanda,

On Thu, Oct 15, 2009 at 1:12 AM, Natarajan, Nandakumar <
[email-masked]> wrote:

> Hi,
>
> I'm a relative newcomer to the world of RBridges and have been looking
> through version 13 of the RBridge specification as well as the RBridge
> mailing list archives. I exchanged an email with Radia about Ingress
> Nickname selection and she suggested that I post the following to the list.
>
> The specification suggests that an RBridge could acquire multiple nicknames
> in order be able to serve as a root for multiple Distribution Trees. In the
> case of a native Known Unicast frame that is processed by an Ingress RBridge
> (that supports multiple nicknames), which of these nicknames does the
> RBridge select as the Ingress Nickname when encapsulating the packet?
> Currently the specification does not state anything about how this should be
> chosen. Choosing the same nickname as the Ingress Nickname every time would
> seem to be the preferred answer since it simplifies endnode learning.
>
> "If ingress R1 has multiple nicknames, it should always use the same
> nickname in the ingress field, to simplify endnode learning".
>

You raise a good point, I think. But there is no need for an RBridge to use
the same ingress nickname for all frames it is encapsulating as long as it
is consistent about using the same nickname whenever it encapsulates from
any particular source MAC address in a particular VLAN. Perhaps it should
say something like

"If ingress R1 has multiple nicknames, it SHOULD use the same nickname in
the ingress field whenever it encapsulates a frame from any particular
source MAC address and VLAN. This simplifies end node learning."

> -Nanda

Thanks,
Donald

---

From: Radia Perlman <[email-masked]>
Date: Thu, 15 Oct 2009 11:40:19 -0700

Yes, Nanda's point is well taken. I'd be OK with either wording. Donald 
is technically correct that it doesn't have to
be as restrictive as "always use the same nickname  in the ingress 
field", as long as it's always the same nickname chosen
for the same source.

However, I can't think of any use for choosing different nicknames for 
different sources, and I'm slightly
nervous that if someone thinks of a use of it, all the ingress RBridges 
will want multiple nicknames. Also, people
have found the multiple nicknames confusing, assuming there must be lots 
of reasons for that feature and that lots
of RBridges would want lots of nicknames.

So I'd slightly
prefer Nanda's wording (implying a single nickname that is really the 
nickname, and the other nicknames, if they
exist, are only for calculating multicast trees). It also means that 
only that preferred nickname need appear in the
unicast forwarding table. And perhaps a way of marking which nickname in 
R1's LSP is R1's preferred nickname,
so other RBridges would know they wouldn't need to put the other 
nickname alias's of R1 into the unicast forwarding table?

Radia

Donald Eastlake wrote:
> Hi Nanda,
>
> On Thu, Oct 15, 2009 at 1:12 AM, Natarajan, Nandakumar 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     I'm a relative newcomer to the world of RBridges and have been
>     looking through version 13 of the RBridge specification as well as
>     the RBridge mailing list archives. I exchanged an email with Radia
>     about Ingress Nickname selection and she suggested that I post the
>     following to the list.
>
>     The specification suggests that an RBridge could acquire multiple
>     nicknames in order be able to serve as a root for multiple
>     Distribution Trees. In the case of a native Known Unicast frame
>     that is processed by an Ingress RBridge (that supports multiple
>     nicknames), which of these nicknames does the RBridge select as
>     the Ingress Nickname when encapsulating the packet? Currently the
>     specification does not state anything about how this should be
>     chosen. Choosing the same nickname as the Ingress Nickname every
>     time would seem to be the preferred answer since it simplifies
>     endnode learning.
>
>     "If ingress R1 has multiple nicknames, it should always use the
>     same nickname in the ingress field, to simplify endnode learning".
>
>
> You raise a good point, I think. But there is no need for an RBridge 
> to use the same ingress nickname for all frames it is encapsulating as 
> long as it is consistent about using the same nickname whenever it 
> encapsulates from any particular source MAC address in a particular 
> VLAN. Perhaps it should say something like
>
> "If ingress R1 has multiple nicknames, it SHOULD use the same nickname 
> in the ingress field whenever it encapsulates a frame from any 
> particular source MAC address and VLAN. This simplifies end node 
> learning."
>  
>
>     Thanks,
>     -Nanda
>
>
> Thanks,
> Donald 
> ------------------------------------------------------------------------
>

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 16 Oct 2009 10:54:01 -0400

OK, if no one objects, we can go with Nanda's wording.
Thanks,
Donald
=============================
Donald E. Eastlake 3rd

On Thu, Oct 15, 2009 at 2:40 PM, Radia Perlman <[email-masked]>wrote:

> Yes, Nanda's point is well taken. I'd be OK with either wording. Donald is
> technically correct that it doesn't have to
> be as restrictive as "always use the same nickname  in the ingress field",
> as long as it's always the same nickname chosen
> for the same source.
>
> have found the multiple nicknames confusing, assuming there must be lots of
> reasons for that feature and that lots
> exist, are only for calculating multicast trees). It also means that only
> that preferred nickname need appear in the
> so other RBridges would know they wouldn't need to put the other nickname
> alias's of R1 into the unicast forwarding table?
>
> Radia
>
>
>
> Donald Eastlake wrote:
>
>> Hi Nanda,
>>
>>
>> [email-masked] <mailto:[email-masked]>> wrote:
>>
>>    Hi,
>>
>> You raise a good point, I think. But there is no need for an RBridge to
>> use the same ingress nickname for all frames it is encapsulating as long as
>> it is consistent about using the same nickname whenever it encapsulates from

---

From: Joe Touch <[email-masked]>
Date: Fri, 16 Oct 2009 08:25:55 -0700

Clarification question:

is there any reason the nickname would need/prefer to correspond to the
distribution tree of a forwarded frame?

i.e., we have different nicknames for different trees; if they're "read
only" or used only in the distribution tree protocol, then we need to
ensure their use is decoupled from the use of nicknames as encapsulation
addrs

e.g., do we need text that says that the source of an encapsulation MUST
NOT be used to infer any table or protocol information? otherwise, use
of nicknames could interfere with other uses...

Joe

Donald Eastlake wrote:
> On Thu, Oct 15, 2009 at 2:40 PM, Radia Perlman <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Yes, Nanda's point is well taken. I'd be OK with either wording.
>     Donald is technically correct that it doesn't have to
>     However, I can't think of any use for choosing different nicknames
>     for different sources, and I'm slightly
>     nervous that if someone thinks of a use of it, all the ingress
>     RBridges will want multiple nicknames. Also, people
>     have found the multiple nicknames confusing, assuming there must be
>     lots of reasons for that feature and that lots
>     prefer Nanda's wording (implying a single nickname that is really
>     the nickname, and the other nicknames, if they
>     unicast forwarding table. And perhaps a way of marking which
>     nickname in R1's LSP is R1's preferred nickname,
>         <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
> 
>            Hi,
> 
>         You raise a good point, I think. But there is no need for an
>         RBridge to use the same ingress nickname for all frames it is
>         encapsulating as long as it is consistent about using the same
>         nickname whenever it encapsulates from any particular source MAC
>         address in a particular VLAN. Perhaps it should say something like
> 
>         "If ingress R1 has multiple nicknames, it SHOULD use the same
>         nickname in the ingress field whenever it encapsulates a frame
>         from any particular source MAC address and VLAN. This simplifies
>         end node learning."
>          
>            Thanks,
>            -Nanda
> 
> 
>         Thanks,
>         Donald
>         [email-masked] <mailto:[email-masked]>

---

From: Dinesh G Dutt <[email-masked]>
Date: Fri, 16 Oct 2009 11:19:32 -0700

I prefer your wording Donald. I see no reason to be restrictive with the 
use of multiple nicknames. I'm fine if you want to put in some 
cautionary text that says that any solution that relies on Rbridges 
having multiple nicknames may not be scalable.

Dinesh
On 10/16/2009 07:54 AM, Donald Eastlake wrote:
> On Thu, Oct 15, 2009 at 2:40 PM, Radia Perlman<[email-masked]>wrote:
>
>    
>>> On Thu, Oct 15, 2009 at 1:12 AM, Natarajan, Nandakumar<
>>> [email-masked]<mailto:[email-masked]>>  wrote:
>>>
>>>     Hi,
>>>

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

---

From: Radia Perlman <[email-masked]>
Date: Fri, 16 Oct 2009 13:51:03 -0700

OK, I'm fine with Donald's wording, and I don't think we need to add 
additional words of warning.

Radia

---

From: "Ramalingam, Swaminathan (Swami)" <[email-masked]>
Date: Tue, 20 Oct 2009 09:05:21 +0530

This looks perfectly fine. BTW, the subject line says "known unicast
packets". I think the following statement hold good for all type of
frames.

Thanks,
Swami

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 20 Oct 2009 10:24:19 -0400

That's reasonable except that there is no "end node learning" is the source
address is not unicast.
Donald

On Mon, Oct 19, 2009 at 11:35 PM, Ramalingam, Swaminathan (Swami) <
[email-masked]> wrote:

> >>> On Thu, Oct 15, 2009 at 2:40 PM, Radia Perlman<[email-masked]
> >wrote:
> >>>
> >>>
> >>>
> Donald is
> field",
> RBridges
> only
> nickname
> to
> nickname in

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 20 Oct 2009 13:50:57 -0400

You can probably ignore my message below as I was temporarily confused
about sources and destinations ....

Donald

On Tuesday, October 20, 2009, Donald Eastlake <[email-masked]> wrote:
> That's reasonable except that there is no "end node learning" is the source address is not unicast.
> Donald
> On Mon, Oct 19, 2009 at 11:35 PM, Ramalingam, Swaminathan (Swami) <[email-masked]> wrote:

-- 
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]