Re: [trill] WG LC for draft-ietf-trill-smart-end-nodes (8/26 to 9/9)- extending WG LC (10/4 to 10/18)//FWD: I-D Action: draft-ietf-trill-smart-endnodes-05.txt
Fangwei: Thank you for uploading the new draft today. I will review the draft as the shepherd and send you comments. Sue Hares From: hu.fang...@zte.com.cn [mailto:hu.fang...@zte.com.cn] Sent: Monday, February 6, 2017 7:53 PM To: Susan Hares; trill@ietf.org; Donald Eastlake Cc: Jon Hudson Subject: Re: [trill] WG LC for draft-ietf-trill-smart-end-nodes (8/26 to 9/9)- extending WG LC (10/4 to 10/18)//FWD: [trill] I-D Action: draft-ietf-trill-smart-endnodes-05.txt Hi,all A new draft is updated based on the discussion with Donald to solve his comments. Please check the link for the new drafts: https://datatracker.ietf.org/doc/draft-ietf-trill-smart-endnodes/ Regards. Fangwei. >Hi, >See below answers to questions and a review of this draft. >Thanks, >Donald === Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com >On Tue, Oct 4, 2016 at 12:10 PM, Susan Hares <sha...@ndzh.com> wrote: > This begins a 2 week extension to the WG LC for > draft-ietf-trill-smart-end-nodes (10/4 to 10/18). We started the call > during August Holidays so the WG may missed this in the email list. The > authors are asked to indicate whether they know of the IPR relating to this > draft. I do not know of any IPR in this draft that has not already been declared. (Note there are two IPR declarations to the IETF by myself. The first is related to a patent application while the second states authoritatively that that patent application has been abandoned.) > WG participants are asked to consider: > > 1) Does this draft ready for publication? I do not think this document is ready for publication. See review below. > 2) Does the extension of the Rbridge to smart-end nodes solve the > problem of learning freshness and provide offload for the > encapsulation/decapsulation problem? Yes, if all the problems in the draft can be cleaned up, it describes a general approach that can solve these problems. > 3) Do you know of any planned implementations or deployments? > Sue Hares and Jon Hudson Comments on draft-ietf-trill-smart-endnodes-04: On Smart-Hellos It turns out that you also need something like Smart-Hellos and a concept of ajdacency in order to support end station access to Pull Directories as well as end station hosting of Pull Directories. So draft-ietf-trill-directory-assist-mechanisms-08 specifies "TRILL ES-IS" which has Hellos and adjacency determination. A problem with Hellos is their limited capacity and that they cannot generally be fragmented. Sending the MAC addresses a Smart Endnode is handling inside Smart Hellos, as the smart-endndoes draft currently specifies, is probably fine for most servers but if there were some kind of specialized gateway or the like that was acting as a Smart Endnode, the MAC addresses (and Data Labels they are in) might not fit into one Hello PDU. TRILL ES-IS also supports local E-L1CS LSPs which provide fragmentation and plenty of room. So perhaps it should be supported to put MAC reachability information in both TRILL ES-IS Hellos and TRILL ES-IS E-L1CS LSPs. [hfw] On using ESADI This draft says that ESADI can be used by Smart Endnodes. But it is not clear how ESADI works to an end station. As ESADI is currently specified, ESADI LSPs would not even be sent onto a link with end stations unless there was more than one edge RBridge on the link with the Smart End Stations and the ESADI distribution tree happens to include that link. Even if ESADI LSPs are being sent on the link, it seems that all the end station could do currently is snoop on the LSPs, which would not be a reliable distribution mechanism because it is not clear how the end station would request ESADI for a particular Data Label or how it would request retransmission of LSPs it missed -- maybe it could originate ESADI PSNPs in that case... But how does the Smart Endstation originate ESADI LSPs? If it uses the nickname the edge RBridge gives it, how does it know that LSP fragments it originates won't colide with those originated by the edge RBridge? If we can figure out how to support ESADI, that should probably go into draft-trill-ietf-directory-assist-mechanisms draft... Since ESADI is the basis of Push Directories, I suggest that this draft be changed to assume that, for directory like stuff, only Pull Directory information is available, not ESDAI or Push Directories. (How an end station can access Pull Directory information is described in draft-ietf-trill-directory-assist-mechanims.) Some other points The draft does not seem to cover the case of an edge RBridge port that supports Smart Endnodes with a link having both Smart and non-Smart end nodes where the edge RBridge port receives a native multi-destination frame from a non-Smart Endnode. In particular, as well as the usual encapsulation, it would
[trill] WG LC for draft-ietf-trill-smart-end-nodes (8/26 to 9/9)- extending WG LC (10/4 to 10/18)
This draft did not reach working group consensus. The authors should post a revision to this draft that address the issues mentioned by Donald Eastlake in the email: https://www.ietf.org/mail-archive/web/trill/current/msg07573.html The WG can reconsider this draft for WG LC after these issues have been addressed. Sue Hares WG co-chair ___ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill
Re: [trill] WG LC for draft-ietf-trill-smart-end-nodes (8/26 to 9/9)- extending WG LC (10/4 to 10/18)
Hi, See below answers to questions and a review of this draft. Thanks, Donald === Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Tue, Oct 4, 2016 at 12:10 PM, Susan Hareswrote: > This begins a 2 week extension to the WG LC for > draft-ietf-trill-smart-end-nodes (10/4 to 10/18). We started the call > during August Holidays so the WG may missed this in the email list. The > authors are asked to indicate whether they know of the IPR relating to this > draft. I do not know of any IPR in this draft that has not already been declared. (Note there are two IPR declarations to the IETF by myself. The first is related to a patent application while the second states authoritatively that that patent application has been abandoned.) > WG participants are asked to consider: > > 1) Does this draft ready for publication? I do not think this document is ready for publication. See review below. > 2) Does the extension of the Rbridge to smart-end nodes solve the > problem of learning freshness and provide offload for the > encapsulation/decapsulation problem? Yes, if all the problems in the draft can be cleaned up, it describes a general approach that can solve these problems. > 3) Do you know of any planned implementations or deployments? > Sue Hares and Jon Hudson Comments on draft-ietf-trill-smart-endnodes-04: On Smart-Hellos It turns out that you also need something like Smart-Hellos and a concept of ajdacency in order to support end station access to Pull Directories as well as end station hosting of Pull Directories. So draft-ietf-trill-directory-assist-mechanisms-08 specifies "TRILL ES-IS" which has Hellos and adjacency determination. A problem with Hellos is their limited capacity and that they cannot generally be fragmented. Sending the MAC addresses a Smart Endnode is handling inside Smart Hellos, as the smart-endndoes draft currently specifies, is probably fine for most servers but if there were some kind of specialized gateway or the like that was acting as a Smart Endnode, the MAC addresses (and Data Labels they are in) might not fit into one Hello PDU. TRILL ES-IS also supports local E-L1CS LSPs which provide fragmentation and plenty of room. So perhaps it should be supported to put MAC reachability information in both TRILL ES-IS Hellos and TRILL ES-IS E-L1CS LSPs. On using ESADI This draft says that ESADI can be used by Smart Endnodes. But it is not clear how ESADI works to an end station. As ESADI is currently specified, ESADI LSPs would not even be sent onto a link with end stations unless there was more than one edge RBridge on the link with the Smart End Stations and the ESADI distribution tree happens to include that link. Even if ESADI LSPs are being sent on the link, it seems that all the end station could do currently is snoop on the LSPs, which would not be a reliable distribution mechanism because it is not clear how the end station would request ESADI for a particular Data Label or how it would request retransmission of LSPs it missed -- maybe it could originate ESADI PSNPs in that case... But how does the Smart Endstation originate ESADI LSPs? If it uses the nickname the edge RBridge gives it, how does it know that LSP fragments it originates won't colide with those originated by the edge RBridge? If we can figure out how to support ESADI, that should probably go into draft-trill-ietf-directory-assist-mechanisms draft... Since ESADI is the basis of Push Directories, I suggest that this draft be changed to assume that, for directory like stuff, only Pull Directory information is available, not ESDAI or Push Directories. (How an end station can access Pull Directory information is described in draft-ietf-trill-directory-assist-mechanims.) Some other points The draft does not seem to cover the case of an edge RBridge port that supports Smart Endnodes with a link having both Smart and non-Smart end nodes where the edge RBridge port receives a native multi-destination frame from a non-Smart Endnode. In particular, as well as the usual encapsulation, it would seem that the edge RBridge always needs to send the encapsulated multi-destination frame out that same port so it will be seen by Smart Endnodes since the draft says that the Smart Endnodes will ignore the native multi-destination frame. But what about the case where there are two edge RBridges with ports on the link and the link is part of the distribution tree? The draft says that if a Smart Endnode originates a multi-destination frame, it encpsulates it to a ditribution tree and unicasts it to an edge RBridge that sends it on the distribution tree. But if that tree includes the link, then it will get sent out the port and the Smart Endnode that originated the encapuslated multi-destinaiton frame will see it -- this violates a fundamental principal of Ethernet that when you