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

Hi,

See at (dee3).

On Tue, Aug 20, 2013 at 5:31 PM, Linda Dunbar <linda.dunbar@huawei.com>wrote;wrote:

>  Fang Wei, ****
>
> ** **
>
> Answers to your comments are inserted below:****
>
> ** **
>
> ** **
>
> *From:* hu.fangwei@zte.com.cn [mailto:hu.fangwei@zte.com.cn]
> *Sent:* Monday, August 19, 2013 9:57 PM
>
> *To:* Linda Dunbar
> *Cc:* trill@ietf.org; trill-bounces@ietf.org
> *Subject:* RE: [trill] Comments on
> draft-dunbar-trill-directory-assisted-encap****
>
>  ** **
>
>
> Hi,Linda
>
> I understand that R1 would keep the encapsulation frame from E1. There
> would bring two issues:
>
> (1) The remote egress RBridge could not learn the {nickname, MAC} pair by
> the data frame.
>
> [Linda] The “nickname” is Ingress’ nickname, the MAC-SA is ingress’ too.
> So the egress RBridge should be able to learn the mapping between the
> Ingress’ nickname and its MAC. Why do you say “could not”?
>
> (dee3) Right, its asymmetric. So the end station does the ingress but the
> egress RBridge does the usual egress process, learning the remote MAC
> address as attached to the ingress nickname in the TRILL Data frame -- but
> it does not matter that much if the egress RBridge learns anything if you
> do ingress for traffic going the other way at the end station also.
>
 (2) The transit RBridges could not pass the RPF check for
> multi-destination forwarding. ****
>
> [Linda] Why? The data frame is same as if the frame is encapsulated by the
> Ingress RBridge. ****
>
> ** (dee3) The only place where there might be an RPF check problem is on
> receipt at the first edge RBridge so some care may be needed there.
> Alternatively, you could just not do the ingress at the end station for
> multi-destination frames but have them ingressed by the edge RBridge.
>
Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

> **
>
> Linda****
>
>
>
>
> ****
>
> *Linda Dunbar <linda.dunbar@huawei.com>* ****
>
> 2013-08-20 10:41 ****
>
> 收件人****
>
> "hu.fangwei@zte.com.cn" <hu.fangwei@zte.com.cn> ****
>
> 抄送****
>
> "trill@ietf.org" <trill@ietf.org>rg>, "trill-bounces@ietf.org" <
> trill-bounces@ietf.org> ****
>
> 主题****
>
> 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 ****
>
> _______________________________________________
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill
>
>