Re: [Pals] 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:   [email protected]



-----Original Message-----
From: Pals <[email protected]> On Behalf Of Italo Busi
Sent: Tuesday, February 5, 2019 4:02 PM
To: [email protected]
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

[email protected]<mailto:[email protected]>

https://www.ietf.org/mailman/listinfo/pals

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________

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