Re: [Apn] Further revised draft Charter

[Adrian Farrel <[e-mail]>]

Yeah, thanks Mirja.

It's good to draw out the two extremes.

On the one hand, using an existing field (or a combination of existing fields) is attractive because it doesn't require any changes to the encoding. But it has two draw-backs:
1. How well would we interact with existing implementations that already use those fields?
2. Can we manage to squeeze the desired information into those fields?

On the other hand, a new *tunnel* encapsulation tends to imply and end-to-end or edge-to-edge solution (a bit like NSH) without making information available to "regular" IP routers on the path. Now, there is the possibility of a new hop-by-hop encapsulation (such as GTP or Ethernet) that is sub-IP but carries the information. The trouble with that is that the information gets lost when you traverse a link that doesn't support the encoding.

We could, I think, spend quite a lot of time debating possible approaches, pros and cons, and the architectural implications. My reading of the proposed charter is to create a space to do exactly that. The charter text that Donald just circulated seems to imply that if the WG discovers that existing mechanisms or fields do the job, then that would be fine. I suppose it would also be fine if the WG discovered that the use cases don't justify further work, or that the architecture implied that a sub-IP solution would work.

Cheers,
Adrian

-----Original Message-----
From: Mirja Kuehlewind <[e-mail]> 
Sent: 20 January 2023 12:58
To: Adrian Farrel <[e-mail]>
Cc: Feng Yang <[e-mail]>; [e-mail]
Subject: Re: [Apn] Further revised draft Charter

Hi Adrian,

Thanks for the further explanation. Right, NSH also impact the IP routing, however, without being an expert, I guess you could just address an explicit egress node. Having such a tunnel where the encapsulation IP header uses the egress address would also be more secure regarding privacy, as the packet could not “escape” the network without being decapsulated.

I guess using a single existing field like DCSP (or maybe also MPLS labels) or having a full-fleshed, generic and extensible tunnel encapsulation are the two extremes. However, it is still not clear to me if something in the middle is needed, how that would look like, or is even really feasible (or would you only get the worse of both worlds, like more complexity but still limited functionality).

Mirja



> On 19. Jan 2023, at 14:27, Adrian Farrel <[e-mail]> wrote:
> 
> 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
> -- 
> Apn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apn