Re: [mpls] MPLS extension header

[<[e-mail]>]

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