Re: [mpls] MPLS extension header

[Haoyu song <[e-mail]>]

Please see my answer inline.
Haoyu

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

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]<mailto:[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.
[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.



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