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

On 28/02/2018 09:56, Alexander Vainshtein wrote:
>
> Resending with correct Himanshu address
>
> Regards,
>
> Sasha
>
> Office: +972-39266302
>
> Cell: +972-549266302
>
> Email: [email protected]
>
> *From:*Alexander Vainshtein
> *Sent:* Wednesday, February 28, 2018 11:01 AM
> *To:* 'Stewart Bryant' <[email protected]>
> *Cc:* [email protected]; [email protected]; 
> '[email protected]' <[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.
>

Hi Sasha

I did not see this before I did the upload this morning.

I am not sure if the text in RFC6790 is advisory or normative. My 
assumption is that it is an explanation for conceptual purposes and that 
if you have an equipment that can do the ELI copy it will be able to 
save a copy of the EL before popping it. How the forwarding engineer 
manages the transfer is really outside the scope of the draft anyway. 
However if we don't propose the copy DPI
will be back in the picture again.

Putting the EL after the PW label is a new design, and also impacts on 
GAL processing.

Forbidding EL on MS-PW limits the options, and given the number of 
MS-PWs out there I am reluctant to apply any constraints we can avoid.

Given it was implementation pragmatism that got us into this , I think 
we need to assume that whatever we say will be subject to further 
pragmatism, so we need to steer the implementers into a position where 
its easy for them to fix their code to remove this problem.

What do other's think?

- Stewart




> Regards,
>
> Sasha
>
> Office: +972-39266302
>
> Cell: +972-549266302
>
> 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
>
>     Cell:      +972-549266302
>
>     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.
> ___________________________________________________________________________

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