Re: Regarding draft-li-6man-service-aware-ipv6-network-00

["Pengshuping (Peng Shuping)" <[e-mail]>]

Dear Brian,



Thank you for your comments. Please see inline.



Best regards,

Shuping





Date: Sun, 31 Mar 2019 10:13:34 +1300

From: Brian E Carpenter <[e-mail]<mailto:[e-mail]>>

To: Lizhenbin <[e-mail]<mailto:[e-mail]>>

Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>

Subject: Re: Regarding draft-li-6man-service-aware-ipv6-network-00

Message-ID: <[e-mail]<mailto:[e-mail]>>

Content-Type: text/plain; charset=utf-8



Hi Zhenbin,



Thanks for your draft. I have a few general questions:



1. As you may know, it's been impossible to deploy new IPv4 options for operational reasons, and also very difficult to deploy new IPv6 extension headers or options. So my first question about your proposal is: what is the intended scope? Do you expect such options to be deployed locally or over the open Internet? (For some background on this question, see https://tools.ietf.org/html/draft-carpenter-limited-domains)



[SP] Thank you for the draft. It could first start with a limited domain, such as the 5G mobile backhaul and metro network, supporting MBB and FBB services.



2. How does this proposal relate to the existing standard for network service headers (https://tools.ietf.org/html/rfc8300)?



[SP] The service-aware options are defined in the draft. Actually NSH could be also taken as a kind of service-aware option. But it is better to separate from this case. The NSH service option is defined in another draft of us. https://tools.ietf.org/html/draft-li-6man-ipv6-sfc-ifit-00 Looking forwards to your comments.



3. How does ths proposal relate to the existing standard for segment routing (https://tools.ietf.org/html/rfc8402) and the segment routing header (https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header)?



[SP] We differentiate the paths as IPv6 paths and SRv6 paths. For an IPv6 path, i.e. all the nodes along the path are IPv6 enabled, we recommend to place the service-aware options in the IPv6 EX header, HBH option in particular, while for an SRv6 path, we recommend to place in the SID and/or in the SRH TLV.



4. How does this proposal relate to FAST tickets (https://tools.ietf.org/html/draft-herbert-fast-03)?



[SP] Agree with Tom that in terms of carrying information along with the packets the two proposals look similar. In this service-aware IPv6 draft https://tools.ietf.org/html/draft-li-6man-service-aware-ipv6-network-00

application/service related information is carried with the packets, with which the network is able to manage the traffic in a finer granularity. It could be applied to a limited domain as stated in the reply to your first comment. The application/service related information could be added at the edge devices of the network which are still in the control of the network operators. Therefore, the security are under control and can be managed.





Regards

   Brian Carpenter





On 19-Mar-19 06:12, Lizhenbin wrote:

> Hi Folks,

> Currently applications are developed very fast which are carried over

> the network and have varying needs for network bandwidth, latency,

> jitter, and packet loss, etc. However, since the current network is

> lack of enough information of service requirements of such

> applications it is difficult to guarantee the SLA or it may take long

> time to provide such guarantee.  In order to solve these these

> challenges, the draft proposes the solution to take use of IPv6

> extensions header to convey the service requirement information along

> with the packet to the network and accordingly the flow-driven method

> is adopted to facilitate the service deployment and network resource adjustment to guarantee SLA for applications. It defines the Service-aware IPv6 ID to identify the possible service/application/user and Service-Para Option is defined to convey the related service parameters.

>

> Comments and suggestions are welcome!

>

>

> Best Regards,

> Zhenbin (Robin)