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

From: Stewart Bryant <[email-masked]>
Date: Fri, 23 Feb 2018 16:30:24 +0000

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.

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.

======

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 25 Feb 2018 08:20:50 +0000

Stewart and all,

Please see  some comments inline below.

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

Email:   [email-masked]

-----Original Message-----
From: Pals [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Friday, February 23, 2018 6:30 PM
To: [email-masked]; [email-masked]
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.

- 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)". 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.

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

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"?

======

_______________________________________________

Pals mailing list

[email-masked]<mailto:[email-masked]>

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.
___________________________________________________________________________

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 26 Feb 2018 20:33:13 +0000

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
>
> 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.

> *//*
> */[[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?

> 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

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

> *//*
> [email-masked] <mailto:[email-masked]>
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 28 Feb 2018 09:00:58 +0000

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
Cell:      +972-549266302

From: Stewart Bryant [mailto:[email-masked]]
Sent: Monday, February 26, 2018 10:33 PM
To: Alexander Vainshtein <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations

Hi Sasha

Stewart and all,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

Email:   [email-masked]<mailto:[email-masked]>

-----Original Message-----
From: Pals [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Friday, February 23, 2018 6:30 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Pals] draft-ietf-pals-ethernet-cw Recommendations

- Stewart

# Recommendation

[[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:

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 have added the following to the end of the # Equal Cost Multi-path (ECMP) section:

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?

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.

# Recommendation

then where the both ingress and egress PEs support RFC6790 {{RFC6790}} (ELI)

is to avoid DPI based ECMP in the network, the Entropy Label value SHOULD be

Any comments received after the upload but before cutoff I will try my best to
incorporate.

- Stewart

======

Pals mailing list

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 28 Feb 2018 09:56:57 +0000

Resending with correct Himanshu address

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Alexander Vainshtein
Sent: Wednesday, February 28, 2018 11:01 AM
To: 'Stewart Bryant' <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]' <[email-masked]>
Subject: RE: [Pals] draft-ietf-pals-ethernet-cw Recommendations

Stewart,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Stewart Bryant [mailto:[email-masked]]
Sent: Monday, February 26, 2018 10:33 PM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations

Hi Sasha

Stewart and all,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: Pals [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Friday, February 23, 2018 6:30 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Pals] draft-ietf-pals-ethernet-cw Recommendations

- Stewart

# Recommendation

The text now says:

# Recommendation

- Stewart

======

Pals mailing list

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 28 Feb 2018 08:13:31 -0500

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-masked]> wrote:

> Office: +972-39266302 <+972%203-926-6302>
>
> Cell:      +972-549266302 <+972%2054-926-6302>
>
> *From:* Alexander Vainshtein
> *Sent:* Wednesday, February 28, 2018 11:01 AM
> *To:* 'Stewart Bryant' <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; '
> [email-masked]' <[email-masked]>
> *Subject:* RE: [Pals] draft-ietf-pals-ethernet-cw Recommendations
>
>
>
> Stewart,
>
> 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:
>
> 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>
>
> *From:* Stewart Bryant [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Monday, February 26, 2018 10:33 PM
> *To:* Alexander Vainshtein <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [Pals] draft-ietf-pals-ethernet-cw Recommendations
>
>
>
> Hi Sasha
>
> Please see  some comments *inline below*.
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302 <+972%203-926-6302>
>
> Cell:      +972-549266302 <+972%2054-926-6302>
>
> From: Pals [mailto:[email-masked] <[email-masked]>] On
> Behalf Of Stewart Bryant
> I have edited the Recommendations section of draft-ietf-pals-ethernet-cw.
> Hopefully, I have correctly reflected our discussion at the last IETF.
>
>
>
> 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.*
>
>
>
> 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
> *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.*
>
>
> *[[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*
>
>
> 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*”?*
>
>
> [email-masked]

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 28 Feb 2018 13:26:35 +0000

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
Cell:      +972-549266302

From: Andrew G. Malis [mailto:[email-masked]]
Sent: Wednesday, February 28, 2018 3:14 PM
To: Alexander Vainshtein <[email-masked]>
Cc: Stewart Bryant <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>

From: Alexander Vainshtein
Sent: Wednesday, February 28, 2018 11:01 AM
To: 'Stewart Bryant' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Pals] draft-ietf-pals-ethernet-cw Recommendations

Stewart,

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

Hi Sasha

Stewart and all,

Regards,

Sasha

Office: +972-39266302<tel:+972%203-926-6302>

Cell:      +972-549266302<tel:+972%2054-926-6302>

-----Original Message-----
From: Pals [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Friday, February 23, 2018 6:30 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Pals] draft-ietf-pals-ethernet-cw Recommendations

- Stewart

# Recommendation

[[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)”.

The text now says:

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”?

# Recommendation

- Stewart

======

Pals mailing list

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 28 Feb 2018 08:49:49 -0500

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-masked]> wrote:

> 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
>
>
>
> *From:* Andrew G. Malis [mailto:[email-masked]]
> *Sent:* Wednesday, February 28, 2018 3:14 PM
> *Cc:* Stewart Bryant <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 28 Feb 2018 14:25:26 +0000

On 28/02/2018 09:56, Alexander Vainshtein wrote:
> *From:*Alexander Vainshtein
> *Cc:* [email-masked]; [email-masked]; 
> [email-masked]' <[email-masked]>
> 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
>
> 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

> <mailto:[email-masked]>
>
> *From:*Stewart Bryant [mailto:[email-masked]]
> *To:* Alexander Vainshtein <[email-masked] 
> <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>; 
> [email-masked] 
> <mailto:[email-masked]>
>     <mailto:[email-masked]>
>
>     To: [email-masked] <mailto:[email-masked]>;
>     [email-masked]
>     <mailto:[email-masked]>
>     draft-ietf-pals-ethernet-cw. Hopefully, I have correctly reflected
>     our discussion at the last IETF.
>
>     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./*
>
>     */[[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:
>
>     */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./*
>
>
>     */[[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/*
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 28 Feb 2018 14:43:57 +0000

On 28/02/2018 13:26, Alexander Vainshtein wrote:
> 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

> *From:*Andrew G. Malis [mailto:[email-masked]]
> 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-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Office: +972-39266302 <tel:+972%203-926-6302>
>
>     Cell: +972-549266302 <tel:+972%2054-926-6302>
>
>     *To:* 'Stewart Bryant' <[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>' <[email-masked]
>     <mailto:[email-masked]>>
>     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
>     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>
>
>     *From:* Stewart Bryant [mailto:[email-masked]]
>         Office: +972-39266302 <tel:+972%203-926-6302>
>
>         Cell: +972-549266302 <tel:+972%2054-926-6302>
>
>         draft-ietf-pals-ethernet-cw. Hopefully, I have correctly
>         reflected our discussion at the last IETF.
>
>         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:
>
>         different directions of the PW? If not (as I sincerely hope),
>         this should be stated explicitly/*
>
>
>         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*/”?/*
>
>
>     ingress