Subject: [mpls] MPLS extension header

From: Haoyu song <[email-masked]>
Date: Wed, 8 Aug 2018 22:23:45 +0000

Dear all,

In IETF102 we presented the idea of MPLS extension header and received a lot of discussion. We have updated the draft to reflect the feedbacks we received.
It seems most people agree that we need extension headers (EH) to support multiple emerging in-network services, but there could be debate on how to indicate the existence of the EHs.
In the document we provide our investigations and suggestions but we do want to see your opinion. Hopefully we can achieve a consensus before IETF103.
Thank you in advance for your help!

https://www.ietf.org/id/draft-song-mpls-extension-header-01.txt

Best regards,
Haoyu

---

From: "徐小虎(义先)" <[email-masked]>
Date: Thu, 09 Aug 2018 10:56:01 +0800

Hi Haoyu,

I believe it's worthwhile to introduce an MPLS payload indicator into MPLS so as to support various MPLS payload types in a long run. However, I wonder whether the mechanism as described in (https://tools.ietf.org/html/draft-xu-mpls-payload-protocol-identifier) has met this demand.

Best regards,
Xiaohu

------------------------------------------------------------------
From:Haoyu song <[email-masked]>
Send Time:2018年8月9日(星期四) 06:24
To:[email-masked] <[email-masked]>
Subject:[mpls] MPLS extension header

Dear all,

---

From: "徐小虎(义先)" <[email-masked]>
Date: Thu, 09 Aug 2018 11:37:22 +0800

By the way, I just noticed the following text in your draft:

"
   Segment Routing:  MPLS extension header can support the
      implementation of a new flavor of the MPLS-based segment routing,
      with better performance and richer functionalities.  The details
      will be described in another draft."

What's the rationale of implementing a new flavor of MPLS-based Segment Routing? In other words, what potential issues with the current MPLS-SR are to be addressed by the MPLS extension header-based MPLS-SR variation?

Best regards,
Xiaohu
------------------------------------------------------------------
From:徐小虎(义先) <[email-masked]>
Send Time:2018年8月9日(星期四) 10:56
To:mpls <[email-masked]>; [email-masked] <[email-masked]>
Subject:Re: [mpls] MPLS extension header

Hi Haoyu,

Best regards,
Xiaohu

Dear all,

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 9 Aug 2018 10:35:20 +0300

Xiahou

A better approach for metadata would be s/PIL/GAL as described in:

https://www.ietf.org/archive/id/draft-guichard-sfc-mpls-metadata-00.txt

I cannot see why we need another reserved label when the one we have would work fine in this application, and many more.

Stewart

Sent from my iPad

> On 9 Aug 2018, at 05:56, 徐小虎(义先) <[email-masked]> wrote:
> 
> Hi Haoyu,
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: <[email-masked]>
Date: Thu, 9 Aug 2018 14:51:46 +0000

Hi

"An EHL can be located in anywhere in an MPLS label stack.
   However, if there are legacy devices which do not recognize the EHL
   in the network, then for backward compatibility, the EHL must be
   located at the bottom of the stack (i.e., only the MPLS tunnel ends
   and EHL-aware nodes will look up and process it).  Otherwise, the EHL
   can be located close to the top of the stack for better lookup
   performance."

I don't like the statement that the EHL can be located anywhere. As you mentioned in the text, the ingress needs to know if transit nodes and the tailend are able to process EHL. How do you plan to signal this ?
Let's say that all transit+tail end support the EHL. In such a case, you propose to place the EHL close to the top of the stack.
In the example below, what is the behavior of Node B ? After parsing the EHs, does it copy back the EHs above Node_SID_F to let them available for other nodes ?

A-B-C-D-E-F

A: ingress node pushing label stack [Adj_SID_BC, EHL, HEH,..., Node_SID_F }

From: mpls [mailto:[email-masked]] On Behalf Of Haoyu song
Sent: Thursday, August 09, 2018 00:24
To: [email-masked]
Subject: [mpls] MPLS extension header

Dear all,

Best regards,
Haoyu

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Haoyu song <[email-masked]>
Date: Thu, 9 Aug 2018 18:57:43 +0000

Hi Stephane,

Thank you very much for the question and comments.

If the EH is applied in a single network domain and all the devices are upgraded to support it, then there is no need to signal the EHL. I think this is a possible scenario.

For your second question, I don't quite understand it. Only the EHL is in the label stack. The HEH and EHs are fields located between the MPLS label stack and the payload. Unless some EHs are no longer needed, they are always there waiting for being parsed and processed, so there is no need for "copy back".  Please let me know if I misunderstood your question.

Best regards,
Haoyu

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, August 09, 2018 7:52 AM
To: Haoyu song <[email-masked]>; [email-masked]
Subject: RE: MPLS extension header

Hi

A-B-C-D-E-F

From: mpls [mailto:[email-masked]] On Behalf Of Haoyu song
Sent: Thursday, August 09, 2018 00:24
To: [email-masked]<mailto:[email-masked]>
Subject: [mpls] MPLS extension header

Dear all,

Best regards,
Haoyu

Thank you.

---

From: Haoyu song <[email-masked]>
Date: Thu, 9 Aug 2018 19:26:00 +0000

Hi Xiaohu and Stewart,

First,  the intention of this draft is not to tell the protocol type of the MPLS payload, but to indicate the existence of EHs. I admit the high level idea is similar: we need some indicator for something.

Here are some considerations for choosing the EH indicator:

(1)    Support multiple in-network service headers to be encapsulated into MPLS packets. Most existing proposals only assume there is one extra header.

(2)    Because each node needs to check the existence of EHs, for performance considerations, we don’t want to force the indicator to be at the bottom of the stack; Besides, too many proposals have already competed for the BoS location, and such proposals also often impair the ECMP capability based on the payload header.

(3)    For the same reason, we prefer an indicator that can directly tell the existence of EHs, rather than overloading some existing labels, and then jumping to another control word after the label stack to see if there are actually EHs.

To meet these requirements, we listed several possible solutions in the draft (there may be others we neglected). If you have a strong opinion to prefer one over the others, please let me know with your reason.

Best regards,
Haoyu

From: mpls [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Thursday, August 09, 2018 12:35 AM
To: "徐小虎(义先)" <[email-masked]>
Cc: [email-masked]; mpls <[email-masked]>
Subject: Re: [mpls] MPLS extension header

Xiahou

Stewart

Sent from my iPad

On 9 Aug 2018, at 05:56, 徐小虎(义先) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Haoyu,

Best regards,
Xiaohu
------------------------------------------------------------------
From:Haoyu song <[email-masked]<mailto:[email-masked]>>
Send Time:2018年8月9日(星期四) 06:24
To:[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject:[mpls] MPLS extension header

Dear all,

In IETF102 we presented the idea of MPLS extension header and received a lot of discussion. We have updated the draft to reflect the feedbacks we received.
It seems most people agree that we need extension headers (EH) to support multiple emerging in-network services, but there could be debate on how to indicate the existence of the EHs.
In the document we provide our investigations and suggestions but we do want to see your opinion.. Hopefully we can achieve a consensus before IETF103.
Thank you in advance for your help!

Best regards,
Haoyu

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: Haoyu song <[email-masked]>
Date: Thu, 9 Aug 2018 19:28:48 +0000

For example, no support of network programming in MPLS-SR
For another example, no support of metadata if MPLS-SR is used for SFC ☺

Haoyu

From: mpls [mailto:[email-masked]] On Behalf Of ???(??)
Sent: Wednesday, August 08, 2018 8:37 PM
To: 徐小虎(义先) <[email-masked]>; [email-masked]
Subject: Re: [mpls] MPLS extension header

"

Best regards,

Xiaohu
------------------------------------------------------------------
From:徐小虎(义先) <[email-masked]<mailto:[email-masked]>>
Send Time:2018年8月9日(星期四) 10:56
To:mpls <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject:Re: [mpls] MPLS extension header

Hi Haoyu,

Best regards,
Xiaohu
To:[email-masked] <[email-masked]<mailto:[email-masked]>>

Dear all,

Best regards,
Haoyu

---

From: "徐小虎(义先)" <[email-masked]>
Date: Fri, 10 Aug 2018 07:17:40 +0800

Hi Haoyu,

Please see my reply inline.

------------------------------------------------------------------
From:Haoyu song <[email-masked]>
Send Time:2018年8月10日(星期五) 03:26
To:Stewart Bryant <[email-masked]>; 徐小虎(义先) <[email-masked]>
Cc:[email-masked] <[email-masked]>; mpls <[email-masked]>
Subject:RE: [mpls] MPLS extension header

Hi Xiaohu and Stewart,

[Xiaohu] Either using the protocol type field or using the EH, we need to indicate the existence of it between MPLS label stack and the MPLS payload. 

[Xiaohu] Could you give a concrete example where multiple EHs are needed especially in the case where each in-network service header itself has a protocol field?

[Xiaohu] Could you explain more concretely how the ECMP capability is impaired when the indicator label is at the bottom of the label stack? 

[Xiaohu] Leave this to Stewart

Best regards,
Xiaohu

Best regards,
Haoyu

Sent from my iPad

Hi Haoyu,

Best regards,
Xiaohu

Dear all,

Best regards,
Haoyu

---

From: "徐小虎(义先)" <[email-masked]>
Date: Fri, 10 Aug 2018 07:32:52 +0800

Please see my response inline.

------------------------------------------------------------------
From:Haoyu song <[email-masked]>
Send Time:2018年8月10日(星期五) 03:28
To:徐小虎(义先) <[email-masked]>; [email-masked] <[email-masked]>
Subject:RE: [mpls] MPLS extension header

[Xiaohu] What concrete network programming capability is expected for MPLS-SR?

For another example, no support of metadata if MPLS-SR is used for SFC J

[Xiaohu] As for how metadata is carried in the MPLS-SR-based SFC mechanism, please see section 7.1 of https://tools.ietf.org/html/draft-xuclad-spring-sr-service-chaining-01.

Xiaohu

Haoyu

"

Best regards,
Xiaohu

Hi Haoyu,

Best regards,
Xiaohu

Dear all,

Best regards,
Haoyu

---

From: Haoyu song <[email-masked]>
Date: Thu, 9 Aug 2018 23:41:29 +0000

Inline

From: 徐小虎(义先) [mailto:[email-masked]]
Sent: Thursday, August 09, 2018 4:18 PM
To: Haoyu song <[email-masked]>; Stewart Bryant <[email-masked]>
Cc: [email-masked]; mpls <[email-masked]>
Subject: Re: [mpls] MPLS extension header

Hi Haoyu,

------------------------------------------------------------------
From:Haoyu song <[email-masked]<mailto:[email-masked]>>
Send Time:2018年8月10日(星期五) 03:26
To:Stewart Bryant <[email-masked]<mailto:[email-masked]>>; 徐小虎(义先) <[email-masked]<mailto:[email-masked]>>
Cc:[email-masked] <[email-masked]<mailto:[email-masked]>>; mpls <[email-masked]<mailto:[email-masked]>>
Subject:RE: [mpls] MPLS extension header

Hi Xiaohu and Stewart,

[Haoyu] Correct.

[Xiaohu] Could you give a concrete example where multiple EHs are needed especially in the case where each in-network service header itself has a protocol field?.

         [Haoyu] We listed several use cases in the draft. Several of them can be applied at the same time (e.g., iOAM+SFC). It’s true for some headers they already defined a protocol field (e.g., NSH). But for others, there is not a protocol field (e.g., iOAM). My feeling is that many of these headers should not be considered as protocol header but rather service header, so they are better to be treated as extension headers.

         [Haoyu] In case the original packet after MPLS labels is IPv4, the IP 5-tuple header is used as hash key for ECMP. Now if there is something else in between, you can’t do it anymore unless you parse the new stuff and skip it. With the EH we proposed, we have the similar situation but we provide a mechanism to skip all EHs in one step without needing to parse them.

Best regards,

Xiaohu

Best regards,
Haoyu

From: mpls [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Thursday, August 09, 2018 12:35 AM
To: "徐小虎(义先)" <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] MPLS extension header

Xiahou

Stewart

Sent from my iPad

Hi Haoyu,

Best regards,
Xiaohu

Dear all,

Best regards,
Haoyu

---

From: John E Drake <[email-masked]>
Date: Thu, 9 Aug 2018 23:41:36 +0000

Hi,

I think someone else (Stephane?) pointed out that if the indicator label is anywhere other than at the bottom of the stack it will be tossed in midflight and what will the succeeding nodes do in this case?

I think this observation is compelling.  Also, all of the data plane implementations of which I am aware first scan the stack for the label w/ the BoS bit set as a way to orient themselves for the forwarding task.

Yours Irrespectively,

John

From: mpls <[email-masked]> On Behalf Of ???(??)
Sent: Thursday, August 9, 2018 7:18 PM
To: Haoyu song <[email-masked]>; Stewart Bryant <[email-masked]>
Cc: [email-masked]; mpls <[email-masked]>
Subject: Re: [mpls] MPLS extension header

Hi Haoyu,

Hi Xiaohu and Stewart,

Best regards,

Xiaohu

Best regards,
Haoyu

Xiahou

https://www.ietf.org/archive/id/draft-guichard-sfc-mpls-metadata-00.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dguichard-2Dsfc-2Dmpls-2Dmetadata-2D00.txt&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=8MosIgvSvroaW2Jn4Rzk0RcHWk4yTvBD5Oi1pCH6VvA&s=hVqsfFDS4ZGd4aOxB7gsByk5yZRoyR8wcqBZ4B1P_Y4&e=>

Stewart

Sent from my iPad

Hi Haoyu,

I believe it's worthwhile to introduce an MPLS payload indicator into MPLS so as to support various MPLS payload types in a long run. However, I wonder whether the mechanism as described in (https://tools.ietf.org/html/draft-xu-mpls-payload-protocol-identifier<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dxu-2Dmpls-2Dpayload-2Dprotocol-2Didentifier&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=8MosIgvSvroaW2Jn4Rzk0RcHWk4yTvBD5Oi1pCH6VvA&s=WRdVCeU_yLHQEflJ6eM52VM5FNRHrceqpcX5vnvmChM&e=>) has met this demand.

Best regards,
Xiaohu

Dear all,

https://www.ietf.org/id/draft-song-mpls-extension-header-01.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dsong-2Dmpls-2Dextension-2Dheader-2D01.txt&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=8MosIgvSvroaW2Jn4Rzk0RcHWk4yTvBD5Oi1pCH6VvA&s=IpHM8aAyfrFEBHROPOiOm3tvvkhx1hPd8vN7fmOrjDU&e=>

Best regards,
Haoyu

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=8MosIgvSvroaW2Jn4Rzk0RcHWk4yTvBD5Oi1pCH6VvA&s=VGPK-EFXHZ9a_I9E_EDS7JGIhn8_A00OmjKZrq-YVTI&e=>

---

From: Haoyu song <[email-masked]>
Date: Thu, 9 Aug 2018 23:50:04 +0000

Inline. But please remember that is just one possible solution and not an essential one, and we prefer to delay its discussion until we finish the current work.

Haoyu

From: 徐小虎(义先) [mailto:[email-masked]]
Sent: Thursday, August 09, 2018 4:33 PM
To: Haoyu song <[email-masked]>; [email-masked]
Subject: Re: [mpls] MPLS extension header

To:徐小虎(义先) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

[Xiaohu] What concrete network programming capability is expected for MPLS-SR?
[Haoyu] Not study it in detail yet. I guess it’s something similar as in SRv6.

[Xiaohu] As for how metadata is carried in the MPLS-SR-based SFC mechanism, please see section 7.1 of https://tools.ietf.org/html/draft-xuclad-spring-sr-service-chaining-01.
[Haoyu] Well, here you point to the same draft again. Yes that’s one possible solution, yet here we just use the EH to support it and at the same time, for the same arguments, to cover other extensions as well.

Xiaohu

Haoyu

From: mpls [mailto:[email-masked]] On Behalf Of ???(??)
Sent: Wednesday, August 08, 2018 8:37 PM
To: 徐小虎(义先) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] MPLS extension header

"

Best regards,

Xiaohu

Hi Haoyu,

Best regards,
Xiaohu

Dear all,

Best regards,
Haoyu

---

From: Haoyu song <[email-masked]>
Date: Fri, 10 Aug 2018 00:01:32 +0000

Hi John,

Yes in this case, when the indicator label is not at BoS, the intermediate node needs to pop it first and then push it back (some non-typical processing). But this is just a very simple operation. Anyway, EH is new to MPLS, and routers need to be upgraded to handle it.

I need to collect more information about the second point. What I heard is that some implementation has the hardware limitation to examine up to some level of MPLS labels which means if the stack is deep, it can’t see the BoS. And depending on the implementation target (e.g., NPU), if it needs to scan the entire label stack for each packet, it’s possible to incur some performance penalty.
We need to check this with more experts.
If this is an issue, then put the indicator near top has its advantages, because it’s possible only a subset of packets has EHs.
If this is not an issue, then we can comfortably put the indicator at the BoS.

Best regards,
Haoyu

From: John E Drake [mailto:[email-masked]]
Sent: Thursday, August 09, 2018 4:42 PM
To: 徐小虎(义先) <[email-masked]>; Haoyu song <[email-masked]>; Stewart Bryant <[email-masked]>
Cc: [email-masked]; mpls <[email-masked]>
Subject: RE: [mpls] MPLS extension header

Hi,

Yours Irrespectively,

John

From: mpls <[email-masked]<mailto:[email-masked]>> On Behalf Of ???(??)
Sent: Thursday, August 9, 2018 7:18 PM
To: Haoyu song <[email-masked]<mailto:[email-masked]>>; Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] MPLS extension header

Hi Haoyu,

Hi Xiaohu and Stewart,

Best regards,

Xiaohu

Best regards,
Haoyu

Xiahou

Stewart

Sent from my iPad

Hi Haoyu,

Best regards,
Xiaohu

Dear all,

Best regards,
Haoyu

---

From: "徐小虎(义先)" <[email-masked]>
Date: Fri, 10 Aug 2018 08:03:38 +0800

See inline

------------------------------------------------------------------
From:Haoyu song <[email-masked]>
Send Time:2018年8月10日(星期五) 07:41
To:徐小虎(义先) <[email-masked]>; Stewart Bryant <[email-masked]>
Cc:[email-masked] <[email-masked]>; mpls <[email-masked]>
Subject:RE: [mpls] MPLS extension header

Inline

 

Hi Xiaohu and Stewart,

【Xiaohu1】Should those headers which lack a protocol field first fix their own issue, just as what we want to do with MPLS?

[Xiaohu1] How to skip all EHs if the EHL and EHs are not recognized by intermediate routers?

Xiaohu

Best regards,
Xiaohu

Best regards,
Haoyu

Xiahou

Stewart

Sent from my iPad

Hi Haoyu,

Best regards,
Xiaohu

Dear all,

Best regards,
Haoyu

---

From: Haoyu song <[email-masked]>
Date: Fri, 10 Aug 2018 00:12:30 +0000

inline
Sent: Thursday, August 09, 2018 5:04 PM

See inline
To:徐小虎(义先) <[email-masked]<mailto:[email-masked]>>; Stewart Bryant <[email-masked]<mailto:[email-masked]>>

Inline

Hi Haoyu,

Hi Xiaohu and Stewart,

[Haoyu1] First, in many cases, I don’t think it’s proper to add a protocol field to each new kind of header, as explained above.

                  Second, if each header has its own definition and format for the next protocol, it forces all the intermediate nodes to understand and be able to parse all the new headers which is impractical. We want to treat each EH equally and easy to skip or ignore any of them with ease, just like what has been done in IPv6.

[Haoyu1] The intermediate router must understand the EHL and HEH. Yes this doesn’t work for legacy routers.

Xiaohu

Best regards,

Xiaohu

Best regards,
Haoyu

Xiahou

Stewart

Sent from my iPad

Hi Haoyu,

Best regards,
Xiaohu

Dear all,

Best regards,
Haoyu

---

From: "徐小虎(义先)" <[email-masked]>
Date: Fri, 10 Aug 2018 09:23:09 +0800

Send Time:2018年8月10日(星期五) 08:12

inline

See inline

Inline

From:徐小虎(义先) [mailto:[email-masked]] 

Hi Haoyu,

Hi Xiaohu and Stewart,

[Xiaohu2] It seems that the iOAM header itself contains a protocol field (see https://tools.ietf.org/html/draft-brockners-inband-oam-transport-05).

Xiaohu

Xiaohu

Best regards,
Xiaohu

Best regards,
Haoyu

Xiahou

Stewart

Sent from my iPad

Hi Haoyu,

Best regards,
Xiaohu

Dear all,

Best regards,
Haoyu

---

From: Tianran Zhou <[email-masked]>
Date: Fri, 10 Aug 2018 02:04:48 +0000

Hi Xiaohu,

For IOAM please see this:
https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data

IMO, IOAM data draft defined the IOAM as a metadata with format. How to encapsulate it into other protocols is another topic. If possible I would prefer to encapsulation it into an extension header, if that protocol supports.

The argument that I think define such functions as an extension header is better than an independent protocol header is compatibility.

For example, for an independent protocol header, if the device do not know this protocol, it cannot continue to process the following headers/protocols. Or it may even drop the packet.

However, for an extension header, we have a generic extension header format, i.e., Type and Length definition. So in principle, if the device do not know one Type, it can just skip this extension header and move to the next by using the Length.

Cheers,
Tianran

From: mpls [mailto:[email-masked]] On Behalf Of 徐小虎(义先)
Sent: Friday, August 10, 2018 9:23 AM
To: Haoyu song <[email-masked]>; Stewart Bryant <[email-masked]>
Cc: [email-masked]; mpls <[email-masked]>
Subject: Re: [mpls] MPLS extension header

inline

See inline

Inline

Hi Haoyu,

Hi Xiaohu and Stewart,

Xiaohu

Xiaohu

Best regards,

Xiaohu

Best regards,
Haoyu

Xiahou

Stewart

Sent from my iPad

Hi Haoyu,

Best regards,
Xiaohu

Dear all,

Best regards,
Haoyu

---

From: <[email-masked]>
Date: Fri, 10 Aug 2018 08:27:57 +0000

Hi,

Please find answers inline.

Brgds

From: Haoyu song [mailto:[email-masked]]
Sent: Thursday, August 09, 2018 20:58
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: RE: MPLS extension header

Hi Stephane,

>If the EH is applied in a single network domain and all the devices are upgraded to support it, then there is no need to signal the EHL. I think this is a possible scenario.
[SLI] You cannot use this assumption. There is always plenty of nodes that were you will not be able to get the feature because their HW will not allow to support it.

>For your second question, I don't quite understand it. Only the EHL is in the label stack. The HEH and EHs are fields located between the MPLS label stack and the payload. Unless some EHs are no longer needed, they are always there waiting for being parsed and processed, so there is no need for "copy >back".  Please let me know if I misunderstood your question.

[SLI] Ok I think there was a misunderstanding on my side on the location of the EHs but my point is still valid for the EHL. Do you copy back the EHL when it is not at the bottom of the stack and it is popped in midflight ?
In https://datatracker.ietf.org/doc/draft-ietf-mpls-spring-entropy-label/ we considered this option as not valid because of the HW impact. Please look at all the options we have analyzed.

One other point, you are telling that GAL makes deep packet inspection more difficult. Don't you think that you have the same issue here ?
If a transit node doing loadbalancing does not understand EHL and EHs, how could it do loadbalancing by deep packet inspection ? I think it won't be able anymore to hash.
If a transit node doing loadbalancing understand the EHL and EHs, the upper layer info will deeper compared to without EHs. Even if you provide an extension header with the upper layer, it may be at the end of the EH chain, and may not be readable.

Even if a node understands EHs, how do you ensure that it will be able to read the entire chain of EHs ? Some HWs are limited to a specific number of bytes they can read.

I don't see how you solve the performance issue compared to GAL like solution if you are keeping the extensions header at the end of the stack. You HW will still need to read up to BOS even if the EHL is next to the top label. Could you elaborate on where is the perf improvement ?

Best regards,
Haoyu

Hi

A-B-C-D-E-F

Dear all,

Best regards,
Haoyu

Thank you.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 10 Aug 2018 16:04:07 +0100

All,
 
I'm finding this fast-moving discussion a bit confusing.
 
Part of the problem is the discussion of all the possible use cases for the EH.
That makes it hard to focus in on the actual requirements rather than the
potential uses, and so the discussion is a bit fluid - when anyone observes that
a specific use case could be solved a different way, it can always be said that
this is not the main reason for the innovation. And, of course, it is easy to
float difficulties with other approaches (such as scaling, etc.) when the
requirements to circumvent those difficulties are speculative.
 
Thus a number of questions remain hard to pin down:
- does this approach need a fork-lift upgrade or can it be used with legacy
routers?
- can multiple EHLs be present in the stack?
- what is done with an EHL when it becomes top of stack?
- is a transit node expected to "find" the EHL if it is not top of stack?
 
To successfully answer these questions we need to know what function we are
attempting to deliver. Indeed, some of the questions may even be irrelevant!
 
But two other things strike me about the current version of the document:
 
1. The description of the deficiencies of the GAL/ACH may over-state the issues
a little. While you note that the primary application originally envisaged the
GAL at the bottom of the stack, this is not a firm requirement and the GAL may
actually appear anywhere in the stack. While it is true, as you note, that only
a limited number of control word types are allowed, the ACH channel type
provides sufficient scaling of a differentiator.  And you are correct that the
GAL only indicates the presence of a single ACH, but the construction of the
G-Ach message allows multiple "objects" to be present. Lastly you note that the
presence of the GAL (and presumably the ACH?) makes DPI and load-balancing by
inspection of the payload protocol header hard, you must understand that this is
for exactly the reason that the use of the EHL and EH would make the same
functions hard - the solution to the first case may not be of interest to the
IETF, and the second case is addressed by the entropy label.
 
2. The behaviour seems to model the IPv6 Destination Options extension header.
This may provide several lessons to us both in construction of a mechanism and
on the breadth of its applicability. Of note is how the destination options may
be present twice: once for the current destination addressed by the destination
address, and once for the ultimate destination. We should note that an EHL in
the stack is only encountered when the preceding label is popped - in that way
it is like the first type of destination option. While an EHL at the bottom of
the stack is like the second type of destination option.
 
Regards,
Adrian

---

From: Haoyu song <[email-masked]>
Date: Fri, 10 Aug 2018 18:49:03 +0000

Please see my answer inline.
Haoyu

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, August 10, 2018 1:28 AM
To: Haoyu song <[email-masked]>; [email-masked]
Subject: RE: MPLS extension header

Hi,

Brgds

From: Haoyu song [mailto:[email-masked]]
Sent: Thursday, August 09, 2018 20:58
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]<mailto:[email-masked]>
Subject: RE: MPLS extension header

Hi Stephane,

[SLI] You cannot use this assumption. There is always plenty of nodes that were you will not be able to get the feature because their HW will not allow to support it.
[HS] This is just one possible deployment scenario, for example, in a mobile backhaul network. If there are legacy devices in the network, then we have to constraint the EHL to the BoS, as stated in the draft.

[SLI] Ok I think there was a misunderstanding on my side on the location of the EHs but my point is still valid for the EHL. Do you copy back the EHL when it is not at the bottom of the stack and it is popped in midflight ?
In https://datatracker.ietf.org/doc/draft-ietf-mpls-spring-entropy-label/ we considered this option as not valid because of the HW impact. Please look at all the options we have analyzed.
[HS] Yes, if we need to pop a label below the EHL, then we need to pop EHL first and then later push it back. But please note that the EHL is just one fixed label with known value (or two if we use the XL+EHL option), so it doesn't even need to be cached. The node just pop it, and later push the EHL back. I don't see much HW impact here. Can you elaborate it more?

One other point, you are telling that GAL makes deep packet inspection more difficult. Don't you think that you have the same issue here ?
If a transit node doing loadbalancing does not understand EHL and EHs, how could it do loadbalancing by deep packet inspection ? I think it won't be able anymore to hash.
If a transit node doing loadbalancing understand the EHL and EHs, the upper layer info will deeper compared to without EHs. Even if you provide an extension header with the upper layer, it may be at the end of the EH chain, and may not be readable.
[HS] Yes, I have discussed this issue in another email. If the hardware is capable, then we provide a mechanism to quickly jump to the upper layer. Here the key is that each node just need to understand the EH as a part of  the MPLS header but no the internal format of each specific EH.

Even if a node understands EHs, how do you ensure that it will be able to read the entire chain of EHs ? Some HWs are limited to a specific number of bytes they can read.
[HS] If that's the hardware limitation, we can do nothing about it.

I don't see how you solve the performance issue compared to GAL like solution if you are keeping the extensions header at the end of the stack. You HW will still need to read up to BOS even if the EHL is next to the top label. Could you elaborate on where is the perf improvement ?
[HS] Yes, if it's at the BoS, the router will need the same time to tell the existence of EHs. It's no better than GAL like solutions. But at that point, we provide a mechanism to chain the EHs together and allow a quick scan through it up to the upper layer. I think this is the key contribution for this draft. We tried the best to provide the EHL location flexibility but for backward compatibility and incremental deployment scenario, we have to follow some constraints.

Best regards,
Haoyu

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, August 09, 2018 7:52 AM
To: Haoyu song <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: MPLS extension header

Hi

A-B-C-D-E-F

Dear all,

Best regards,
Haoyu

Thank you.

Thank you.

---

From: Haoyu song <[email-masked]>
Date: Fri, 10 Aug 2018 19:21:01 +0000

Hi Adrian,

Please find my response inline.

Best,
Haoyu

From: Adrian Farrel [mailto:[email-masked]]
Sent: Friday, August 10, 2018 8:04 AM
To: [email-masked]
Cc: Haoyu song <[email-masked]>
Subject: RE: [mpls] MPLS extension header

All,

Part of the problem is the discussion of all the possible use cases for the EH. That makes it hard to focus in on the actual requirements rather than the potential uses, and so the discussion is a bit fluid - when anyone observes that a specific use case could be solved a different way, it can always be said that this is not the main reason for the innovation. And, of course, it is easy to float difficulties with other approaches (such as scaling, etc.) when the requirements to circumvent those difficulties are speculative.

Thus a number of questions remain hard to pin down:
- does this approach need a fork-lift upgrade or can it be used with legacy routers?
[HS] For legacy routers, if they don't need to access the upper layer and they don't need to scan and understand every label, then they can still forward packets with EHs.
Otherwise, a fork-lift upgrade is needed.

- can multiple EHLs be present in the stack?
[HS] I don't see why this is needed but there's no fundamental reason why it can't be done.

- what is done with an EHL when it becomes top of stack?
[HS] Pop it if a label below it needs to be accessed. Then push it back if EHs are still present.

- is a transit node expected to "find" the EHL if it is not top of stack?
[HS] If it's capable and configured to process EHs, the node should try to find EHL in each packet.

To successfully answer these questions we need to know what function we are attempting to deliver. Indeed, some of the questions may even be irrelevant!

1. The description of the deficiencies of the GAL/ACH may over-state the issues a little. While you note that the primary application originally envisaged the GAL at the bottom of the stack, this is not a firm requirement and the GAL may actually appear anywhere in the stack. While it is true, as you note, that only a limited number of control word types are allowed, the ACH channel type provides sufficient scaling of a differentiator.  And you are correct that the GAL only indicates the presence of a single ACH, but the construction of the G-Ach message allows multiple "objects" to be present. Lastly you note that the presence of the GAL (and presumably the ACH?) makes DPI and load-balancing by inspection of the payload protocol header hard, you must understand that this is for exactly the reason that the use of the EHL and EH would make the same functions hard - the solution to the first case may not be of interest to the IETF, and the second case is addressed by the entropy label.
[HS] I have discussed this point in another email. And in the draft we explained why we don't want to further overload the GAL sematics. But anyway if there is a strong  argument and consensus to reuse GAL as the indicator, we won't object it. The main contribution of this draft is the way to support multiple chained EHs. We are open to select the indicator approach for EHs.

2. The behaviour seems to model the IPv6 Destination Options extension header. This may provide several lessons to us both in construction of a mechanism and on the breadth of its applicability. Of note is how the destination options may be present twice: once for the current destination addressed by the destination address, and once for the ultimate destination. We should note that an EHL in the stack is only encountered when the preceding label is popped - in that way it is like the first type of destination option. While an EHL at the bottom of the stack is like the second type of destination option.
[HS] This is an interesting observation. Currently we just assume that every configured node will check for EHL in the entire label stack and then search for the EHs it is configured to process if an EHL is found. What you said seems to suggest to associate an EHL to a particular destination, hence we can have more control and realize something like hop-by-hop EH and end-to-end EH. I think we can explore this possibility further.

Regards,
Adrian