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

[Alexander Vainshtein <[e-mail]>]

Italo,
Was your last question was about migrating from a single-segment PW (without the CW) to the new solution (whatever it can be) with minimal impact on traffic?
This is a good question and the answer is implementation-specific I think.
But generally speaking you could configure your H-VPLS first (with the PWs set up and all), and then transfer your ACs in TP-1 and TP-2 from the original PW endpoints to the VSI in these devices in a coordinated management action. Such a transfer would be, of course, traffic-affecting, but, hopefully, the hits would be short enough. Not very complicated with proper network management I think.

My 2c,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]

From: Alexander Vainshtein
Sent: Wednesday, February 6, 2019 6:09 PM
To: 'Italo Busi' <[e-mail]>
Cc: [e-mail]; Shell Nakash <[e-mail]>; Michael Gorokhovsky <[e-mail]>
Subject: RE: Progressing draft-busi-pals-pw-cw-stitching-01

Italo,
Lots of thanks for a prompt response.
Please see answers to some of your questions inline below.

Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>

From: Italo Busi <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, February 5, 2019 7:37 PM
To: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Shell Nakash <[e-mail]<mailto:[e-mail]>>; Michael Gorokhovsky <[e-mail]<mailto:[e-mail]>>
Subject: RE: 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,[[Sasha]] It is definitely 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
[[Sasha]] My reading of the minutes (copied below for your convenience) is different:
Matthew: are you doing a label swap and adding a CW added?
Italo: Yes
Matthew:  The architecture doesn't allow it.  You are really stitching the two PWs together, after having gone to the Ethernet frame and then pushing the label stack with the CW.  This is in the architecture.  Change the draft to point to that.
Stewart: OK
Himanshu:  So this isn't a switching PE, it's a tear down and rebuild of the stack?
Stewart: Yes, with end to end OAM.
Himanshu: But everything terminates. It's not native, and not end to end if it terminates.
Matthew: Could do the OAM at the Ethernet level, but not VCCV
Stewart: OK there is some work to be done.
I.e., according to Matthew, what you have proposed does not match the MS-PW architecture, and you cannot run end-to-end PW OAM, only Ethernet OAM.

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[[Sasha]] From my POV, RFC 7079 strongly suggest that this was the case even 5.5 years ago. Since then I think the dominance of Ethernet PWs has only increased.

-          These Ethernet PWs are always single-homed (i.e., no dual-homing, no PW redundancy)[[Sasha]] H-VPLS can use PW redundancy as well I think. What can be achieved with such a mechanism depends on what you are looking for.

-          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[[Sasha]] You can use Ethernet service OAM link trace for that.

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

Italo

From: Alexander Vainshtein [mailto:[e-mail]]
Sent: martedì 5 febbraio 2019 17:02
To: Italo Busi <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Shell Nakash <[e-mail]<mailto:[e-mail]>>; Michael Gorokhovsky <[e-mail]<mailto:[e-mail]>>
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: [phone]

Cell:      [phone]

Email:   [e-mail]<mailto:[e-mail]>



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

[e-mail]<mailto:[e-mail]>

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