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

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Stewart Bryant-2

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.

======

_______________________________________________
Pals mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/pals
Reply | Threaded
Open this post in threaded view
|

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

Alexander Vainshtein

Stewart and all,

Please see  some comments inline below.

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   [hidden email]

 

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

[hidden email]

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

_______________________________________________
Pals mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/pals
Reply | Threaded
Open this post in threaded view
|

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

Stewart Bryant-2

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

 

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

[hidden email]

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


_______________________________________________
Pals mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/pals
Reply | Threaded
Open this post in threaded view
|

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

Alexander Vainshtein

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

Email:   [hidden email]

 

From: Stewart Bryant [mailto:[hidden email]]
Sent: Monday, February 26, 2018 10:33 PM
To: Alexander Vainshtein <[hidden email]>
Cc: [hidden email]; [hidden email]
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:   [hidden email]

 

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

[hidden email]

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
[hidden email]
https://www.ietf.org/mailman/listinfo/pals
Reply | Threaded
Open this post in threaded view
|

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

Alexander Vainshtein
In reply to this post by Stewart Bryant-2

Resending with correct Himanshu address

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   [hidden email]

 

From: Alexander Vainshtein
Sent: Wednesday, February 28, 2018 11:01 AM
To: 'Stewart Bryant' <[hidden email]>
Cc: [hidden email]; [hidden email]; '[hidden email]' <[hidden email]>
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 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

Email:   [hidden email]

 

From: Stewart Bryant [[hidden email]]
Sent: Monday, February 26, 2018 10:33 PM
To: Alexander Vainshtein <[hidden email]>
Cc: [hidden email]; [hidden email]
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:   [hidden email]

 

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

[hidden email]

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
[hidden email]
https://www.ietf.org/mailman/listinfo/pals
Reply | Threaded
Open this post in threaded view
|

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

Andrew G. Malis-3
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 <[hidden email]> wrote:

Resending with correct Himanshu address

 

Regards,

Sasha

 

Office: <a href="tel:+972%203-926-6302" value="+97239266302" target="_blank">+972-39266302

Cell:      <a href="tel:+972%2054-926-6302" value="+972549266302" target="_blank">+972-549266302

Email:   [hidden email]

 

From: Alexander Vainshtein
Sent: Wednesday, February 28, 2018 11:01 AM
To: 'Stewart Bryant' <[hidden email]>
Cc: [hidden email]; [hidden email]; '[hidden email]' <[hidden email]>
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 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: <a href="tel:+972%203-926-6302" value="+97239266302" target="_blank">+972-39266302

Cell:      <a href="tel:+972%2054-926-6302" value="+972549266302" target="_blank">+972-549266302

Email:   [hidden email]

 

From: Stewart Bryant [[hidden email]]
Sent: Monday, February 26, 2018 10:33 PM
To: Alexander Vainshtein <[hidden email]>
Cc: [hidden email]; [hidden email]
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: <a href="tel:+972%203-926-6302" value="+97239266302" target="_blank">+972-39266302

Cell:      <a href="tel:+972%2054-926-6302" value="+972549266302" target="_blank">+972-549266302

Email:   [hidden email]

 

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

[hidden email]

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
[hidden email]
https://www.ietf.org/mailman/listinfo/pals
Reply | Threaded
Open this post in threaded view
|

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

Alexander Vainshtein

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

Email:   [hidden email]

 

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

Resending with correct Himanshu address

 

Regards,

Sasha

 

Office: <a href="tel:&#43;972%203-926-6302" target="_blank">+972-39266302

Cell:      <a href="tel:&#43;972%2054-926-6302" target="_blank">+972-549266302

Email:   [hidden email]

 

From: Alexander Vainshtein
Sent: Wednesday, February 28, 2018 11:01 AM
To: 'Stewart Bryant' <[hidden email]>
Cc: [hidden email]; [hidden email]; '[hidden email]' <[hidden email]>
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 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: <a href="tel:&#43;972%203-926-6302" target="_blank">+972-39266302

Cell:      <a href="tel:&#43;972%2054-926-6302" target="_blank">+972-549266302

Email:   [hidden email]

 

From: Stewart Bryant [[hidden email]]
Sent: Monday, February 26, 2018 10:33 PM
To: Alexander Vainshtein <[hidden email]>
Cc: [hidden email]; [hidden email]
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: <a href="tel:&#43;972%203-926-6302" target="_blank"> +972-39266302

Cell:      <a href="tel:&#43;972%2054-926-6302" target="_blank"> +972-549266302

Email:   [hidden email]

 

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

[hidden email]

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
[hidden email]
https://www.ietf.org/mailman/listinfo/pals
Reply | Threaded
Open this post in threaded view
|

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

Andrew G. Malis-3
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 <[hidden email]> 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: <a href="tel:+972%203-926-6302" value="+97239266302" target="_blank">+972-39266302

Cell:      <a href="tel:+972%2054-926-6302" value="+972549266302" target="_blank">+972-549266302

Email:   [hidden email]

 

From: Andrew G. Malis [mailto:[hidden email]]
Sent: Wednesday, February 28, 2018 3:14 PM
To: Alexander Vainshtein <[hidden email]>
Cc: Stewart Bryant <[hidden email]>; [hidden email]; [hidden email]; [hidden email]


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 <[hidden email]> wrote:

Resending with correct Himanshu address

 

Regards,

Sasha

 

Office: <a href="tel:+972%203-926-6302" target="_blank">+972-39266302

Cell:      <a href="tel:+972%2054-926-6302" target="_blank">+972-549266302

Email:   [hidden email]

 

From: Alexander Vainshtein
Sent: Wednesday, February 28, 2018 11:01 AM
To: 'Stewart Bryant' <[hidden email]>
Cc: [hidden email]; [hidden email]; '[hidden email]' <[hidden email]>
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 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: <a href="tel:+972%203-926-6302" target="_blank">+972-39266302

Cell:      <a href="tel:+972%2054-926-6302" target="_blank">+972-549266302

Email:   [hidden email]

 

From: Stewart Bryant [[hidden email]]
Sent: Monday, February 26, 2018 10:33 PM
To: Alexander Vainshtein <[hidden email]>
Cc: [hidden email]; [hidden email]
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: <a href="tel:+972%203-926-6302" target="_blank"> +972-39266302

Cell:      <a href="tel:+972%2054-926-6302" target="_blank"> +972-549266302

Email:   [hidden email]

 

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

[hidden email]

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
[hidden email]
https://www.ietf.org/mailman/listinfo/pals
Reply | Threaded
Open this post in threaded view
|

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

Stewart Bryant-2
In reply to this post by Alexander Vainshtein



On 28/02/2018 09:56, Alexander Vainshtein wrote:

Resending with correct Himanshu address

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   [hidden email]

 

From: Alexander Vainshtein
Sent: Wednesday, February 28, 2018 11:01 AM
To: 'Stewart Bryant' [hidden email]
Cc: [hidden email]; [hidden email]; '[hidden email]' [hidden email]
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 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:   [hidden email]

 

From: Stewart Bryant [[hidden email]]
Sent: Monday, February 26, 2018 10:33 PM
To: Alexander Vainshtein <[hidden email]>
Cc: [hidden email]; [hidden email]
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:   [hidden email]

 

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

[hidden email]

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
[hidden email]
https://www.ietf.org/mailman/listinfo/pals
Reply | Threaded
Open this post in threaded view
|

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

Stewart Bryant-2
In reply to this post by Alexander Vainshtein



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

 

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

Resending with correct Himanshu address

 

Regards,

Sasha

 

Office: <a href="tel:+972%203-926-6302" target="_blank" moz-do-not-send="true">+972-39266302

Cell:      <a href="tel:+972%2054-926-6302" target="_blank" moz-do-not-send="true">+972-549266302

Email:   [hidden email]

 

From: Alexander Vainshtein
Sent: Wednesday, February 28, 2018 11:01 AM
To: 'Stewart Bryant' <[hidden email]>
Cc: [hidden email]; [hidden email]; '[hidden email]' <[hidden email]>
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 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: <a href="tel:+972%203-926-6302" target="_blank" moz-do-not-send="true">+972-39266302

Cell:      <a href="tel:+972%2054-926-6302" target="_blank" moz-do-not-send="true">+972-549266302

Email:   [hidden email]

 

From: Stewart Bryant [[hidden email]]
Sent: Monday, February 26, 2018 10:33 PM
To: Alexander Vainshtein <[hidden email]>
Cc: [hidden email]; [hidden email]
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: <a href="tel:+972%203-926-6302" target="_blank" moz-do-not-send="true"> +972-39266302

Cell:      <a href="tel:+972%2054-926-6302" target="_blank" moz-do-not-send="true"> +972-549266302

Email:   [hidden email]

 

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

[hidden email]

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
[hidden email]
https://www.ietf.org/mailman/listinfo/pals