Subject: Next steps with draft-dong-6man-enhanced-vpn-vtn-id

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 5 Aug 2021 01:56:47 +0000

Hi WG,

In last week's IETF 111 meeting, we presented the update of draft-dong-6man-enhanced-vpn-vtn-id. Due to limited meeting time, we didn't have chance for comments and discussion.

As mentioned in the presentation, this version solves the comments received both in previous IETF meetings and on the mail list. Further review and comments are appreciated.

The authors believe this document is in the right direction of using HBH for per-hop forwarding treatment with a specific set of resources, and the content has become stable. Thus we would like to request for WG adoption of this document, thanks.

Best regards,
Jie

---

From: Chongfeng Xie <[email-masked]>
Date: Tue, 10 Aug 2021 14:06:41 +0800

Hi， folks, 
 
I think the extension to HBH header in this document is valuable.  It aligns with the HBH header processing, and provide an approach to efficiently identify the resources used for packet forwarding. This mechanism will be useful in IPv6 networks where a large number of network slices will be deployed.

Chongfeng 

> 2021年8月5日 上午9:56，Dongjie (Jimmy) <[email-masked]> 写道：
> 
> Hi WG, 
>  
> In last week’s IETF 111 meeting, we presented the update of draft-dong-6man-enhanced-vpn-vtn-id. Due to limited meeting time, we didn’t have chance for comments and discussion.
>  
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked] <mailto:[email-masked]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> --------------------------------------------------------------------

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 10 Aug 2021 16:38:38 +0000

Hi all,
Slicing is something fundamental/low_level. Slice ID should not be buried deep into the label or SID stack like VPN is.
HbH is the proper place for it. Hence, support for this draft.
Eduard
From: ipv6 [mailto:[email-masked]] On Behalf Of Chongfeng Xie
Sent: Tuesday, August 10, 2021 9:07 AM
To: Dongjie (Jimmy) <[email-masked]>
Cc: 6MAN <[email-masked]>; 6man Chairs <[email-masked]>
Subject: Re: Next steps with draft-dong-6man-enhanced-vpn-vtn-id

Hi， folks,

Chongfeng

2021年8月5日 上午9:56，Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>> 写道：

Hi WG,

Best regards,
Jie
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Aug 2021 13:05:21 -0400

I have to disagree.  Slicing is not particularly fundamental.
Resource allocation (including queueing) and packet forwarding are low 
level constructs.
Slicing is a way of talking about using those and other tools to deliver 
an externally understandable set of behaviors.
An easily accessible identifier in the packet is useful for actual low 
level operations.   But we have those.  I have not yet seen any 
explanation of why we need an explicit identifier associated with the 
end-to-end slice in an easily accessible portion of the packet.

Many iterations of trying to do fine grained control in the middle of 
the network teach us that what we need in the middle is aggregated / 
aggregatable state that can be used to deliver the needed behaviors. 
MPLS labels, DSCP code points, and similar tools give us that.

Yours,
Joel

On 8/10/2021 12:38 PM, Vasilenko Eduard wrote:
> Hi all,
> 
> Slicing is something fundamental/low_level. Slice ID should not be 
> buried deep into the label or SID stack like VPN is.
> 
> *From:*ipv6 [mailto:[email-masked]] *On Behalf Of *Chongfeng Xie
> *Sent:* Tuesday, August 10, 2021 9:07 AM
> *To:* Dongjie (Jimmy) <[email-masked]>
> *Cc:* 6MAN <[email-masked]>; 6man Chairs <[email-masked]>
> *Subject:* Re: Next steps with draft-dong-6man-enhanced-vpn-vtn-id
> 
> Hi，folks,
> 
> I think the extension to HBH header in this document is valuable.  It 
> aligns with the HBH header processing, and provide an approach to 
> efficiently identify the resources used for packet forwarding. This 
> mechanism will be useful in IPv6 networks where a large number of 
> network slices will be deployed.
> 
> Chongfeng
> 
>     In last week’s IETF 111 meeting, we presented the update of
>     draft-dong-6man-enhanced-vpn-vtn-id. Due to limited meeting time, we
>     didn’t have chance for comments and discussion.
> 
>     As mentioned in the presentation, this version solves the comments
>     received both in previous IETF meetings and on the mail list.
>     Further review and comments are appreciated.
> 
>     The authors believe this document is in the right direction of using
>     HBH for per-hop forwarding treatment with a specific set of
>     resources, and the content has become stable. Thus we would like to
>     request for WG adoption of this document, thanks.
> 
>     Best regards,
> 
>     Jie
> 
>     Administrative Requests:https://www.ietf.org/mailman/listinfo/ipv6
>     <https://www.ietf.org/mailman/listinfo/ipv6>
> [email-masked]

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 10 Aug 2021 14:42:07 -0400

I support WG adoption of this draft as it is a critical component of 5G
network slice provisioning of VPN+  Enhanced VPN coupling of VPN overlay
resources to underlay Virtual Transport Network(VTN) resource reservation
underpinning.

As VPN+ sits in the overlay, it’s the VPN+ Overlay underpinnings to the now
virtualization of the transport underlay mapping and resources provisioning
of the E2E underlay hop by hop resources, is what the VTN ID provides,
which is a critical component of the overall Enhanced VPN framework
architecture of network slice (NS) provisioning process by the NS
controller which utilizes the S-NSSAI slice differentiator now encoded into
the HBH VTN ID per this draft.

https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn/

https://datatracker.ietf.org/doc/draft-drake-bess-enhanced-vpn/

Kind Regards

Gyan

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 11 Aug 2021 03:55:18 +0000

Hi Joel,

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Wednesday, August 11, 2021 1:05 AM
> To: Vasilenko Eduard <[email-masked]>; Chongfeng Xie
> <[email-masked]>; Dongjie (Jimmy) <[email-masked]>
> Cc: 6MAN <[email-masked]>
> Resource allocation (including queueing) and packet forwarding are low level
> constructs.
> Slicing is a way of talking about using those and other tools to deliver an
> externally understandable set of behaviors.

Yes, resource allocation in the lower layer is needed, and in data packet there needs to be some field to identify the resources allocated for the processing of packets belonging to the same VTN.

> Many iterations of trying to do fine grained control in the middle of the network
> teach us that what we need in the middle is aggregated / aggregatable state
> that can be used to deliver the needed behaviors.

Please refer to the slides of my presentation in the 6man session of IETF 111. There is analysis about the candidate fields in IPv6 packet which may be used for this, and the result shows the existing fields either have been used for other purposes, or have scalability issues. Thus a new Hop-by-Hop option dedicated for this purpose is reasonable:

https://datatracker.ietf.org/meeting/111/materials/slides-111-6man-carrying-vtn-id-in-ipv6-extension-header-00

Best regards,
Jie

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 11 Aug 2021 07:49:45 +0100

I think this discussion shows that using IP as a VTN Is probably a mistake, and that it is time to think about a protocol better suited to the task.

Given that every hop has to support the new feature for it to fully work, and thus needs to be upgraded, it is a short step to introduce a less compromised protocol to provide the required feature.

Stewart

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 11 Aug 2021 12:01:51 +0000

Hi Stewart,

Not quite sure I got your point here. 

Do you mean using IP address as the VTN-ID is probably a mistake, or VTN may be better implemented using a protocol other than IP? The former was analyzed in my presentation slides on IETF 111, while the latter seems out of the scope of this WG (6man). 

As we know, VTN can be implemented based on either IPv6 data plane or MPLS data plane. This document proposes the mechanism to carry VTN-ID in IPv6 packet header. The operational considerations section also describes the cases where some nodes do not recognize the HBH header or the VTN option.

Within the scope of IPv6 data plane, do you think the extension to HBH is a reasonable approach?

Best regards,
Jie

> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Wednesday, August 11, 2021 2:50 PM
> Cc: Joel M. Halpern <[email-masked]>; Vasilenko Eduard
> <[email-masked]>; Chongfeng Xie <[email-masked]>;
> 6MAN <[email-masked]>
> I think this discussion shows that using IP as a VTN Is probably a mistake, and
> that it is time to think about a protocol better suited to the task.
> 
> 
> Given that every hop has to support the new feature for it to fully work, and
> thus needs to be upgraded, it is a short step to introduce a less compromised
> protocol to provide the required feature.
> 
> Stewart

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 11 Aug 2021 08:15:03 -0400

While I do not speak for Stewart, I can make an observation that struck 
me reading Stewart's question.

We already have MPLS label stacks, SRH SID lists, and an experimental 
code point for CRH SID lists to describe paths.  Within MPLS we even 
have the path segment work to provide a management identifier for the 
path.  We also have the NSH header for steering traffic with service 
metadata.

Given all those tools, why do we need yet another identifier.  Much less 
a new single, limited identifier to identify a path?

Yes, your presentation claimed that the existing solutions would not 
work.  I did not find your slide presentation particularly persuasive in 
this regard.

Yours,
Joel

---

From: <[email-masked]>
Date: Thu, 12 Aug 2021 10:27:18 +0800 (CST)

Hi Jie,

thank you for providing the reference to the presentation. I've got a question about slide 3, particularly the analysis of using the Flow Label as VTN ID. Looking at the draft, I couldn't find such an analysis. Have I missed it? I've asked a similar question at APN BoF and will repeat myself here. Why NOT use the Flow Label? I've read RFC 6437, and I cannot find that it limits the applicability of the Flow Label (e.g., load balancing over a multi-path). Hence my question is, Why not the Flow Label as the VTN ID? With a centralized controller assigning VTN ID values, 20 bits may go a long way.

What do you think?

Regards,

Greg Mirsky

Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division

E: [email-masked] 
www.zte.com.cn

Original Mail

Sender: Dongjie(Jimmy)
To: Joel M. Halpern;Vasilenko Eduard;Chongfeng Xie;
CC: 6MAN <[email-masked]>;
Date: 2021/08/10 20:56
Subject: RE: Next steps with draft-dong-6man-enhanced-vpn-vtn-id

Hi Joel,

 

 
Best regards,
Jie

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 12 Aug 2021 00:10:02 -0400

Hi Greg

I can try to help answer this question asked during the APN BOF and as well
is related to the question related to use of flow label in this case for
VTN ID.

As for APN ID we are investigating possibilities and studying how it would
be possible to use the flow label to carry the APN ID.  However based on my
detailed analysis it is not possible.  Reasons why are below.

So with RFC 6437 there at two possible use cases for the APN ID one for
stateless use case for uniform ECMP load balancing and tbr second use case
for stateful use case for edge marking  signaling QOS type marking.  Both
the stateless and the stateful must confirm to section 3 as stated below
and must follow the per packet 5-tuple header key hash to generate the 20
bit flow label key input to local hash function for ECMP uniform 50/50 load
balancing.

4 <https://datatracker.ietf.org/doc/html/rfc6437#section-4>.  Flow
State Establishment Requirements

   A node that sets the flow label MAY also take part in a flow state
   establishment method that results in assigning specific treatments to
   specific flows, possibly including signaling.  Any such method MUST
   NOT disturb nodes taking part in the stateless scenario just
   described.  Thus, any node that sets flow label values according to a
   stateful scheme MUST choose labels that conform to Section 3
<https://datatracker.ietf.org/doc/html/rfc6437#section-3> of this
specification.  Further details are not discussed in this document.

Stateless signaling must follow section 3 below as I stated above.

3 <https://datatracker.ietf.org/doc/html/rfc6437#section-3>.  Flow
Labeling Requirements in the Stateless Scenario

   This section defines the minimum requirements for methods of setting
   the flow label value within the stateless scenario of flow label
   usage.

   To enable Flow-Label-based classification, source nodes SHOULD assign
   each unrelated transport connection and application data stream to a
   new flow.  A typical definition of a flow for this purpose is any set
   of packets carrying the same 5-tuple {dest addr, source addr,
   protocol, dest port, source port}.  It should be noted that a source
   node always has convenient and efficient access to this 5-tuple,
   which is not always the case for nodes that subsequently forward the
   packet.

The details of how stateless and stateful will actually work together in
the real world is out of scope of  RFC 6437.

What section 4 is stating is that as the per packet 5-tuple header hash
used to generate the conversation key encoded into the flow label is used
to assign all packets that are part of the same L3/L4 session get hashed to
the same path to prevent out of order packets as well as with the 20 bit
input key hash able to provide more randomization with the 5-tuple to
result in 50/50 uniform ECMP load balancing.

So what section 4 is stating is that same section 3  5-tuple header hash
keys to generate the 20 bit input key is the exact same 5-tuple algorithm
that must be used for stateful signaling if a source or edge node is
performing a marking function similar to QOS edge marking the end result 20
bit key generated for stateful edge marking must be identical to the key
used for stateless uniform ECMP load balancing so the key does not change
and is identical so that the stateful flow label does not overwrite the
stateless key impacting load balancing and possible out of order packet as
a result.

So what I stated above is the reason why APN and VTN cannot use the flow
label as the APN and VTN of have their own fields where APN has its opaque
fields and VTN has its S-NSAAI identifier for network slice selection and
thus the APN and VTN ID which does not follow the RFC 6437 per packet
5-tuple header key hash algorithm  used for stateless uniform load
balancing.

RFC 6436 describes the use cases in detail that it’s forbidden to use any
stateful signaling a would be done with APN ID or VTN ID that could impact
uniform load balancing.

Note that all modern routers for many years now support and operators rely
on RFC 6437 stateless uniform load balancing.

So we have to ensure that any new design to use any stateful signaling
mechanisms must not impact stateless uniform load balancing used by
operators today.

Excerpt from RFC 6436 that described the updates to RFC 6437 for use as
default standard for stateless uniform load balancing:

Bottom of section 3 changes to specification

A complication that led to much discussion is the possibility that
   hosts inside a particular network domain might use a stateful method
   of setting the flow label, and that packets bearing stateful labels
   might then erroneously escape the domain and be received by nodes
   performing stateless processing, such as load balancing.  This might
   result in undesirable operational implications (e.g., congestion,
   reordering) for not only the inappropriately flow-labeled packets,
   but also well-behaved flow-labeled packets, during forwarding at
   various intermediate devices.  It was suggested that border routers
   might "correct" this problem by overwriting such labels in packets
   leaving the domain.  However, neither domain border egress routers
   nor intermediate routers/devices (using a flow label, for example, as
   a part of an input key for a load-distribution hash) can determine by
   inspection that a value is not part of a uniform distribution.  Thus,
   there is no way that such values can be detected and "corrected".
   Therefore, the recommendation to choose flow labels from a uniform
   distribution also applies to stateful schemes.

4 <https://datatracker.ietf.org/doc/html/rfc6436#section-4>.  Discussion

   The following are some practical consequences of the above changes:

   o  Sending hosts that are not updated will in practice continue to
      send all-zero labels.  If there is no label-setting router along
      the path taken by a packet, the label will be delivered as zero.

   o  Sending hosts conforming to the new specification will by default
      choose uniformly distributed labels between 1 and 0xFFFFF.

   o  Sending hosts may continue to send all-zero labels, in which case
      an ingress router may set uniformly distributed labels between 1
      and 0xFFFFF.

   o  The flow label is no longer unrealistically asserted to be
      strictly immutable; it is recognized that it may, incorrectly, be
      changed en route.  In some circumstances, this will break end-to-
      end usage, e.g., potential detection of third-party spoofing
      attacks [LABEL-SEC
<https://datatracker.ietf.org/doc/html/rfc6436#ref-LABEL-SEC>].

   o  The expected default usage of the flow label is some form of
      stateless load distribution, such as the ECMP/LAG usage defined in
      [RFC6438 <https://datatracker.ietf.org/doc/html/rfc6438>].———->
***States uniform load balancing is the default use of flow label****

   o  If the new rules are followed, all IPv6 traffic flows on the
      Internet should have zero or uniformly distributed flow label
      values.

   From an operational viewpoint, existing IPv6 hosts that set a default
   (zero) flow label value and ignore the flow label on receipt will be
   unaffected by implementations of the new specification.  In general,
   it is assumed that hosts will ignore the value of the flow label on
   receipt; it cannot be relied on as an end-to-end signal.  However,
   this doesn't apply if a cryptographically generated label is being
   used to detect attackers [LABEL-SEC
<https://datatracker.ietf.org/doc/html/rfc6436#ref-LABEL-SEC>].

   Similarly, routers that ignore the flow label will be unaffected by
   implementations of the specification.

Hope that helps.

Kind Regards

Gyan

On Wed, Aug 11, 2021 at 10:28 PM <[email-masked]> wrote:

> Hi Jie,
>
> thank you for providing the reference to the presentation. I've got a
> question about slide 3, particularly the analysis of using the Flow Label
> as VTN ID. Looking at the draft
> <https://datatracker.ietf.org/doc/draft-dong-6man-enhanced-vpn-vtn-id/>,
> I couldn't find such an analysis. Have I missed it? I've asked a similar
> question at APN BoF and will repeat myself here. Why NOT use the Flow
> Label? I've read RFC 6437 <https://datatracker.ietf.org/doc/html/rfc6437>,
> and I cannot find that it limits the applicability of the Flow Label (e.g.,
> load balancing over a multi-path). Hence my question is, Why not the Flow
> Label as the VTN ID? With a centralized controller assigning VTN ID values,
> 20 bits may go a long way.
>
> What do you think?
>
>
>
> Regards,
>
> Greg Mirsky
>
>
> 预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D
> Institute/Wireline Product Operation Division
>
>
>
> *Sender: *Dongjie(Jimmy)
> *To: *Joel M. Halpern;Vasilenko Eduard;Chongfeng Xie;
> *CC: *6MAN <[email-masked]>;
> *Date: *2021/08/10 20:56
> *Subject: **RE: Next steps with draft-dong-6man-enhanced-vpn-vtn-id*
> Hi Joel,
>
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 12 Aug 2021 00:14:38 -0400

Hi Greg

Very sorry, I have a slight typo in the 3rd paragraph rewritten below:

So with RFC 6437 there at two possible use cases for the flow label below:

first - stateless use case for uniform ECMP load balancing and second -
stateful use case for edge marking  signaling QOS style marking.

On Thu, Aug 12, 2021 at 12:10 AM Gyan Mishra <[email-masked]> wrote:

>
> Hi Greg
>
> I can try to help answer this question asked during the APN BOF and as
> well is related to the question related to use of flow label in this case
> for VTN ID.
>
> 4 <https://datatracker.ietf.org/doc/html/rfc6437#section-4>.  Flow State Establishment Requirements
>
>    stateful scheme MUST choose labels that conform to Section 3 <https://datatracker.ietf.org/doc/html/rfc6437#section-3> of this specification.  Further details are not discussed in this document.
>
>
> 3 <https://datatracker.ietf.org/doc/html/rfc6437#section-3>.  Flow Labeling Requirements in the Stateless Scenario
>
>       attacks [LABEL-SEC <https://datatracker.ietf.org/doc/html/rfc6436#ref-LABEL-SEC>].
>
>       [RFC6438 <https://datatracker.ietf.org/doc/html/rfc6438>].———-> ***States uniform load balancing is the default use of flow label****
>
>
>    used to detect attackers [LABEL-SEC <https://datatracker.ietf.org/doc/html/rfc6436#ref-LABEL-SEC>].
>
>> > >     Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6

*Gyan Mishra*

*M 301 502-1347*

---

From: <[email-masked]>
Date: Fri, 13 Aug 2021 10:40:25 +0800 (CST)

Hi Gyan,

many thanks for the most detailed response that puts many things in a different perspective (I had not looked at RFC 6436 before your referenced it).

Please find my notes in-lined below under the tag GIM>>.

Best regards,

Greg Mirsky

Original Mail

Sender: GyanMishra
To: gregory mirsky10211915;
CC: [email-masked] <[email-masked]>;[email-masked];
Date: 2021/08/11 21:10
Subject: Re: Next steps with draft-dong-6man-enhanced-vpn-vtn-id

Hi Greg 

I can try to help answer this question asked during the APN BOF and as well is related to the question related to use of flow label in this case for VTN ID.

As for APN ID we are investigating possibilities and studying how it would be possible to use the flow label to carry the APN ID.  However based on my detailed analysis it is not possible.  Reasons why are below.

So with RFC 6437 there at two possible use cases for the APN ID one for stateless use case for uniform ECMP load balancing and tbr second use case for stateful use case for edge marking  signaling QOS type marking.  Both the stateless and the stateful must confirm to section 3 as stated below and must follow the per packet 5-tuple header key hash to generate the 20 bit flow label key input to local hash function for ECMP uniform 50/50 load balancing.

4. Flow State Establishment Requirements A node that sets the flow label MAY also take part in a flow state establishment method that results in assigning specific treatments to specific flows, possibly including signaling. Any such method MUST NOT disturb nodes taking part in the stateless scenario just described. Thus, any node that sets flow label values according to a stateful scheme MUST choose labels that conform to Section 3 of this specification. Further details are not discussed in this document.

GIM>> Indeed, APN ID and VTN ID, in my opinion - examples of stateful use of the Flow Label. I feel we agree on that.

GIM>> I think that "MUST conform to N" is not the same as "MUST follow N". Would you agree?

3. Flow Labeling Requirements in the Stateless Scenario This section defines the minimum requirements for methods of setting the flow label value within the stateless scenario of flow label usage. To enable Flow-Label-based classification, source nodes SHOULD assign each unrelated transport connection and application data stream to a new flow. A typical definition of a flow for this purpose is any set of packets carrying the same 5-tuple {dest addr, source addr, protocol, dest port, source port}. It should be noted that a source node always has convenient and efficient access to this 5-tuple, which is not always the case for nodes that subsequently forward the packet.

The details of how stateless and stateful will actually work together in the real world is out of scope of  RFC 6437.

What section 4 is stating is that as the per packet 5-tuple header hash used to generate the conversation key encoded into the flow label is used to assign all packets that are part of the same L3/L4 session get hashed to the same path to prevent out of order packets as well as with the 20 bit input key hash able to provide more randomization with the 5-tuple to result in 50/50 uniform ECMP load balancing.

GIM>> My interpretation of the quoted text and reference to 5-tuple is that using 5-tuple is not required but recommended as it is characterized as a "typical definition of a flow". If that is the correct interpretation, we may have other ways to define a flow and generate the Flow Label value. 

So what section 4 is stating is that same section 3  5-tuple header hash keys to generate the 20 bit input key is the exact same 5-tuple algorithm that must be used for stateful signaling if a source or edge node is performing a marking function similar to QOS edge marking the end result 20 bit key generated for stateful edge marking must be identical to the key used for stateless uniform ECMP load balancing so the key does not change and is identical so that the stateful flow label does not overwrite the stateless key impacting load balancing and possible out of order packet as a result.

GIM>> As mentioned earlier, I interpret that text as a recommendation, not a requirement.

So what I stated above is the reason why APN and VTN cannot use the flow label as the APN and VTN of have their own fields where APN has its opaque fields and VTN has its S-NSAAI identifier for network slice selection and thus the APN and VTN ID which does not follow the RFC 6437 per packet 5-tuple header key hash algorithm  used for stateless uniform load balancing.

GIM>> I think that we arrive at different conclusions because we have different interpretation of the normative language in Section 3.

RFC 6436 describes the use cases in detail that it’s forbidden to use any stateful signaling a would be done with APN ID or VTN ID that could impact uniform load balancing.

Note that all modern routers for many years now support and operators rely on RFC 6437 stateless uniform load balancing.  

So we have to ensure that any new design to use any stateful signaling mechanisms must not impact stateless uniform load balancing used by operators today.

GIM>> I agree that we must be cautious and not disturb the Internet. On the other hand, we can explore introducing the new interpretation of the Flow Label, perhaps in combination with another field in the IPv6 header.

Excerpt from RFC 6436 that described the updates to RFC 6437 for use as default standard for stateless uniform load balancing:

A complication that led to much discussion is the possibility that hosts inside a particular network domain might use a stateful method of setting the flow label, and that packets bearing stateful labels might then erroneously escape the domain and be received by nodes performing stateless processing, such as load balancing. This might result in undesirable operational implications (e.g., congestion, reordering) for not only the inappropriately flow-labeled packets, but also well-behaved flow-labeled packets, during forwarding at various intermediate devices. It was suggested that border routers might "correct" this problem by overwriting such labels in packets leaving the domain. However, neither domain border egress routers nor intermediate routers/devices (using a flow label, for example, as a part of an input key for a load-distribution hash) can determine by inspection that a value is not part of a uniform distribution. Thus, there is no way that such values can be detected and "corrected". Therefore, the recommendation to choose flow labels from a uniform distribution also applies to stateful schemes.

4. Discussion The following are some practical consequences of the above changes: o Sending hosts that are not updated will in practice continue to send all-zero labels. If there is no label-setting router along the path taken by a packet, the label will be delivered as zero. o Sending hosts conforming to the new specification will by default choose uniformly distributed labels between 1 and 0xFFFFF. o Sending hosts may continue to send all-zero labels, in which case an ingress router may set uniformly distributed labels between 1 and 0xFFFFF. o The flow label is no longer unrealistically asserted to be strictly immutable; it is recognized that it may, incorrectly, be changed en route. In some circumstances, this will break end-to- end usage, e.g., potential detection of third-party spoofing attacks [LABEL-SEC]. o The expected default usage of the flow label is some form of stateless load distribution, such as the ECMP/LAG usage defined in [RFC6438].———-> ***States uniform load balancing is the default use of flow label****

 o If the new rules are followed, all IPv6 traffic flows on the Internet should have zero or uniformly distributed flow label values.
 From an operational viewpoint, existing IPv6 hosts that set a default (zero) flow label value and ignore the flow label on receipt will be unaffected by implementations of the new specification. In general, it is assumed that hosts will ignore the value of the flow label on receipt; it cannot be relied on as an end-to-end signal. However, this doesn't apply if a cryptographically generated label is being used to detect attackers [LABEL-SEC]. Similarly, routers that ignore the flow label will be unaffected by implementations of the specification.

GIM>> If APN and VTN are overlays, then their respective domains provide a certain level of assurance that the stateful use of the Flow Label will not escape its domain.

Hope that helps.

Kind Regards 

Gyan

Hi Jie,

What do you think?

Regards,

Greg Mirsky

Original Mail

Sender: Dongjie(Jimmy)

Hi Joel,

 

 
 
Best regards,
Jie

-- 

Gyan Mishra

Network Solutions Architect 

Email [email-masked]

M 301 502-1347

---

From: Huzhibo <[email-masked]>
Date: Fri, 13 Aug 2021 08:30:22 +0000

Hi Joel:

The approach you mentionded is to carry the VTN ID information in the Segment list. Normally the Segment ID indicates the function to be performed by a specified node. While the VTN ID is used to indicate the forwarding resources used for per-hop forwarding action. 

Further reasons of not using Segment ID to carry the VTN ID information are:

1. If VTN ID information is carried in the segment ID, separate Segment IDs need to be assigned by each node for each VTN. This has limitation in the number of VTNs supported in a network. 

2. Taking SRv6 as an example, if the VTN ID information is carried in the Locator field, it requires independent path computation for each VTN, which has scalability limitation in the control plane. If the VTN ID information is carried in the function field, it requires to use SR-TE policy for each path in the VTN. Therefore, full-mesh SR policies need to be established for each VTN, which will also introduce scalability issues.

3. VTNs may be built in IP networks which does not have to enable segment routing. Thus it is better that VTN-ID is not carried in SRH.

In conclusion, carrying VTN ID in IPv6 HBH meets both the functional requirements and scalability requirements.

Best regards

Zhibo

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, August 11, 2021 8:15 PM
To: Dongjie (Jimmy) <[email-masked]>; Stewart Bryant <[email-masked]>
Cc: 6MAN <[email-masked]>
Subject: Re: Next steps with draft-dong-6man-enhanced-vpn-vtn-id

While I do not speak for Stewart, I can make an observation that struck me reading Stewart's question.

We already have MPLS label stacks, SRH SID lists, and an experimental code point for CRH SID lists to describe paths.  Within MPLS we even have the path segment work to provide a management identifier for the path.  We also have the NSH header for steering traffic with service metadata.

Given all those tools, why do we need yet another identifier.  Much less a new single, limited identifier to identify a path?

Yes, your presentation claimed that the existing solutions would not work.  I did not find your slide presentation particularly persuasive in this regard.

Yours,
Joel

On 8/11/2021 8:01 AM, Dongjie (Jimmy) wrote:
>> <[email-masked]>; Chongfeng Xie 
>> <[email-masked]>; 6MAN <[email-masked]>
>> I think this discussion shows that using IP as a VTN Is probably a 
>> mistake, and that it is time to think about a protocol better suited to the task.
>>
>>
>> Given that every hop has to support the new feature for it to fully 
>> work, and thus needs to be upgraded, it is a short step to introduce 
>> a less compromised protocol to provide the required feature.
>>
>> Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 13 Aug 2021 10:15:53 +0100

Hi Jie

My point is that IPv6 is not well suited to be a transport layer network. I would have thought that considering the suitability of  IPv6 to address the needs of an application was very much in the scope of 6man.

IP was designed as a host to host protocol that expresses to the network where a packet should be sent and with what priority. It has an addressing scheme that is intended to have global scope.

If you consider the design of the protocols that have been successfully deployed in packet transport networks such as MPLS and Ethernet, they tend to be much simpler with just the bare-bones features needed to address the task in hand. They certainly do not have global scoped addresses. Indeed it is very difficult to get a packet outside the intended network scope, or conversely to sneak a packet Into the Transport Network.

My point was that given that every hop has to be upgraded to address the new Hop by Hop header it is actually a small step to introduce a protocol that does the job well, and this is a better approach than to adapt a protocol (IPv6) that is not a good match for the problem. The problem with introducing new protocols to the Internet is huge and that tends to be considered too hard a mountain to climb. However we are not talking about the Internet here, we are talking about a scope that is limited to the switch path for the packed carrying the service that needs this feature. If the feature is needed, then all hops have to support it.

Now as to the identifier you can of course map a VTN-ID to an IP address. You can map anything to an IPv6 address, that is both the blessing and the curse of 128bit addresses. However unless the VTN-ID is expected to be in the DA or SA of an IPv6 packet there is no reason to accept that constraint. Much better to consider the requirements and design an identifier that is a (generalised) best match for the problem.

As to HBH I do not particularly like them, but if there is no alternative then they can obviously be used. The reason that I do not like them is that are not really a full citizen of the packet forwarding architecture*. You have to hunt for them in the packet and they may be a way down the packet possible requiring a forwarder re-cycle. Then there may be multiple HBH requirements in the packet which tends to significant complexity and possible conflict. A good forwarding architecture makes the actions at a hop directly accessible and explicit. That is why actions directly bound to the main forwarding instruction (the packet address, or label) are fundamentally a better design.

Now I do not expect that this argument will carry much weight given the weight of commercial pressures in play, but we should at least make the decision understanding the compromise and possible future implications.

Best regards

Stewart

*They are a candidate for inclusion in MPLS and I have similar reservations in that context.

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 13 Aug 2021 10:33:39 +0100

Setting aside any designs I have proposed, the semantic that best suits a forwarder is:

"Lookup up this identifier in a database and do what the database tells you to do” 

That is how basic IP, SR and MPLS works. It is fast and efficient.

If you outgrow the ability to create a single forwarding identifier then you have to find a way to include additional parameters in the packet, so the semantic becomes:

“Look up this identifier in a database and do what the database tells you do enhanced by this (these) explicit parameter(s) in the packet”

Given that paths are no longer shortest path best effort, particularly in a transport network, I think it is helpful to be more specific about which parameter(s) to apply at which hop.

So I think we need to be working in the direction of associating a set of explicit parameters with a specific hop. A way that I have proposed in other IETF contexts is to use pointers to elements within the packet. This may or may not be the best way, but it is an gedanken existence proof of an explicit rather than sort of implicit parameter mechanism that can be used by a forwarder. I am happy if we can find other suitably powerful methods, but I do think we need to move the forwarding semantic along to better suit these needs.

- Stewart

> On 13 Aug 2021, at 09:30, Huzhibo <[email-masked]> wrote:
> 
> Hi Joel:
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 13 Aug 2021 07:57:38 -0400

Thank you for clarifying that the think you want to identify here has 
the functionality we are discussing in the terminology discussion on the 
TEAS list.  That is, it identifies resources to be used without 
controlling the forwarding path.   We really need to find a new term. 
Fortunately, we are working on that.  (I understand that in the absence 
of a new term, you used the term you had been using.  Understandable.) 
Lets call this a Resource A/P/P (meaning something like an aggregate, 
pool, or partition) for this email.

When used in conjunction with a path specification technology such as 
conventional MPLS or some variety of segment routing, I understand how 
this is to work.  Finding a good encoding is not easy or obvious, but it 
is a problem I agree we will need to solve.

One would hope that any such encoding would work when flex-algo is used 
in conjunction with the path specification technologies, without 
exploding the number of path computations one needs to perform.

All of those cases have the advantage that the path is being controlled, 
and one can reasonable deal with the need to ensure that the Resource 
A/P/P is suitably present and usable at all the nodes / links on the 
path.  Not easy, but again necessary so we can address the needs.

But if we start applying this to conventional IPv6, I have to wonder. 
To identify a Resource A/P/P? in conjunction with an IPv6 packet, we run 
into multiple problems.   We are not in a limited domain, so it is not 
even clear what the scoping would be.  Even if we can scope it to a 
limited domain, we would have to require that ALL nodes in the domain 
support this mechanism (since conceptually IPv6 forwarding can go 
anywhere in the domain.  And for similar reasons, we would seem to need 
to require that the Resource A/P/P/ be present and available at all 
nodes in the domain.  Which seems a non-starter.  To paraphrase Stewart, 
maybe we don't want to solve this part of the problem?

Yours,
Joel

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 13 Aug 2021 21:14:19 -0400

Hi Greg

Many thanks for your insightful response.

Responses in-line

Kind Regards

Gyan

On Thu, Aug 12, 2021 at 10:40 PM <[email-masked]> wrote:

> Hi Gyan,
>
> many thanks for the most detailed response that puts many things in a
> different perspective (I had not looked at RFC 6436 before your referenced
> it).
>
> *Sender: *GyanMishra
> *To: *gregory mirsky10211915;
> *CC: [email-masked] <[email-masked]>;[email-masked];
> *Date: *2021/08/11 21:10
> *Subject: **Re: Next steps with draft-dong-6man-enhanced-vpn-vtn-id*
>
> Hi Greg
>
> 4 <https://datatracker.ietf.org/doc/html/rfc6437#section-4>.  Flow State Establishment Requirements     A node that sets the flow label MAY also take part in a flow state    establishment method that results in assigning specific treatments to    specific flows, possibly including signaling.  Any such method MUST    NOT disturb nodes taking part in the stateless scenario just    described.  Thus, any node that sets flow label values according to a    stateful scheme MUST choose labels that conform to Section 3 <https://datatracker.ietf.org/doc/html/rfc6437#section-3> of this specification.  Further details are not discussed in this document.
>
>
> GIM>> Indeed, APN ID and VTN ID, in my opinion - examples of stateful use
> of the Flow Label. I feel we agree on that.
>
> Gyan> Agreed
>
> 3 <https://datatracker.ietf.org/doc/html/rfc6437#section-3>.  Flow Labeling Requirements in the Stateless Scenario     This section defines the minimum requirements for methods of setting    the flow label value within the stateless scenario of flow label    usage.     To enable Flow-Label-based classification, source nodes SHOULD assign    each unrelated transport connection and application data stream to a    new flow.  A typical definition of a flow for this purpose is any set    of packets carrying the same 5-tuple {dest addr, source addr,    protocol, dest port, source port}.  It should be noted that a source    node always has convenient and efficient access to this 5-tuple,    which is not always the case for nodes that subsequently forward the    packet.
>
>
> GIM>> My interpretation of the quoted text and reference to 5-tuple is
> that using 5-tuple is not required but recommended as it is characterized
> as a "typical definition of a flow". If that is the correct interpretation,
> we may have other ways to define a flow and generate the Flow Label value.
> Gyan> Agreed to your point that the 5-tuple is a recommendation as other
> means maybe possible better algorithms that could be utilized to generate
> the flow label key.  As for RFC 6437 ECMP 50/50 load balancing for mix
> vendor interoperability the algorithm whatever it maybe must be a
> standardized algorithm.
>
> Gyan> Agreed on normative language.   Here  the key point I was trying to
> make is that the flow label algorithm whatever it maybe to generate the
> flow label, the stateful flow label must be the same as stateless flow
> label or the uniform load balancing will be  broken.
>
> GIM>> I think that we arrive at different conclusions because we have
> different interpretation of the normative language in Section 3.
> Gyan>  I think we are on the same page for the normative language as I
> stated above and I completely agree that it 5-tuple could be used or any
> other algorithm that is better to provide uniform load balancing.  So the
> development work  of stateless ECMP and the standardized algorithm used for
> stateless uniform load balancing must be the same algorithm so as long as
> APN and VTN use the same identical algorithm that is used today by vendors
> using RFC 6437 to provide for their customers uniform ECMP 50/50 load
> balancing then VTN and APN can for sure use the flow label.
>

> GIM>> I agree that we must be cautious and not disturb the Internet. On
> the other hand, we can explore introducing the new interpretation of the
> Flow Label, perhaps in combination with another field in the IPv6 header.
>
> Gyan> Agreed.  This maybe a good path for maybe experimental so that we
> don’t disturb existing implementation.
>
> 4 <https://datatracker.ietf.org/doc/html/rfc6436#section-4>.  Discussion     The following are some practical consequences of the above changes:     o  Sending hosts that are not updated will in practice continue to       send all-zero labels.  If there is no label-setting router along       the path taken by a packet, the label will be delivered as zero.     o  Sending hosts conforming to the new specification will by default       choose uniformly distributed labels between 1 and 0xFFFFF.     o  Sending hosts may continue to send all-zero labels, in which case       an ingress router may set uniformly distributed labels between 1       and 0xFFFFF.     o  The flow label is no longer unrealistically asserted to be       strictly immutable; it is recognized that it may, incorrectly, be       changed en route.  In some circumstances, this will break end-to-       end usage, e.g., potential detection of third-party spoofing       attacks [LABEL-SEC <https://datatracker.ietf.org/doc/html/rfc6436#ref-LABEL-SEC>].     o  The expected default usage of the flow label is some form of       stateless load distribution, such as the ECMP/LAG usage defined in       [RFC6438 <https://datatracker.ietf.org/doc/html/rfc6438>].———-> ***States uniform load balancing is the default use of flow label****
>
>
>    From an operational viewpoint, existing IPv6 hosts that set a default    (zero) flow label value and ignore the flow label on receipt will be    unaffected by implementations of the new specification.  In general,    it is assumed that hosts will ignore the value of the flow label on    receipt; it cannot be relied on as an end-to-end signal.  However,    this doesn't apply if a cryptographically generated label is being    used to detect attackers [LABEL-SEC <https://datatracker.ietf.org/doc/html/rfc6436#ref-LABEL-SEC>].     Similarly, routers that ignore the flow label will be unaffected by    implementations of the specification.
>
>
> GIM>> If APN and VTN are overlays, then their respective domains provide a
> certain level of assurance that the stateful use of the Flow Label will not
> escape its domain.
>

  Gyan> Yes both APN and VTN are domain specific so that would ensure it
does not escape the domain. Also to that point from a domain context
perspective each domain can ensure the interoperability of stateful
signaling use with stateless ECMP does not impact intra domain uniform load
balancing as well, and that would provide some viability for use of flow
label for APN and VTN intra domain.

*Gyan Mishra*

*M 301 502-1347*

---

From: Huzhibo <[email-masked]>
Date: Sat, 14 Aug 2021 07:39:25 +0000

Hi Joel:

Yes, the VTN ID carried in IPv6 HBH does not determine the path or topology. In fact, maybe it is better to call it the VTN resource ID, which is independent of the topology or path. While for the VTN concept, we think it is a combination of topology and resource. 
However, the VTN can refer to a Flexalgo to determine its topology, and different VTNs may refer to the same Flexalgo, so that we do not need differfent Flexalgo for each VTN, 
This is the benefit of decoupling VTN's resources attribute from its topology attribute, which is fully described in draft-dong-teas-enhanced-vpn-vtn-scalability. 

With Flexalgo, we could use different IP/SIDs to identify different topologies.Note in IPv6 network, Flexalgo may also be used to limit the topology of the VTN.

Therefore, in addition to the existing IP/SIDs for topology/path identification, we need to introduce an identifier in IPv6 packets to identify the resources allocated to a VTN.

Best regards

Zhibo

-----邮件原件-----
发件人: Joel M. Halpern [mailto:[email-masked]] 
发送时间: 2021年8月13日 19:58
收件人: Huzhibo <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; Stewart Bryant <[email-masked]>
抄送: 6MAN <[email-masked]>
主题: Re: Next steps with draft-dong-6man-enhanced-vpn-vtn-id

Thank you for clarifying that the think you want to identify here has the functionality we are discussing in the terminology discussion on the TEAS list.  That is, it identifies resources to be used without 
controlling the forwarding path.   We really need to find a new term. 
Fortunately, we are working on that.  (I understand that in the absence of a new term, you used the term you had been using.  Understandable.) Lets call this a Resource A/P/P (meaning something like an aggregate, pool, or partition) for this email.

When used in conjunction with a path specification technology such as conventional MPLS or some variety of segment routing, I understand how this is to work.  Finding a good encoding is not easy or obvious, but it is a problem I agree we will need to solve.

One would hope that any such encoding would work when flex-algo is used in conjunction with the path specification technologies, without exploding the number of path computations one needs to perform.

All of those cases have the advantage that the path is being controlled, and one can reasonable deal with the need to ensure that the Resource A/P/P is suitably present and usable at all the nodes / links on the path.  Not easy, but again necessary so we can address the needs.

But if we start applying this to conventional IPv6, I have to wonder. 
To identify a Resource A/P/P? in conjunction with an IPv6 packet, we run 
into multiple problems.   We are not in a limited domain, so it is not 
even clear what the scoping would be.  Even if we can scope it to a limited domain, we would have to require that ALL nodes in the domain support this mechanism (since conceptually IPv6 forwarding can go anywhere in the domain.  And for similar reasons, we would seem to need to require that the Resource A/P/P/ be present and available at all nodes in the domain.  Which seems a non-starter.  To paraphrase Stewart, maybe we don't want to solve this part of the problem?

Yours,
Joel

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 16 Aug 2021 07:12:07 +0000

Hi Greg,

Sorry for the late response, I was following the discussion between you and Gyan.

Yes the analysis about the alternatives was only in the presentation slides, as we want to keep the draft focusing on the HBH based VTN extension and operation. It the WG thinks that analysis helps, it may be added to the draft as an appendix.

I’ve reread the flow label related RFCs, and please see some replies to your comment.

Since you mentioned that “20 bits may go a long way”, I assume you are talking about using the whole 20-bit flow label as the VTN-ID, please correct me if this is not what you proposed.

1.      Flow label is generated by the source or the ingress node to identify a particular flow, while in a VTN there can be multiple flows from different source or ingress nodes, these flows may be assigned with different flow labels by the source or ingress nodes, but they need to be identified as belonging to the same VTN.

2.      VTN-ID is unique within a network domain, while flow label does not have domain uniqueness. As flow label is generated by the source node, it is possible that different source nodes may generate the same flow label for their flows, while these flows may belong to different VTNs.

3.      As defined in RFC 6437, the default mechanism of flow label is the stateless model, and in most implementations flow label has been used for stateless load balancing. VTN requires to maintain per-VTN state in network nodes. Using flow label for VTN may introduce compatibility issue and result in unexpected traffic forwarding behavior.

4.      As mentioned by Gyan, in RFC 6437, it is preferable that the algorithms used for flow label generation approximate to discrete uniform distribution, while the allocation of VTN-ID is management based and does not take this into consideration.

5.      In section 6.2 of RFC 6437, it mentions that “in general, networks SHOULD NOT make resource allocation decisions based on flow labels without some external means of assurance.”

Hope this helps.

Best regards,
Jie

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, August 12, 2021 10:27 AM
To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re:Next steps with draft-dong-6man-enhanced-vpn-vtn-id

Hi Jie,

thank you for providing the reference to the presentation. I've got a question about slide 3, particularly the analysis of using the Flow Label as VTN ID. Looking at the draft<https://datatracker.ietf.org/doc/draft-dong-6man-enhanced-vpn-vtn-id/>, I couldn't find such an analysis. Have I missed it? I've asked a similar question at APN BoF and will repeat myself here. Why NOT use the Flow Label? I've read RFC 6437<https://datatracker.ietf.org/doc/html/rfc6437>, and I cannot find that it limits the applicability of the Flow Label (e.g., load balancing over a multi-path). Hence my question is, Why not the Flow Label as the VTN ID? With a centralized controller assigning VTN ID values, 20 bits may go a long way.

What do you think?

Regards,

Greg Mirsky

E: [email-masked]<mailto:[email-masked]>
www.zte.com.cn<http://www.zte.com.cn/>

Original Mail
Sender: Dongjie(Jimmy)
To: Joel M. Halpern;Vasilenko Eduard;Chongfeng Xie;
CC: 6MAN <[email-masked]<mailto:[email-masked]>>;
Date: 2021/08/10 20:56
Subject: RE: Next steps with draft-dong-6man-enhanced-vpn-vtn-id
Hi Joel,

> To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>; Chongfeng Xie
> <[email-masked]<mailto:[email-masked]>>; Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
> Cc: 6MAN <[email-masked]<mailto:[email-masked]>>

Best regards,
Jie

> > *To:* Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
> > *Cc:* 6MAN <[email-masked]<mailto:[email-masked]>>; 6man Chairs <[email-masked]<mailto:[email-masked]>>
> >     2021年8月5日 上午9:56，Dongjie (Jimmy) <[email-masked]
<mailto:[email-masked]%0b>> >     <mailto:[email-masked]>> 写道：
> >     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

---

From: Ran Pang(联通集团中国联通研究院-本部) <[email-masked]>
Date: Tue, 17 Aug 2021 09:08:19 +0000

Hi all,

It is reasonable to extend IPv6 HBH for per-hop packet forwarding treatment such as network slicing, thus IMO this document is in the right direction. I would like to see this work move forward.

One comment to the authors: in section 2, it may be helpful to clarify that this VTN-ID is the identifier of the set of resources allocated to a VTN.

Best regards,
Pang Ran.

From: Dongjie (Jimmy)<mailto:[email-masked]>
Date: 2021-08-05 09:56
To: 6MAN<mailto:[email-masked]>
CC: 6man Chairs<mailto:[email-masked]>
Subject: Next steps with draft-dong-6man-enhanced-vpn-vtn-id
Hi WG,

Best regards,
Jie
如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 17 Aug 2021 09:42:28 +0000

Hi all,
Theoretically slicing ID is the lower level than DSCP – every PFE should pay attention to it first. Hence, the Slice ID should be in the basic header of IPv6 or IPv4 even before DSCP.
Well, it would be too much to change IP basic header. IMHO: Slicing does not have a big enough business case for such a huge cost.

Slice ID is needed somewhere. We have 2 reasonable options:

1.       Some universal header that is always available. IPv6 HbH for example.

2.       Many different headers for all transport technologies that we have (MPLS, SRv6)
Both options need to upgrade all nodes to support new functionality.
The second option needs more RFCs in different IETF WGs.
The second option needs to upgrade different parts of the microcode, a little more expensive.
The second option (especially in the SRv6 case) could put this information out of the PFE parsing window (the smallest is 128B now).
MPLS and SRv6 stacks do not have a proper place now for such type of information (no static label or SID that should be processed on every hop) – Slicing ID would protrude out of original architecture. HbH header is not available in MPLS or SRv6.
Eduard
From: Dongjie (Jimmy)
Sent: Monday, August 16, 2021 10:12 AM
To: [email-masked]
Cc: [email-masked]; Vasilenko Eduard <[email-masked]>; [email-masked]; [email-masked]
Subject: Re:Next steps with draft-dong-6man-enhanced-vpn-vtn-id

Hi Greg,

Hope this helps.

Best regards,
Jie

Hi Jie,

What do you think?

Regards,

Greg Mirsky

Original Mail
Sender: Dongjie(Jimmy)

Best regards,
Jie

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 18 Aug 2021 16:11:42 +0000

Hi Stewart,

Thanks for your detailed explanation. Please see some replies inline:

> Sent: Friday, August 13, 2021 5:16 PM
> Cc: Stewart Bryant <[email-masked]>; Joel Halpern
> <[email-masked]>; 6MAN <[email-masked]>; Huzhibo
> <[email-masked]>
> My point is that IPv6 is not well suited to be a transport layer network. I would
> have thought that considering the suitability of  IPv6 to address the needs of
> an application was very much in the scope of 6man.

As you know the word "transport" is somehow controversial, while in my understanding the extensions to IPv6 are in the scope of 6man WG.

> IP was designed as a host to host protocol that expresses to the network where
> a packet should be sent and with what priority. It has an addressing scheme
> that is intended to have global scope.
> 
> If you consider the design of the protocols that have been successfully
> deployed in packet transport networks such as MPLS and Ethernet, they tend
> to be much simpler with just the bare-bones features needed to address the
> task in hand. They certainly do not have global scoped addresses. Indeed it is
> very difficult to get a packet outside the intended network scope, or
> conversely to sneak a packet Into the Transport Network.

The global scoped addresses make IPv6 applicable for providing global reachability, while IMO it can also be used in networks with limited scope. Of course some mechanism to filter the unwanted packet at the boundary would be needed. 

> 
> My point was that given that every hop has to be upgraded to address the new
> Hop by Hop header it is actually a small step to introduce a protocol that does
> the job well, and this is a better approach than to adapt a protocol (IPv6) that
> is not a good match for the problem. The problem with introducing new
> protocols to the Internet is huge and that tends to be considered too hard a
> mountain to climb. However we are not talking about the Internet here, we
> are talking about a scope that is limited to the switch path for the packed
> carrying the service that needs this feature. If the feature is needed, then all
> hops have to support it.

I fully agree it is possible to realize the required function with different data planes. This is analogous to SR which can be instantiated using IPv6 or MPLS. 

Introducing another protocol is also possible. In 6man we would like to focus on the suitable mechanisms to realize it with IPv6.  

> Now as to the identifier you can of course map a VTN-ID to an IP address. You
> can map anything to an IPv6 address, that is both the blessing and the curse of
> 128bit addresses. However unless the VTN-ID is expected to be in the DA or SA
> of an IPv6 packet there is no reason to accept that constraint. Much better to
> consider the requirements and design an identifier that is a (generalised) best
> match for the problem.

Agree that it is better to introduce an dedicated identifier for this mechanism. 

> 
> As to HBH I do not particularly like them, but if there is no alternative then
> they can obviously be used. The reason that I do not like them is that are not
> really a full citizen of the packet forwarding architecture*. You have to hunt for
> them in the packet and they may be a way down the packet possible requiring
> a forwarder re-cycle. Then there may be multiple HBH requirements in the
> packet which tends to significant complexity and possible conflict. A good
> forwarding architecture makes the actions at a hop directly accessible and
> explicit. That is why actions directly bound to the main forwarding instruction
> (the packet address, or label) are fundamentally a better design.

As the design of HBH is for per-hop packet forwarding treatment, it could meet our requirement. IMO this is straightforward. As for how the HBH header should be processed and how it can be optimized, there is another document in this WG working on it. 

> Now I do not expect that this argument will carry much weight given the
> weight of commercial pressures in play, but we should at least make the
> decision understanding the compromise and possible future implications.

Thanks for your thought on this. 

Best regards,
Jie

> >> Do you mean using IP address as the VTN-ID is probably a mistake, or VTN
> may be better implemented using a protocol other than IP? The former was
> analyzed in my presentation slides on IETF 111, while the latter seems out of
> the scope of this WG (6man).
> >>
> >> As we know, VTN can be implemented based on either IPv6 data plane or
> MPLS data plane. This document proposes the mechanism to carry VTN-ID in
> IPv6 packet header. The operational considerations section also describes the
> cases where some nodes do not recognize the HBH header or the VTN option.
> >>

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 20 Aug 2021 14:44:58 +0800

Hi All,
It is a valuable proposal and we are also interested in the direction.
However, I have some concerns from the operators perspective.
1）The existing network cannot support to identify the slice-id in HBH. And it is difficult to upgrade because of insufficient chip resources.
2）The overhead is a little bit higher if using the HBH.
3）Multiple HBHs in the same packet is possible, and it may bring more challenges while HBH may also be used for other function.
We have submitted a draft "draft-cheng-spring-srv6-encoding-network-sliceid"[1].
It described a new IP-Address based proposal for network slice. 
Any comments are welcome.

[1] https://datatracker.ietf.org/doc/draft-cheng-spring-srv6-encoding-network-sliceid/

Best Regards,
Liyan Gong

[email-masked]
 
From: Dongjie \(Jimmy\)
Date: 2021-08-05 09:56
To: 6MAN
CC: 6man Chairs

 
 
Best regards,
Jie

---

From: Tianran Zhou <[email-masked]>
Date: Fri, 20 Aug 2021 07:15:38 +0000

Hi Liyan,

My understanding is that you agree with the use of slice-id encapsulated in data plane.
Your concern is about the use of HbH extension header.
My preference is to follow the IPv6 design and choose the EH with the right semantics. So the HBH is the one in this case.
It’s true there are legacy issues in practice. But the WG is working on a better specification of HbH EH.
Hopefully, your concern could be solved.

Best,
Tianran
From: ipv6 [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, August 20, 2021 2:45 PM
To: Dongjie (Jimmy) <[email-masked]>; 6MAN <[email-masked]>
Cc: 6man-chairs <[email-masked]>
Subject: Re: Next steps with draft-dong-6man-enhanced-vpn-vtn-id

Hi All,

Best Regards,
Liyan Gong

________________________________
[email-masked]<mailto:[email-masked]>

From: Dongjie \(Jimmy\)<mailto:[email-masked]>
Date: 2021-08-05 09:56
To: 6MAN<mailto:[email-masked]>
CC: 6man Chairs<mailto:[email-masked]>
Subject: Next steps with draft-dong-6man-enhanced-vpn-vtn-id
Hi WG,

Best regards,
Jie