Subject: [Lsr] Discussion on draft-wang-lsr-hbh-process-00

From: wangyali <[email-masked]>
Date: Tue, 17 Nov 2020 12:11:16 +0000

Hi all,

Many thanks for these value questions and comments from Chris, Ron, Acee in the LSR 109 session. I summarize them as follows, and supplement my answer. Waiting forwards to further discussion with WG.

Q1: are you using this information to determine the routing to the network? 
On one hand, such advertisement does not effect on the normal SPF computation and may be useful for traffic engineering. For example, for IOAM service, if the HbH Processing Action of Node/Link is assigned to a slow processing plane, the Node or Link should be excluded for path computation. If the HbH Processing Action of Node/Link is ignore all extension Options header, the Node/Link can be used as the normal IPv6 transit node/link. If the HbH Processing Action of Node/Link is skip to Next extension Options header (e.g. Routing Header), the Node/Link can be considered as Endpoints in SRv6 routing. On the other hand, such advertisement is useful for entities to determine specific services encoded in HbH options header can be deployed in a given path.

Q2: can you use the link color to compute paths?
In the above, I answered, taking advantage of this advertisement, the exact action taken by Node or Link to process HbH options header can be determined (defined in Action Flag field), which can be useful for traffic engineering. Hence, such advertisement is not only used to determine whether the HbH options header supported by Node/Link or not. But the link color cannot exactly indicate the exact action.

More questions and comments are welcome.

Thanks,
Yali

-----Original Message-----
From: wangyali [mailto:[email-masked]] 
Sent: Thursday, October 29, 2020 9:20 PM
To: [email-masked]
Subject: [Lsr] New Version for draft-wang-lsr-hbh-process-00

Hello WG,

Considering the Hop-by-Hop Options header has been used for IOAM [I-D.ietf-ippm-ioam-ipv6-options], Alternate Marking method [I-D.ietf-6man-ipv6-alt-mark], etc., but as specified in RFC8200, the Hop-by-Hop Options header is only examined and processed if it is explicitly configured. In this case, nodes may be configured to ignore the Hop-by-Hop Options header, drop packets containing a Hop-by-Hop Options header, or assign packets containing a Hop-by-Hop Options header to a slow processing path. Thus, the performance measurement does not account for all links and nodes along a path. In addition, packets carrying a Hop-by-Hop Options header may be dropped, which gravely deteriorates network performance.

Therefore, we propose a new draft about IGP extensions for signaling Hop-by-Hop Options header processing action at node and link granularity. Such advertisement is useful for entities (e.g., the centralized controller) to gather each router's processing action for achieving the computation of TE paths that be able to support a specific service encoded in the Hop-by-Hop Options header. 

Please let us know your opinion. Questions and comments are very welcome.

Best regards,
Yali

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 29, 2020 8:42 PM
To: Tianran Zhou <[email-masked]>; Huzhibo <[email-masked]>; wangyali <[email-masked]>
Subject: New Version Notification for draft-wang-lsr-hbh-process-00.txt

A new version of I-D, draft-wang-lsr-hbh-process-00.txt has been successfully submitted by Yali Wang and posted to the IETF repository.

Name:		draft-wang-lsr-hbh-process
Revision:	00
Title:		IGP Extensions for Advertising Hop-by-Hop Options Header Processing Action
Document date:	2020-10-29
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/archive/id/draft-wang-lsr-hbh-process-00.txt
Status:         https://datatracker.ietf.org/doc/draft-wang-lsr-hbh-process/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-wang-lsr-hbh-process
Htmlized:       https://tools.ietf.org/html/draft-wang-lsr-hbh-process-00

Abstract:
   This document extends Node and Link attribute TLVs to Interior
   Gateway Protocols (IGP) to advertise the Hop-by-Hop Options header
   processing action and supported services (e.g.  IOAM Trace Option and
   Alternate Marking) at node and link granularity.  Such advertisements
   allow entities (e.g., centralized controllers) to determine whether
   the Hop-by-Hop Options header and specific services can be supported
   in a given network.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Tony Li <[email-masked]>
Date: Tue, 17 Nov 2020 09:40:51 -0800

> In the above, I answered, taking advantage of this advertisement, the exact action taken by Node or Link to process HbH options header can be determined (defined in Action Flag field), which can be…

This suggests that you’re missing one bit of information.  Thus, could you use two link colors to differentiate between the two?

Tony

---

From: wangyali <[email-masked]>
Date: Wed, 18 Nov 2020 02:41:38 +0000

Hi Tony,

Thanks for your question. Please see in line [Yali]. 
Please let me know your opinions.

Best,
Yali

-----Original Message-----
From: Tony Li [mailto:[email-masked]] 
Sent: Wednesday, November 18, 2020 1:41 AM
To: wangyali <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] Discussion on draft-wang-lsr-hbh-process-00

This suggests that you’re missing one bit of information.  Thus, could you use two link colors to differentiate between the two?
[Yali] I am not clear what does the "... to differentiate between the two" mean? Please let me know if I'm missing something. 

[Yali] While please let me clarify what does the "Processing Action" include in this draft. The "Processing Action" indicates the various of configurable processing behavior for Hop-by-Hop Options header, which are specified in RFC8200. The "Processing Action" includes ignore the Hop-by-Hop Options header, skip to the next extension header, drop packets containing a Hop-by-Hop Options header, or assign packets to a slow processing path. Besides, the "Service Flag" is also defined in this draft used to indicate which service/function Options supported by Node/Link.

[Yali] Hence, "two link colors" cannot differentiate the above vary combinations of "Processing Action Flag" and "Service Flag". Moreover, "Link Color" can only indicate whether or not include or exclude the Link for Traffic Engineering. But our use cases mentioned in Q1 is not so simple.

Tony