Hi,yuchi, PLS see inline.
Thanks, Wei "Yuchi Chen" <[email protected]> 2014-02-18 12:39:34: > 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. [Wei] I agree. Congestion might hardly occur in normal network traffic. Anyway, the rate of creating new sessions is a key performance indexes of per apparatus under traditional routing scenario. My proposal is that we should consider how to maintain existing performance per apparatus (switch/router) while finding a way to unify IPv6 transition technologies. i.e. reasonable number of controllers in network... > > > > > 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). [Wei]If so, does a switch need to send its NAT44 sessions(or flow tables) to the controller? > > > > > >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
