Re: [mpls] MPLS extension header

[John E Drake <[e-mail]>]

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 <[e-mail]> On Behalf Of ???(??)
Sent: Thursday, August 9, 2018 7:18 PM
To: Haoyu song <[e-mail]>; Stewart Bryant <[e-mail]>
Cc: [e-mail]; mpls <[e-mail]>
Subject: Re: [mpls] MPLS extension header

Hi Haoyu,

Please see my reply inline.

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

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.

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

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.



[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?



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



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



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



[Xiaohu] Leave this to Stewart



Best regards,

Xiaohu


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:[e-mail]] On Behalf Of Stewart Bryant
Sent: Thursday, August 09, 2018 12:35 AM
To: "徐小虎(义先)" <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; mpls <[e-mail]<mailto:[e-mail]>>
Subject: Re: [mpls] MPLS extension header

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

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, 徐小虎(义先) <[e-mail]<mailto:[e-mail]>> wrote:

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
------------------------------------------------------------------
From:Haoyu song <[e-mail]<mailto:[e-mail]>>
Send Time:2018年8月9日(星期四) 06:24
To:[e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
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!

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
[e-mail]<mailto:[e-mail]>
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=>