Re: [trill] Comments on draft-dunbar-trill-directory-assisted-encap

Fang Wei,

Sorry for the late response due to lack of internet access during my vacation last two weeks. Answers to your questions are inserted below:

From: hu.fangwei@zte.com.cn [mailto:hu.fangwei@zte.com.cn]
Sent: Friday, August 09, 2013 2:59 AM
To: Linda Dunbar
Cc: trill@ietf.org; trill-bounces@ietf.org
Subject: Re: [trill] Comments on draft-dunbar-trill-directory-assisted-encap

Hi,Linda

When R1 receives a frame, it will check the MAC-SA, and find that it is from E1.  Will R1 re-encapsulate the ingress nickname from "phantom nickname" to N1(R1's nickname)?
[Linda] R1 will not re-encapsulate the frame because the MAC-DA of the frame is R1.  R1 will terminate the MAC header and look into  the payload, which is a TRILL frame. R1 will put another MAC header with MAC-DA being the egress RBridge’s MAC and MAC-SA being its own MAC.

In addition, how about the multi-destination forwarding , does the multi-destination forwarding support in this document?

[Linda] For multi destination frames, the destination Nickname should be a root of multicast tree.

Linda

 Best Regards.

Linda Dunbar <linda.dunbar@huawei.com>
发件人:  trill-bounces@ietf.org

2013-08-03 14:39

收件人

"hu.fangwei@zte.com.cn" <hu.fangwei@zte.com.cn>cn>, "trill@ietf.org" <trill@ietf.org>

抄送

主题

Re: [trill] Comments on draft-dunbar-trill-directory-assisted-encap

Fang Wei,

Sorry for the delayed response. Answers to your comments are inserted below:

From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of hu.fangwei@zte.com.cn
Sent: Wednesday, July 31, 2013 10:49 AM
To: trill@ietf.org
Subject: [trill] Comments on draft-dunbar-trill-directory-assisted-encap

Hi, Linda

I have several comments:

(1) We say that E1 is the "Non-RBridge Nodes", R1 is the local edge RBridge. E1 will encapsulate the TRILL encapsuation with the ingress nickname as "Phantom nickname", and  egress nickname as the nickname of R1(we say it N1). The encapuslation frame will be forwarded to R1. My question is that, how R1 know that the trill encapuslation frame is sent by E1(Non-RBridge node)?

[Linda] There is an Ethernet header in front of the RBridge header. R1 knows that the frame from is from E1 from the MAC-SA.

(2) The concept of  'TRILL   Encapsulating node'' or ''Simplified RBridge' is defined in section 3. But it never used in the document. Is it the same meaning with non-RBridge nodes?

[Linda] We call a non-RBridge nodes that can encapsulate TRILL header as “TRILL Encapsulating node”, or “Directory reliant smart end node”. We can finalize the term when going through the WG adoption.

Linda

Fangwei

Regards_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill