Hi Wei, Thanks for the review. The purpose of this work is to provide a unified and flexible framework for implementing and deploying IPv6 transition mechanisms, and enable these mechanisms to coexist in the same infrastructure. Please see inline for the detailed responses.
Best regards! -------------- Yuchi Chen On 2/17/14, 17:36 PM, "[email protected]" <[email protected]> wrote: >Hi Yong, Yuchi, all > > This is a interesting topic. I reviewed this draft and have some >comments and questions. > 1) In section 5 > "When receiving an incoming packet that doesn't have a match in the > flow table (usually the intial packet of a new flow), CPE Switch and > BR Switch MUST forward the packet to Controller. Controller MUST > determine how to proceed the flow (e.g. whether to apply NAT/ NAT64 > translation and/ or softwire encapsluaton/ decapuslutaion), and > interpret the process into a set of forwarding rule configurations. > Controller then passes these configurations to CPE Swtich and BR > Switch. CPE Switch and BR Switch then configure their flow table > according to these configurations," > > Why not let controller create flow table. Since packet is received by >controller, why not let it do more? [yuchi] In this framework switch should do packet forwarding, just like traditional router (or L3 switch). The main difference is that switch doesn't know any other information except for information of flows passing by, which is maintained in the flow table. Controller - a centralized (cluster of) device(s) at a higher level in the network - knows everything (e.g. topology, routing, NAT states, etc) of the network. It can tell a switch how to proceed and forward packets of each flow by configuring the flow table maintained by switch. Hence controller just needs to deal with the first packet of a flow, determine how to proceed the flow, then let the switch do the rest. I think it might not be efficient and may lead to message congestion if let controller do all the packet forwarding. > BTW, does "usually the intial packet of a new flow" mean an intial >packet >of each session? If so, it might lead to message congestion between switch >& >controller. [yuchi] Yes, switch should forward the inital packet of each of unknown flows to controller. I agree that it indeed may lead to congestion if there are too many new flows concurrently passing through switch. However, as controller at the same time only deals with packets no more than the number of concurrent flows passing through switches it connects to (note that all the outbound and inbound packets of a session can be regarded as belonging to the same flow), I think the congestion is less likely to occur and can be mitigated easily. > > 2) What is the concrete consideration between CPE/BR & controller? >such as netconfig, i2rs. > [yuchi] The concrete interface (if this is what you mean) between switch and controller is not specified. IMHO all the protocols (or interfaces) that are able to carry flow information and flow table configuration can be adopted. > 3) Logging is important in NAT, what is the consideration about it? >Maybe a switch is not suitable for logging itself. [yuchi] The logging of a switch can be done by its associated controller. The controller is responsible for maintaining all states that is related to the switch, such as NAT44 state and flow table (if needed). > > >Thanks, >Wei > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
