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

From: Linda Dunbar <[email-masked]>
Date: Sat, 3 Aug 2013 06:39:23 +0000

Fang Wei,

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 31, 2013 10:49 AM
To: [email-masked]
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

---

From: [email-masked]
Date: Fri, 9 Aug 2013 15:59:05 +0800

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)? If yes, it is deviated with RFC 6325(the 
specification in section 3.7.2 in RFC6325 is "Once the ingress nickname 
field is set, it MUST NOT be changed by any  subsequent transit 
RBridge."). R1 should not change the ingress nickname field because it is 
not a egress/ingress RBridge for that trill encapsulation frame. R1 is the 
transit RBridge for that frame; If not, the remote RB could not learn the 
nickname of R1. So I think the non-RBridge use the phantom nickname (or 
other special nickname) is not a good idea.

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

Linda Dunbar <[email-masked]> 
发件人:  [email-masked]
2013-08-03 14:39

收件人
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
抄送

主题
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: [email-masked] [mailto:[email-masked]] On Behalf Of 
[email-masked]
Sent: Wednesday, July 31, 2013 10:49 AM
To: [email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/trill

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 20 Aug 2013 02:41:02 +0000

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: [email-masked] [mailto:[email-masked]]
Sent: Friday, August 09, 2013 2:59 AM
To: Linda Dunbar
Cc: [email-masked]; [email-masked]
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.

2013-08-03 14:39

收件人

"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

抄送

主题

Fang Wei,

Hi, Linda

I have several comments:

[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

---

From: [email-masked]
Date: Tue, 20 Aug 2013 10:57:14 +0800

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.

(2) The transit RBridges could not pass the RPF check for 
multi-destination forwarding.

2013-08-20 10:41

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
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: [email-masked] [mailto:[email-masked]] 
Sent: Friday, August 09, 2013 2:59 AM
To: Linda Dunbar
Cc: [email-masked]; [email-masked]
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. 

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

 Best Regards. 

收件人

主题

Fang Wei, 

Hi, Linda 

I have several comments: 

  
  
Linda 

Fangwei

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 20 Aug 2013 21:31:35 +0000

Fang Wei,

Answers to your comments are inserted below:

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, August 19, 2013 9:57 PM
To: Linda Dunbar
Cc: [email-masked]; [email-masked]
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”?

(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.

Linda

2013-08-20 10:41

收件人

抄送

"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

主题

Fang Wei,

Hi,Linda

Linda

Best Regards.

2013-08-03 14:39

收件人

抄送

主题

Fang Wei,

Hi, Linda

I have several comments:

Linda

Fangwei

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 20 Aug 2013 20:46:11 -0400

Hi,

See at (dee3).

On Tue, Aug 20, 2013 at 5:31 PM, Linda Dunbar <[email-masked]>wrote:

>  Fang Wei, ****
>
> ** **
>
> Answers to your comments are inserted below:****
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]]
> *Sent:* Monday, August 19, 2013 9:57 PM
>
> *To:* Linda Dunbar
> *Cc:* [email-masked]; [email-masked]
> *Subject:* RE: [trill] Comments on
> draft-dunbar-trill-directory-assisted-encap****
>
>  ** **
>
>
> Hi,Linda
>
> [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.
>
> 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
 [email-masked]

> **
>
> Linda****
>
>
>
>
> ****
>
> *Linda Dunbar <[email-masked]>* ****
>
> 2013-08-20 10:41 ****
>
> 收件人****
>
> "[email-masked]" <[email-masked]> ****
>
> 抄送****
>
> "[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]> ****
>
> 主题****
>
> RE: [trill] Comments on draft-dunbar-trill-directory-assisted-encap****
>
> ** **
>
>
>
>
> Fang Wei,
>
> *From:* [email-masked] [mailto:[email-masked]] *
> Sent:* Friday, August 09, 2013 2:59 AM*
> To:* Linda Dunbar*
> Cc:* [email-masked]; [email-masked]*
> Subject:* Re: [trill] Comments on
> Best Regards. ****
> *Linda Dunbar <[email-masked]>*
> 发件人:  [email-masked] ****
>
> 2013-08-03 14:39 ****
>
> ** **
>
> 收件人****
>
> "[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]> ****
>
> 抄送****
>
> 主题****
>
> Re: [trill] Comments on draft-dunbar-trill-directory-assisted-encap****
>
>
>   ****
>
> ** **
>
>
>
>
>
> Fang Wei,
>
>  *
> From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of [email-masked]*
> Sent:* Wednesday, July 31, 2013 10:49 AM*
> To:* [email-masked]*
> Subject:* [trill] Comments on draft-dunbar-trill-directory-assisted-encap
>
>
> Hi, Linda
>
> I have several comments:
>
> question is that, how R1 know that the trill encapuslation frame is sent by
> E1(Non-RBridge node)?
>
> “TRILL Encapsulating node”, or “Directory reliant smart end node”. We can
> finalize the term when going through the WG adoption.
>
> Linda
>
>
>
> Fangwei
>
> https://www.ietf.org/mailman/listinfo/trill ****
>
> _______________________________________________
> trill mailing list
> [email-masked]

---

From: [email-masked]
Date: Wed, 21 Aug 2013 11:30:25 +0800

Linda
I am total confused with the solution.

In section 4 of the draft, a phontom nickname is used for the ingress 
nickname when the non-rbridge nodes encapsulates the trill frame(a new 
nickname can be given to an RBridge edge node, e.g. Phantom  Nickname, to 
represent all the TRILL Encapsulating Nodes attached to the RBridge edge 
node.). But here, you said that the ingress nickname is R1's nickname.

Would you please describle the encapsulation frame format for E1 and R1? 
Thanks.

2013-08-21 05:31

收件人

Fang Wei, 

Subject: RE: [trill] Comments on 

Hi,Linda 

 
[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”?

Ingress RBridge. 
 
Linda

收件人

Fang Wei, 

Hi,Linda 

  
  
Linda 

Best Regards. 

收件人

主题

Fang Wei, 

Hi, Linda 

I have several comments: 

 
 
Linda 

Fangwei

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 21 Aug 2013 19:33:13 +0000

Fang Wei,

The “phantom nickname” is the Ingress RBridge’s nickname. Just two nicknames are assigned to each edge RBridge, one nickname indicates that the TRILL encapsulation is done by the RBridge itself, the other nickname  (i.e. Phantom nickname) indicates that the TRILL encapsulation is done by the end nodes attached to the RBridge.

Using Phantom Nickname is an option. RBridge, by default,  is capable of receiving data frame with its own nickname in the SA field of the TRILL header.

Is it clear to you now?

Linda

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, August 20, 2013 10:30 PM
To: Linda Dunbar
Cc: [email-masked]; [email-masked]
Subject: Re: RE: [trill] Comments on draft-dunbar-trill-directory-assisted-encap

Linda

In section 4 of the draft, a phontom nickname is used for the ingress nickname when the non-rbridge nodes encapsulates the trill frame(a new nickname can be given to an RBridge edge node, e.g. Phantom  Nickname, to represent all the TRILL Encapsulating Nodes attached to the RBridge edge node.). But here, you said that the ingress nickname is R1's nickname.

Would you please describle the encapsulation frame format for E1 and R1? Thanks.

2013-08-21 05:31

收件人

抄送

主题

Fang Wei,

Hi,Linda

Linda

2013-08-20 10:41

收件人

抄送

主题

Fang Wei,

Hi,Linda

Linda

Best Regards.

2013-08-03 14:39

收件人

抄送

主题

Fang Wei,

Hi, Linda

I have several comments:

Linda

Fangwei

---

From: [email-masked]
Date: Thu, 22 Aug 2013 09:16:54 +0800

Hi, Linda

If two phantom nicknames(PN1, PN2) are assigned to two edge ingress 
RBridge(R1 and R2)respectly, are PN1 and PN2 the same value or different?

Thanks

2013-08-22 03:33

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
Re: [trill] Comments on draft-dunbar-trill-directory-assisted-encap

Fang Wei, 
 
The “phantom nickname” is the Ingress RBridge’s nickname. Just two 
nicknames are assigned to each edge RBridge, one nickname indicates that 
the TRILL encapsulation is done by the RBridge itself, the other nickname 
(i.e. Phantom nickname) indicates that the TRILL encapsulation is done by 
the end nodes attached to the RBridge. 
 
Using Phantom Nickname is an option. RBridge, by default,  is capable of 
receiving data frame with its own nickname in the SA field of the TRILL 
header. 
 
Is it clear to you now?
 
Linda

Subject: Re: RE: [trill] Comments on 

Linda 

收件人

Fang Wei, 

Hi,Linda 

  

Linda 

收件人

Fang Wei, 

Hi,Linda 

 
 
Linda 

Best Regards. 

收件人

主题

Fang Wei, 

Hi, Linda 

I have several comments: 

Linda 

Fangwei

---

From: [email-masked]
Date: Thu, 22 Aug 2013 10:33:15 +0800

Hi, Donald

Please see my comments inline with [hfw]

[hfw] This is one of the scenarios : local end station can do TRILL 
encapsulation, while the remote endstation only process the native frame.

(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.
[hfw] Is phantom nickname golabl unique or RB unique? For global unique, 
all the edge RBridges have the same value. In this situation, the RPF does 
not pass for multi-destination.
     For RB unique, different edge RBridges have different phantom 
nicknames. In this situation, it wastes many nicknames. We can assign the 
RB1's nickname (N1, not phantom nickname) to the non-RBridge nodes.
Thanks!
Fangwei

Donald Eastlake <[email-masked]> 
发件人:  [email-masked]
2013-08-21 08:46

收件人
Linda Dunbar <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" <[email-masked]>
主题
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 <[email-masked]> 
wrote:
Fang Wei, 

To: Linda Dunbar

Hi,Linda 

 (dee3) The only place where there might be an RPF check problem is on 

收件人
[email-masked]> 

Fang Wei, 

Hi,Linda 

  
  
Linda 

Best Regards. 

收件人
[email-masked]> 
抄送

主题

Fang Wei, 

Hi, Linda 

I have several comments: 

 
 
Linda 

Fangwei

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 21 Aug 2013 23:04:18 -0400

Hi Fangwei,

On Wed, Aug 21, 2013 at 10:33 PM, <[email-masked]> wrote:
> (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.
>
> [hfw] This is one of the scenarios : local end station can do TRILL encapsulation, while the remote endstation only process the native frame.
>
>
>  (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.
>
> [hfw] Is phantom nickname golabl unique or RB unique? For global unique, all the edge RBridges have the same value. In this situation, the RPF does not pass for multi-destination.

If you use a phantom nickname, I think there needs to be one phantom
nickname unique across the campus for each edge RBridge to which
pre-ingressed frames are being sent. The idea is that the edge RBridge
doesn't need to do any different processing (other than accepting
pre-ingressed packets). If you just had one phantom nickname for the
campus, lots of things would not work, such as unicast address
learning. Probably the phantom nickname needs to be reported in LSP as
being adjacent to its associated edge RBridge with zero cost...

>      For RB unique, different edge RBridges have different phantom nicknames. In this situation, it wastes many nicknames. We can assign the RB1's nickname (N1, not phantom nickname) to the non-RBridge nodes.

You can use RB1's nickname if RB1 will accept pre-ingressed frames
where the ingress nickname field is equal to RB1's nickname.

Thanks,
Donald

> "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> 主题
> On Tue, Aug 20, 2013 at 5:31 PM, Linda Dunbar <[email-masked]> wrote:
> Fang Wei,
>
>
>
> (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.
>  (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

---

From: [email-masked]
Date: Thu, 22 Aug 2013 11:22:50 +0800

Hi, Donald

If we could use the R1's nickname for the non-RBridge encapsulation, the 
phantom nickname is no need for the document to save the nickname. The 
idea is very similar with Radia Perlman's 
draft(draft-perlman-trill-smart-endnode).

Thanks

2013-08-22 11:04

收件人
Hu Fangwei <[email-masked]>
抄送
Linda Dunbar <[email-masked]>, "[email-masked]" <[email-masked]>
主题
Re: 答复: Re: [trill] Comments on 
draft-dunbar-trill-directory-assisted-encap

Hi Fangwei,

>
> (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.

Thanks,
Donald

> "[email-masked]" <[email-masked]>, 
>
> (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.
<[email-masked]>
<[email-masked]>
>
>
> (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?