Subject: [Int-area] FW: [Aeon] Time slots for AEON session at IETF 89 - Please indicate available via link below by Wed. Feb 19

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 17 Feb 2014 23:47:59 +0000

Just an FYI, we posted and presented the following draft at previous IETF
meetings:

A Framework for Signaling Flow Characteristics between Applications and
the Network 
(http://tools.ietf.org/html/draft-eckert-intarea-flow-metadata-framework-02
)

We have taken the feedback from this and created two new drafts, focusing
on the problem statement and use cases, respectively:
"Application Enabled Open Networking: Problem Statement and Requirements²,
draft-eckel-aeon-problem-statement-00
(http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00)
"Application Enabled Open Networking Use Cases²,
draft-eckel-aeon-use-cases-01
(http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01)

If you are interested in this area, you should consider subscribing to the
AEON list and attending the meeting we are planning at IETF 89, as
announced in the forwarded e-mail.

Cheers,
Charles

On 2/17/14, 10:12 AM, "Charles Eckel (eckelcu)" <[email-masked]> wrote:

>AEON list members and other interested parties,
>
>We plan to reserve an IESG breakout room to have an AEON meeting at IETF
>89 in London.
>Please indicate which of the potential time slots work for you no later
>than Wednesday, Feb 19.
>All time slots are 1 hour in duration.
>The actual location and time will be announced on the AEON list.
>
>
>Preliminary agenda is as follows:
>1) problem statement draft
>2) draft charter
>
>The agenda will be finalized via a separate thread on the AEON list as
>well.
>Here is the link to the poll:
>http://www.doodle.com/fb8k5hyqap4iqyye
>
>
>Cheers,
>Charles
>
>_______________________________________________
>Aeon mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/aeon

---

From: "Yuchi Chen" <[email-masked]>
Date: Tue, 18 Feb 2014 12:39:34 +0800

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-masked]" <[email-masked]> 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-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: [email-masked]
Date: Tue, 18 Feb 2014 15:15:55 +0800

Hi,yuchi,

  PLS see inline.

Thanks,
Wei

"Yuchi Chen" <[email-masked]> 2014-02-18 12:39:34:

> [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 
> 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.
> 
> [yuchi] Yes, switch should forward the inital packet of each of 
> unknown flows to controller. I agree that 
> 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...

> [yuchi] The logging of a switch can be done by its associated 
> controller. The controller is responsible for 

[Wei]If so, does a switch need to send its NAT44 sessions(or flow tables) 
to
the controller?

---

From: "Yuchi Chen" <[email-masked]>
Date: Tue, 18 Feb 2014 16:46:37 +0800

Hi Wei,

Please see inline.

Best regards!
--------------
Yuchi Chen

>  i.e. reasonable number of controllers in network...

[yuchi] Yes, thanks for your suggestion. The scenario of using several controller
is mentioned (e.g., "Controller can be a single device or a cluster of devices" in 
Bullet 3 of Terminology Section). I think this scenario can be discussed in more 
detail in the text. 

>[Wei]If so, does a switch need to send its NAT44 sessions(or flow tables) 

[yuchi] NAT44 process can be interpreted into actions and recorded in the flow table. Hence 
I think switch does not have to maintain NAT44 session state (if this is what you mean). 

On the other hand, controller can establish related states according to the inital packet of each flow, 
which is what switch needs to send to controller. If controller needs the information of the flow table 
maintained by switch, it can ask switch to send that. Hence switch is not required to send its flow table 
to controller by default.

---

From: [email-masked]
Date: Tue, 18 Feb 2014 17:15:52 +0800

Hi Yuchui，

  PLS see inline.

Thanks，
Wei

> Best regards!

[Wei] Got it. This interpreting is what controllers need to do. To
avoid confusion, I propose this process and the relationship of 
status(session) & "flow table" need further explanation in this draft, 
if needed.

---

From: "Yuchi Chen" <[email-masked]>
Date: Tue, 18 Feb 2014 17:24:05 +0800

Hi Wei,

>status(session) & "flow table" need further explanation in this draft, 

Sure, we'll clarify this as well as other points you suggested in the text. Thanks for the comments!

Best regards!
--------------
Yuchi Chen

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Feb 2014 08:32:07 +1300

On 18/02/2014 20:15, [email-masked] wrote:
...
> "Yuchi Chen" <[email-masked]> 2014-02-18 12:39:34:
...
>> concurrently passing through switch. 

That sounds like an ideal and simple target for a DDOS attack.

   Brian

---

From: "Yuchi Chen" <[email-masked]>
Date: Wed, 19 Feb 2014 15:32:37 +0800

Hi Brian,

Thank you for raising up this point. IMHO some existing monitoring or filtering approaches should be adopted to prevent against these attacks. We will include these considerations in the next version.

In general, I believe that this work will be of benefits, though it still needs to be improved. It will be greatly appreciated if we can receive more comments from the WG. 

Best regards!

Yuchi Chen

From: Brian E Carpenter
Date: 2014-02-19 03:32
To: meng.wei2
CC: chenycmx; [email-masked]
Subject: Re: [Int-area] [intarea]Comments on draft-cui-intarea-unified-v6-framework-00
On 18/02/2014 20:15, [email-masked] wrote:
...
...

   Brian