Re: [Apn] Further revised draft Charter

[Adrian Farrel <[e-mail]>]

You can do a lot with the NSH because it is a layer 3.5 encapsulation. But that comes at a price because the packet has to be built as IP to the next service function forwarder, NSH, original IP payload.

 

The NSH basically allows you to put quasi-arbitrary meta data with a packet, so it is not totally free to implement in hardware.

 

I'd say there are plus and minus points and it is worth looking at the benefits of a simple approach.

 

It may be worth asking why SFC deployments eschew the NSH in favour of MPLS, SRv6, or native IP in IP approaches.

 

Cheers,

Adrian

 

 

On 19/01/2023 14:14 CET Mirja Kuehlewind <[e-mail]> wrote:

 

 

Hi Feng,

 

My understanding is that NSH provides such a clean and generic solution. What is missing?

 

Mirja

 

 

 

On 19. Jan 2023, at 13:38, Feng Yang <[e-mail]> wrote:

Hi Mirja,

 

Thanks for your suggestion.  

 

We have associated quite a lot information on the source IP, for example, location/address/user/services(mainly for user who paid will get better bandwidth resource gareentee), etc. Maybe there would be more in future. So I feel to reuse some existing field will create a more “discreted space” , thus even harder to handle.  

 

If there is a clean, generic mechanism, that will great simplify the solution and give more possbility on the service we can define.

 

BR，

 

杨锋

Feng Yang

 

发件人: Apn [mailto:[e-mail]] 代表 Mirja Kuehlewind

发送时间: 2023年1月19日 00:37

收件人: Feng Yang

抄送: [e-mail]

主题: Re: [Apn] Further revised draft Charter

 

Hi Feng,

 

Why are not just using the DSCP field or, if you need to provide more information to the network nodes, Network Service Header (NSH) encapsulation?

 

 

Mirja

 

 

 

 

 

 

On 18. Jan 2023, at 12:53, Feng Yang <[e-mail]> wrote:

 

Dear WG,

 

In the operator's network, we provide corresponding services for Internet services and bussiness services to meet the needs of a group of users with the same service requirements for the network, such as acceleration, and security for Internet services (e.g. SAVNet), and leased line for bussiness services,(e.g. slicing and service chaining).

 

Currently, we are distinguishing services by source IP address at our network edge devices. But the source addresses are discrete, we hope there is a way to transform the address from discrete space into a linear space , which will make it be easier for classification, so that the services and policies can be combined in a simple way. Eventually that can improve our efficiency and reduce costs. 

 

This actually solves the fundamental problem that ACLs are difficult to apply at scale, and facilitates us to aggregate services in a linear space and statically configure a number of matching conditions by means of planning.

 

I think this Charter clearly presents the work we would like to see, so I suggest it is best not to postpone APN Charter any longer, we should setup the WG first and discuss the actual work as soon as possible.

 

The Spring festival is coming on this weekend. Best wishes for everyone. J

 

BR，

 

杨锋

Feng Yang

 

发件人: Apn [mailto:[e-mail]] 代表 Donald Eastlake

发送时间: 2023年1月18日 10:04

收件人: [e-mail]

抄送: [e-mail]

主题: [Apn] Further revised draft Charter

 

I've gotten some comments and I've re-read some of the AD DISCUSSES and comments. Based on that I've updated the draft Charter as attached. Comments are welcome. 

 

Thanks,

Donald

===============================

 Donald E. Eastlake 3rd [phone] (cell)

 2386 Panoramic Circle, Apopka, FL 32703 USA

 [e-mail]

-- 

Apn mailing list

[e-mail]

https://www.ietf.org/mailman/listinfo/apn

--

Apn mailing list

[e-mail]

https://www.ietf.org/mailman/listinfo/apn