Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations

On 28/02/2018 13:26, Alexander Vainshtein wrote:
>
> Andy,
>
> This copying operation is exactly what looks problematic to me.
>
> From my POV, when an MPLS LER pops a label it forgets its value. Of 
> course, there is use case of “context labels” that define the 
> context-specific label space for the next label, but this is hardly 
> the case for ELI/EL.
>
> IMHO requesting an egress LER to store the popped label (actually, a 
> pair of labels) and to copy them into the new LSP for which it acts as 
> an ingress LER is non-standard (not from the POV of the general MPLS 
> architecture and not from the POV of ELI/EL). Therefore implementing 
> this mechanism with off-the-shelf HW (that typically supports the DP 
> behavior as defined in the appropriate RFCs) may be quite challenging 
> if not outright impossible.
>

So I think that there are two cases:

The EL gets popped before the S-PE gets the packet in which case that is 
the end of ECMP support for this PW (hopefully - because we know what 
happens next otherwise). or
The EL is there, and is received by an interface that that is configured 
to do this type of S-PE processing, in which case it is a small change 
to save the EL and physically or logically saves the ELI in case the 
packet is switched rather than terminated.

On h/w that cannot do EL propagation FAT is the only method that works 
across an S-PE.

- Stewart

> Regards,
>
> Sasha
>
> Office: +972-39266302
>
> Cell: +972-549266302
>
> Email: [email protected]
>
> *From:*Andrew G. Malis [mailto:[email protected]]
> *Sent:* Wednesday, February 28, 2018 3:14 PM
> *To:* Alexander Vainshtein <[email protected]>
> *Cc:* Stewart Bryant <[email protected]>; [email protected]; 
> [email protected]; [email protected]
> *Subject:* Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations
>
> Sasha,
>
> How about if the draft says that for a MS-PW, if both a tunnel LSP and 
> the next tunnel LSP both support EL/ELI, then the Entropy Label should 
> be copied. The reasoning is that we would like to avoid ECMP being 
> improperly calculated by an intermediate S-PE. We do realize that if 
> one of the tunnel LSPs doesn’t support EL/ELI, then there’s not much 
> we can do in that case if the FAT label isn’t being used. But if 
> EL/ELI isn’t available end-to-end, then the FAT label should be used.
>
> Cheers,
>
> Andy
>
> On Wed, Feb 28, 2018 at 4:56 AM, Alexander Vainshtein 
> <[email protected] 
> <mailto:[email protected]>> wrote:
>
>     Resending with correct Himanshu address
>
>     Regards,
>
>     Sasha
>
>     Office: +972-39266302 <tel:+972%203-926-6302>
>
>     Cell: +972-549266302 <tel:+972%2054-926-6302>
>
>     Email: [email protected]
>     <mailto:[email protected]>
>
>     *From:* Alexander Vainshtein
>     *Sent:* Wednesday, February 28, 2018 11:01 AM
>     *To:* 'Stewart Bryant' <[email protected]
>     <mailto:[email protected]>>
>     *Cc:* [email protected] <mailto:[email protected]>;
>     [email protected]
>     <mailto:[email protected]>; '[email protected]
>     <mailto:[email protected]>' <[email protected]
>     <mailto:[email protected]>>
>     *Subject:* RE: [Pals] draft-ietf-pals-ethernet-cw Recommendations
>
>     Stewart,
>
>     Lots of thanks for a prompt response and apologies for my delay.
>
>     I have a problem with the following proposed text:
>
>     the Entropy Label value SHOULD be calculated at ingress PE where
>     there is more payload context, and copied from ingress to egress
>     LSP at an S-PE
>
>     From my POV, this text contradicts the definition of the data
>     plane handling of ELI and EL as defined in Section 4.1 of RFC 6790
>     <https://tools.ietf.org/html/rfc6790> that says:
>
>        If an ingress LSR X chooses to impose an EL, then Y will receive a
>
>        tunnel termination packet with label stack <TL, ELI, EL> <remaining
>
>        packet header>.  Y recognizes TL as the label it distributed to its
>
>        upstream for the tunnel and pops it.  (Note that TL may be the
>
>        implicit null label, in which case it doesn't appear in the label
>
>        stack.) Y then recognizes the ELI and pops two labels: the ELI and
>
>        the EL.  Y then processes the remaining packet header as normal
>
>     I.e., copying the pair {ELI, EL} from the terminated tunnel LSP to
>     the another tunnel LSP is not, IMHO, allowed by this definition –
>     among other things, because the tail-end of the next tunnel LSP
>     did not necessarily signal its ability to support EL.
>
>     This actually matches Himanshu’s comments on the PALS mailing
>     list. The only difference between his position and mine was that
>     he suggested to use EL/ELI at the PW layer (and not at the tunnel
>     LSP layer as proposed in the draft) while I simply stated that
>     EL/ELI cannot be used with MS-PWs.
>
>     Regards,
>
>     Sasha
>
>     Office: +972-39266302 <tel:+972%203-926-6302>
>
>     Cell: +972-549266302 <tel:+972%2054-926-6302>
>
>     Email: [email protected]
>     <mailto:[email protected]>
>
>     *From:* Stewart Bryant [mailto:[email protected]]
>     *Sent:* Monday, February 26, 2018 10:33 PM
>     *To:* Alexander Vainshtein <[email protected]
>     <mailto:[email protected]>>
>     *Cc:* [email protected] <mailto:[email protected]>;
>     [email protected]
>     <mailto:[email protected]>
>     *Subject:* Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations
>
>     Hi Sasha
>
>     Thank you for the comments.
>
>     Please see inline which are reflected in the candidate version -02
>
>     On 25/02/2018 08:20, Alexander Vainshtein wrote:
>
>         Stewart and all,
>
>         Please see  some comments */inline below/*.
>
>         Regards,
>
>         Sasha
>
>         Office: +972-39266302 <tel:+972%203-926-6302>
>
>         Cell: +972-549266302 <tel:+972%2054-926-6302>
>
>         Email: [email protected]
>         <mailto:[email protected]>
>
>         -----Original Message-----
>         From: Pals [mailto:[email protected]] On Behalf Of Stewart
>         Bryant
>         Sent: Friday, February 23, 2018 6:30 PM
>         To: [email protected] <mailto:[email protected]>;
>         [email protected]
>         <mailto:[email protected]>
>         Subject: [Pals] draft-ietf-pals-ethernet-cw Recommendations
>
>         I have edited the Recommendations section of
>         draft-ietf-pals-ethernet-cw. Hopefully, I have correctly
>         reflected our discussion at the last IETF.
>
>         Any comments before I upload a new version of the draft?
>
>         - Stewart
>
>         # Recommendation
>
>         The ambiguity between an MPLS payload that is a Ethernet PW
>         and one that is an IP packet is resolved when the Ethernet PW
>         control word is used. This document updates RFC4448
>         {{RFC4448}} to state that where both both the ingress PE and
>         the egress PE support the Ethernet pseudowire control word,
>         then the CW MUST be used.*/[[Sasha]] Support./*
>
>         Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and
>         both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW)
>
>         */[[Sasha]] Does this imply that ELI can be used if supported
>         by the ingress PE even if the egress PE (or the first S-PE in
>         the case of a MS-PW) did not indicate its support? This seems
>         to contradict the text in Section 5 “Equal-Cost Multipath
>         (ECMP)”. /*
>
>
>     I think I was using the text that came out of the last PALS
>     meeting, and I did not check it carefully enough. You are right,
>     both need to support which ever feature is being used
>     to support ECMP.
>
>
>     The text now says:
>
>     Where ECMP of Ethernet PW traffic is required, then where the both
>     ingress and egress PEs support RFC6790 {{RFC6790}} (ELI)
>     or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW),
>     then either method may be used. The use of both methods on the same
>     PW is not normally necessary and should be avoided unless
>     circumstances require it.
>     In the case of multi-segment PWs, if ELI is used then it should be
>     used on every segment of the PW.
>
>     However in thinking about it we could have two PE's that only support
>     FAT and an SR core with a stack reach that did not allow the LSR's to
>     see the FAT label. So we might have to use both. That is technically
>     permitted in the text above, and am hoping that we can avoid
>     discussing
>     the corner cases in detail.
>
>         */And in any case it would be nice if the draft would explain
>         where the ELI and EL, if used, are located in the label stack
>         relative to the PW label. As I see it, there was no consensus
>         about that on the mailing list./*
>
>
>     I think that they are pushed one or more times after the PW label.
>
>     I have added the following to the end of the # Equal Cost
>     Multi-path (ECMP) section:
>
>     The PW label is pushed before the LSP label. As the EL/ELI labels are
>     part of the LSP layer rather than part of the PW layer, they are
>     pushed
>     after the PW label has been pushed.
>
>         and ECMP of Ethernet PW traffic is required then only one of
>         these methods should be used.
>
>         */[[Sasha]] Is it possible to use different methods in the
>         different directions of the PW? If not (as I sincerely hope),
>         this should be stated explicitly/*
>
>
>     So far we have been silent on that everywhere in the PW design. It
>     seems unlikely
>     that anyone would want to run asymmetrically since peer
>     capabilities are normally symmetric.
>     However I cannot see any reason to actively forbid the asymmetry.
>     I have not put text in on
>     this. Does anyone else think that it is necessary?
>
>         In the case of multi-segment PWs, if ELI is used then it
>         should be used on every segment of the PW.*/[[Sasha]] Does
>         “/*used*/”  above actually mean “/*regenerated by each S-PE
>         based on hashing of  Ethernet payload*/”?/*
>
>
>     The whole point of the draft is surely to avoid midpoint anything
>     guessing anything,
>     I have added the following to the end of the Recommendation text:
>
>     Since the reason for this recommendation
>     is to avoid DPI based ECMP in the network, the Entropy Label value
>     SHOULD be
>     calculated at ingress PE where there is more payload context, and
>     copied from ingress to egress LSP at an S-PE.
>
>     So the whole section now reads:
>
>     # Recommendation
>
>     The ambiguity between an MPLS payload that is a Ethernet PW and one
>     that is an IP packet is resolved when the Ethernet PW control word
>     is used. This document updates RFC4448 {{RFC4448}} to state that
>     where both both the ingress PE and the egress PE support the Ethernet
>     pseudowire control word, then the CW MUST be used.
>
>     Where the application ECMP to an Ethernet PW traffic is required,
>     then where the both ingress and egress PEs support RFC6790
>     {{RFC6790}} (ELI)
>     or both ingress and egress PEs support RFC6391 {{RFC6391}} (FAT PW),
>     then either method may be used. The use of both methods on the same
>     PW is not normally necessary and should be avoided unless
>     circumstances require it.
>     In the case of multi-segment PWs, if ELI is used then it should be
>     used on every segment of the PW.
>
>     Where the ingress PE supports RFC6790 {{RFC6790}} (ELI) and both
>     ingress
>     and egress PEs support RFC6391 {{RFC6391}} (FAT PW) and ECMP of
>     Ethernet
>     PW traffic is required, then only one of these methods should be used.
>     In the case of multi-segment PWs, if ELI is used then it should be
>     used on every segment of the PW. Since the reason for this
>     recommendation
>     is to avoid DPI based ECMP in the network, the Entropy Label value
>     SHOULD be
>     calculated at ingress PE where there is more payload context, and
>     copied from ingress to egress LSP at an S-PE.
>
>
>     Any further comments (anyone) before I upload.
>
>     Any comments received after the upload but before cutoff I will
>     try my best to
>     incorporate.
>
>     - Stewart
>
>         ======
>
>         _______________________________________________
>
>         Pals mailing list
>
>         [email protected] <mailto:[email protected]>
>
>         https://www.ietf.org/mailman/listinfo/pals
>
>
>         ___________________________________________________________________________
>
>         This e-mail message is intended for the recipient only and
>         contains information which is
>         CONFIDENTIAL and which may be proprietary to ECI Telecom. If
>         you have received this
>         transmission in error, please inform us by e-mail, phone or
>         fax, and then delete the original
>         and all copies thereof.
>         ___________________________________________________________________________
>
>
>     ___________________________________________________________________________
>
>     This e-mail message is intended for the recipient only and
>     contains information which is
>     CONFIDENTIAL and which may be proprietary to ECI Telecom. If you
>     have received this
>     transmission in error, please inform us by e-mail, phone or fax,
>     and then delete the original
>     and all copies thereof.
>     ___________________________________________________________________________
>
>
> ___________________________________________________________________________
>
> This e-mail message is intended for the recipient only and contains 
> information which is
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have 
> received this
> transmission in error, please inform us by e-mail, phone or fax, and 
> then delete the original
> and all copies thereof.
> ___________________________________________________________________________

_______________________________________________
Pals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pals