Re: [mpls] MPLS extension header

[<[e-mail]>]

Hi,

Please find answers inline.

Brgds

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

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

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.

_________________________________________________________________________________________________________________________

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.