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

[Brian E Carpenter <[e-mail]>]

See in line.

Regards
   Brian Carpenter

On 04-Apr-19 02:13, Pengshuping (Peng Shuping) wrote:
> Dear Brian,
>  
> Thank you for your comments. Please see inline.
>  
> Best regards,
> Shuping
... 
> 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.  

OK, that is what I thought.
   
> 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. 

That is my question. Although the *meaning* of an NSH might be different from the *meaning* of your options, why would we want to use different formats, which leads to more complex code and therefor to more bugs and operational problems?

> 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.

OK, I will look.
  
> 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.

An SRV6 path is an IPv6 path. (A segment routing path might alternatively be an MPLS path, but that is another discussion.) Is there anything that prevents expressing your semantics in SRV6? 
> 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.

OK, but if it really is similar to FAST I suggest a careful discussion with Tom. The IETF doesn't like to standardise two solutions to the same problem. We really need to understand if there is a requirement for multiple solutions.

> 
> 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)
> 
>  
>