Re: [Pals] Progressing draft-busi-pals-pw-cw-stitching-01

Hi Sasha,

Thanks for your comment and for having brought to the table another alternative solution to the problem we are trying to solve

Using H-VPLS for p2p services, even if possible, is not something I really like/prefer/advocate

If the option to stitch the PW traffic at the Ethernet level is acceptable, I would prefer following the approach suggested by Matthew during IETF 103 which, as far as I have understood, is based on the MS-PW architecture rather than on H-VPLS architecture

In both cases, stitching the PW traffic at the Ethernet level would work if and only if:

-          Ethernet PWs are the only PWs being deployed without the CW

-          These Ethernet PWs are always single-homed (i.e., no dual-homing, no PW redundancy)

-          It is acceptable to use Ethernet OAM instead of VCCV to monitor an MS-PW end-to-end (between the two T-PEs), e.g., for locating which PW segment is failed when the MS-PW is down

A side question would also be how the network can be reconfigured without using the PW redundancy

Italo

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: martedì 5 febbraio 2019 17:02
To: Italo Busi <Italo.Busi@huawei.com>
Cc: pals@ietf.org; Shell Nakash <Shell.Nakash@ecitele.com>; Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>
Subject: RE: Progressing draft-busi-pals-pw-cw-stitching-01

Italo and all,

I suspect that the problem which this draft tries to solve admits a simple solution that is fully covered by existing standards: the Hierarchical VPLS as defined in Section 10 of RFC 4762<https://tools.ietf.org/html/rfc4762> could be used without any changes:

-          T-PE1 and T-PE2 would treat S-PE 1 as their VPLS peer, but would not be aware of each other

-          S-PE1 would treat T-PE1 as a spoke peer and T-PE2 - as its core peer. It would do degenerated MAC-based switching between the two PWs it terminates (whatever comes in via one PW goes out via into the other one)

-          T-PE1 and T-PE 2 will also do degenerated MAC-based switching

-          Usage of the CW would be negotiated separately between each pair of VPLS peers

-          MAC-based switching in all the PEs would be configured not to apply any policing on BUM traffic. If MAC learning can be turned off, it would also help

-          Ethernet service OAM (as per IEEE 802.1ag or ITU-T Y.1731 would be fully applicable.

What, if anything, did I miss? Is the situation when T-PE supports Ethernet PWs but does not support VPLS relevant in real deployments?

Regards, and lots of thanks in advance,

Sasha

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>

-----Original Message-----
From: Pals <pals-bounces@ietf.org<mailto:pals-bounces@ietf.org>> On Behalf Of Italo Busi
Sent: Tuesday, February 5, 2019 4:02 PM
To: pals@ietf.org<mailto:pals@ietf.org>
Subject: [Pals] Progressing draft-busi-pals-pw-cw-stitching-01

During IETF 103, draft-busi-pals-pw-cw-stitching-01 has been presented and discussed

We have received very valid technical comments that we think can be addressed in the future versions of the draft

One of the main outstanding comment is about whether the solution proposed in the draft is addressing a real need in deployed networks

The draft is proposing a solution that could resolve the issues described in RFC 8469 when PWs are deployed without the CW because an existing T-PE is not capable to insert the CW

It is worth noting, as outlined during the IETF 103 discussion, that we are considering only T-PEs which are not capable to insert the CW because of hardware limitations and not T-PEs that are capable to insert the CW but configured not to do so. In the latter case, the solution in RFC 8469 (recommending to enable the use of CW) seems sufficient

As outlined by Dave in the meeting notes, more analysis needs to be done on:

                1. the use cases where this function would be used e.g., mobile transport? Ethernet enterprise services? data center interconnect? etc.

                2. In these cases identified, how likely would it be where the TPE would not be upgraded?

Since these issues are related to existing network deployments and future/planned network upgrades, we would appreciate any input from operators about these questions

Thanks in advance

Italo (on behalf of co-authors)

_______________________________________________

Pals mailing list

Pals@ietf.org<mailto:Pals@ietf.org>

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