Re: [mpls] MPLS extension header

[Haoyu song <[e-mail]>]

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: [e-mail] [mailto:[e-mail]]
Sent: Thursday, August 09, 2018 7:52 AM
To: Haoyu song <[e-mail]>; [e-mail]
Subject: RE: MPLS extension header

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:[e-mail]] On Behalf Of Haoyu song
Sent: Thursday, August 09, 2018 00:24
To: [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

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.