Re: [OSPF] WG Last Call for "Signalling ELC using OSPF"

[<[e-mail]>]

Hi Xiaohu,

Thanks for your reply.
Please see inline [Bruno]

In short, I insist on the need to have a specific definition of what “RLD” (or RLDC depending on the draft…) means.
- From a general standpoint, this is required for interop of even usage of this information. Then on this specific case, unfortunately, from the discussion, it seems that different person have a different understanding of it, so we may have a bigger problem.
- And we may have a bigger problem as the EL spec allow many (all) behavior on the transit LSR. https://tools.ietf.org/html/rfc6790#section-4.3  e.g. the EL may not be used if the LSR is capable of parsing the inner packet (IP header), in which case this is useless to add an (additional) EL,ELI pair, especially if the ingress is limited in the number of labels that it can push. (hence the problem is even bigger for draft-ietf-mpls-spring-entropy-label-04.txt which tries to make a decision based on the RLDC advertisement (which currently is loosely defined) and the LSR transit behavior (which is just unknown/unspecified)…
- This is a pre-requisite to even discuss the draft. (well, I mean the second half of this draft related to the RDLC TLV (type TBD2).

From: Xuxiaohu [mailto:[e-mail]]
Sent: Tuesday, November 08, 2016 3:34 AM
To: Acee Lindem (acee); DECRAENE Bruno IMT/OLN; OSPF WG List
Subject: ??: [OSPF] WG Last Call for "Signalling ELC using OSPF"

Hi Acee and Bruno,

Thanks for your comments. Please see my response inline.

发件人: OSPF [mailto:[e-mail]] 代表 Acee Lindem (acee)
发送时间: 2016年11月8日 9:27
收件人: [e-mail]<mailto:[e-mail]>; OSPF WG List
主题: Re: [OSPF] WG Last Call for "Signalling ELC using OSPF"

Hi Bruno,

From: Bruno Decraene <[e-mail]<mailto:[e-mail]>>
Date: Monday, November 7, 2016 at 6:43 AM
To: Acee Lindem <[e-mail]<mailto:[e-mail]>>, OSPF WG List <[e-mail]<mailto:[e-mail]>>
Subject: RE: [OSPF] WG Last Call for "Signalling ELC using OSPF"

Hi authors, all,

Please find below some comments on the RLDC definition.

1) I’d like to see a more specific definition of RLDC.
e.g. load-balancing hashing could be done based on (hashing):
-a- a (stack of) N  “regular” MPLS labels (i.e. there is no ELI in this stack)
-b- the (IP) header below the stack of N  labels
-c- the EL label in the stack of N labels (i.e. there is one ELI in this stack)

I’d like the specification to be clear on the applicability of the RLDC. Does it apply on these 3 cases, on only a subset?
Personally, I’d like at least a and c be in scope of the RLDC definition, such that an ingress with limited push capability could have enough information to decide that it could avoid pushing an ELI,EL pair if the stack of MPLS labels that it pushes has enough entropy within the first RLDC labels.


I think that the signaling document should reference section 4 of https://www.ietf.org/id/draft-ietf-mpls-spring-entropy-label-04.txt. However, I don’t think -b- is covered there.

[Xiaohu] The RLDC is only applicable to c, as it had been stated in section 6 (see below).
[Bruno] I don’t think that this is good enough. The goal of RLD/RLDC is to give the ingress node, additional knowledge on the capability on the load-balancing of downstream LSR, in order to be able to take an informed decision with regard to the placement of EL labels. Knowing “a” seems useful to me. So if you don’t want RLD to apply to “a”, then I’d like the draft to be extended to also be able to advertise the RLD for the “a” case. IOW, in TLV=TBD2, allow the advertisement of both RLD for EL an RLD for stack of regular labels.
Note that in the general case, case “a” is a bit more complex as some implementations are limited to do the hashing on a range of inner labels e.g. labels 5 to label 9, so in order to accurately reflect this, we would need to advertise this range. At which point we could also advertise the “b” case, since if the MPLS encapsulated protocol is IP, some implementation will have a different behavior and load balance based on the IP header.
So the problem is not very easy and some trade-off may be involved. But we need to clearly define the meaning of the RLD advertisement, otherwise it’s either useless or misleading.
Note that even if the document is restricted to the case “c”, the behavior needs to be clear for IP traffic. Indeed, some hardware may do the LB based on the IP header, even if a ELI is present in the label stack. In which case, there may be an incentive for the ingress to push more labels, in order to “hide” the IP header and allow the EL to be used. (as the EL could provide more entropy than the IP header, e.g. if the IP header is from an IP tunnel). And given that the EL spec roughly opens all possibly option for the transit LSR behavior, https://tools.ietf.org/html/rfc6790#section-4.3 it looks like much more work is needed.





§6 Usage and Applicability

“The RLDC is used by ingress LSRs

   to determine whether it's necessary to insert an EL for a given LSP

   tunnel in the case where there has already been at least one EL in

   the label stack.

2) Current text seems to limit the use of the RLDC to the insertion of a _second_ EL. Why is the RLD not applicable to the first EL?


§1.  Introduction

“This capability, referred to

   as Readable Label Deepth Capability (RLDC) can be used by ingress

   LSRs to determine whether it's necessary to insert an EL for a given

   LSP tunnel in the case where there has already been at least one EL

   in the label stack [I-D.ietf-mpls-spring-entropy-label<https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-03#ref-I-D.ietf-mpls-spring-entropy-label>]”



§6 Usage and Applicability

“The RLDC is used by ingress LSRs

   to determine whether it's necessary to insert an EL for a given LSP

   tunnel in the case where there has already been at least one EL in

   the label stack. »




I think that this is an unnecessary restriction of the RLDC usage. Indeed, an ingress with a limited capability in term of label push, could be forced to push a single EL label. It should be able to use the RLDC info in order to choose the best location for the EL, even if it pushes a single one.
But both sentences seems to restrict RLDC usage for the additional EL push, not the first one.

I would tend to agree.

[Xiaohu] I agree that the goal (i.e., use the RLDC info in order to choose the best location for the EL, even if it pushes a single one.) is perfect.
[Bruno] Good.

And it seems in align with the second of the recommendations for inserting EL pairs


   o  An LSR that is limited in the number of <ELI, EL> pairs that it
      can insert SHOULD insert such pairs deeper in the stack.

   o  An LSR SHOULD try to insert <ELI, EL> pairs at positions so that
      for the maximum number of transit LSRs, the EL occurs within the
      RLD of the incoming packet to that LSR.

   o  An LSR SHOULD try to insert the minimum number of such pairs while
      trying to satisfy the above criteria.

However, it would make the EL insertion decision process on the ingress much complex. For instance, the ingress need to determine the total number of transit LSRs within each LSP hierarchy when that LSP is the outermost one. In fact, the EL insertion decision process in the recommended solution as described in section 4 of https://www.ietf.org/id/draft-ietf-mpls-spring-entropy-label-04.txt has  already been a bit complex. For instance, the ingress needs to determine the minimum of the RLDs of transit LSRs of each LSP hierarchy when that LSP is the outermost one. How to do that in the inter-area/inter-level scenario? IMHO, the most practice way is to insert a single EL under the innermost LSP☺

[Bruno] Your text is quoted from a different draft. This is not the one that I’m commented on. IOW, "Signalling ELC using OSPF" is about the signaling of information. Not how it is used.
That being said, if we can’t agree on the exact meaning of RLD, draft-ietf-mpls-spring-entropy-label becomes somewhat useless. (e.g. LSR LB based on the IP header, so don’t care about the EL)

Best regards,
Xiaohu

Thanks,
Acee





Thanks,
Regards,
--Bruno

From: OSPF [mailto:[e-mail]] On Behalf Of Acee Lindem (acee)
Sent: Saturday, November 05, 2016 5:46 PM
To: OSPF WG List
Subject: [OSPF] WG Last Call for "Signalling ELC using OSPF"

This begins the WG last call for  "Signalling ELC using OSPF”, https://www.ietf.org/id/draft-ietf-ospf-mpls-elc-03.txt. Please review the document and send comments to this list prior to Nov 27th, 2016. Due to the IETF week, the last call period is going to be 3 weeks rather than usual 2 weeks.

Thanks,
Acee

_________________________________________________________________________________________________________________________



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.