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

Sasha,

Good point, as always. It’s not in -02, so we’re good there in this respect.

Cheers,
Andy


On Wed, Feb 28, 2018 at 8:26 AM, Alexander Vainshtein <
[email protected]> 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.
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302 <+972%203-926-6302>
>
> Cell:      +972-549266302 <+972%2054-926-6302>
>
> 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]> wrote:
>
> Resending with correct Himanshu address
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302 <+972%203-926-6302>
>
> Cell:      +972-549266302 <+972%2054-926-6302>
>
> 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.
>
>
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302 <+972%203-926-6302>
>
> Cell:      +972-549266302 <+972%2054-926-6302>
>
> Email:   [email protected]
>
>
>
> *From:* Stewart Bryant [mailto:[email protected]
> <[email protected]>]
> *Sent:* Monday, February 26, 2018 10:33 PM
> *To:* Alexander Vainshtein <[email protected]>
> *Cc:* [email protected]; [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 <+972%203-926-6302>
>
> Cell:      +972-549266302 <+972%2054-926-6302>
>
> Email:   [email protected]
>
>
>
> -----Original Message-----
> From: Pals [mailto:[email protected] <[email protected]>] On
> Behalf Of Stewart Bryant
> Sent: Friday, February 23, 2018 6:30 PM
> To: [email protected]; [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]
>
> 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