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

[[e-mail]]

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
 



Linda Dunbar <[e-mail]> 
发件人:  [e-mail]
2013-08-22 03:33

收件人
"[e-mail]" <[e-mail]>
抄送
"[e-mail]" <[e-mail]>, "[e-mail]" 
<[e-mail]>
主题
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
 
 
From: [e-mail] [mailto:[e-mail]] 
Sent: Tuesday, August 20, 2013 10:30 PM
To: Linda Dunbar
Cc: [e-mail]; [e-mail]
Subject: Re: RE: [trill] Comments on 
draft-dunbar-trill-directory-assisted-encap
 

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. 
  


Linda Dunbar <[e-mail]> 
2013-08-21 05:31 


收件人
"[e-mail]" <[e-mail]> 
抄送
"[e-mail]" <[e-mail]>, "[e-mail]" 
<[e-mail]> 
主题
RE: [trill] Comments on draft-dunbar-trill-directory-assisted-encap
 








Fang Wei, 
  
Answers to your comments are inserted below: 
  
  
From: [e-mail] [mailto:[e-mail]] 
Sent: Monday, August 19, 2013 9:57 PM
To: Linda Dunbar
Cc: [e-mail]; [e-mail]
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 

 

Linda Dunbar <[e-mail]> 
2013-08-20 10:41 
 


收件人
"[e-mail]" <[e-mail]> 
抄送
"[e-mail]" <[e-mail]>, "[e-mail]" 
<[e-mail]> 
主题
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: [e-mail] [mailto:[e-mail]] 
Sent: Friday, August 09, 2013 2:59 AM
To: Linda Dunbar
Cc: [e-mail]; [e-mail]
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 <[e-mail]> 
发件人:  [e-mail] 
2013-08-03 14:39 
 
 


收件人
"[e-mail]" <[e-mail]>, "[e-mail]" 
<[e-mail]> 
抄送

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