Hi Yiu,
thanks a lot for your detailed review, and sorry for the delay in responding. Please see inline.. From: Lee, Yiu [mailto:[email protected]] Sent: Friday, February 25, 2011 9:52 PM To: Softwires; Frank Brockners (fbrockne); Sri Gundavelli (sgundave); [email protected]; [email protected] Subject: GI-DS-lite Review Hi authors, I was asked to do a review on the GI-DS-lite draft, this is my review. The draft is well written and is ready to publish. P.3: If e.g., a GRE based encapsulation mechanisms is chosen, it allows the network between the access gateway and the "NAT" to be either IPv4 or IPv6 Suggest to change NAT to AFTR. ...FB: Thanks. Good catch. P.4: AFTR: Address Family Transition Router (also known as "Large Scale NAT (LSN)" or "Dual-Stack lite Tunnel Concentrator", or "Carrier Grade NAT"). An AFTR combines IP-in-IP tunnel termination and IPv4-IPv4 NAT. Suggest to remove "(also known as "Large Scale NAT (LSN)" or "Dual-Stack lite Tunnel Concentrator", or "Carrier Grade NAT"). " ...FB: OK. P.4: TID: Access Tunnel Identifier. The interface identifier of the point-to-point access tunnel. In the GI-DS-lite context, my understanding is the GW is a L3 device, the TID (e.g. SID of the PPPoE) could be used to map to a CID. The two usages I can think of in the draft is mapping the SID to the GRE-key and SID to the IPv6-Flow-Label. But since MPLS-VPN and IP-in-IP are using AD's source IP address for the CID, the TID won't be used. In case of WiMAX, no TID will be assigned to the AD. This isn't discussed clearly in the draft. Do you think we should write a session to capture this? ...FB: Agreed. Let's look at things again: Right now the draft states that "Local policies at the Gateway determine which part of the traffic received from an access device is tunneled over the softwire to the AFTR." As you note, a tunnel identifier could be one way to identify traffic from an AD for some deployments, the source IP address could be another way for another type of deployment. How about adding another sentence: "Deployment dependent, ADs can be identified by either the source IP-address or an access tunnel identifier" - and then removing the verbiage on "TID" in all the other places? P.4: The combination of CID and SWID (potentially along with other traffic identifiers such as e.g. interface, VLAN, port, etc.) serves as common context between Gateway and AFTR to uniquely identify flows associated with an access device. Suggest to rewrite to: "The combination of CID and SWID must be unique between gateway and AFTR to identify the flows associated with an AD." ...FB: We can make this change, but should be cognizant of the fact that we change the meaning here. The original sentence would allow for deployments where CID and SWID are insufficient to identify the flows associated with an AD - in which case another identifier would be needed (like a VLAN). That said, I think this is a bit orthogonal to the draft, so I'm fine with the suggestion to change the text. P.5: The outer/ external IPv4 address of a NAT-binding at the AFTR is either assigned autonomously by the AFTR from a local address pool..... Suggest to rewrite to: "The NAT binding of the AD's address could be assigned autonomously by the AFTR from a local address pool....." ..FB: ok P.8: Softwire identification is supplied by the endpoints of the GRE tunnel. The GRE-key serves as CID. Suggest to rewrite to "SWID is the source address of the GRE tunnel from the GW. The CID is the GRE-key assigned to the AD. ..FB: ok P.7: MPLS VPN: Softwire identification is supplied by the VPN Identifier of the MPLS VPN. The IPv4-address serves as CID. The IPv4-address within a VPN has to be unique. Suggest to rewrite to "SWID is the MPLS VPN label. The AD's IPv4-address is the CID. Give a MPLS VPN label, the AD's IPv4 address must be unique. ..FB: ok P.7: Softwire identification is supplied by the endpoints of the IP-in-IP tunnel. Either the inner IPv4-address serves as CID (in which case the IPv4-address has to be unique) or the IPv6-Flow-Label serves as CID (which obviously only applies to cases where IPv6 transport is used). Note that when using the IP- Flow-Label as CID additional scaling considerations might apply given that the CID is to only 20 bits wide in this case. Also one should ensure sufficient randomization in this case to for example avoid interference with other uses of the IP-Flow-Label, such as ECMP. I think it would be more clear to separate the discussion for IPv4-in-IPv4 and IPv4-in-IPv6. Suggest to rewrite to: "IPv4-in-IPv4: SWID is the outer IPv4 source address. The AD's IPv4 address is the CID. Given an outer IPv4 source address, the AD's IPv4 address must be unique. IPv4-in-IPv6: SWID is the outer IPv6 source address. If the AD's IPv4 address is the CID, the AD's IPv4 address must be unique. If the IPv6-Flow-Label [RFC3697] is the CID, the AD's IPv4 address may be overlapped. IPv6-Flow-Label is 20-bit wide which is shorter than the recommended 32-bit CID. In addition, one should ensure sufficient randomization to avoid possible interference with other uses of the IP-Flow-Label, such as ECMP." P.9: May want to update Figure 3 to separate the two IP-in-IP cases. ..FB: ok. Thanks for all your suggestions. We're working on updating the draft - and will have a revised version (also including Olaf's and Paco's changes) out shortly. Regards, Frank Regards, Yiu
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
