70 likes | 86 Views
Pseudo-Wire Protection. Mustapha Aissaoui, Florin Balus, Matthew Bocci, Hamid Ould-Brahim, Ping Pan IETF 66, Montreal. What we have learned since last IETF. PW protection may mean different things to different people: End-to-end path protection Congestion relief Multi-homed AC protection
E N D
Pseudo-Wire Protection Mustapha Aissaoui,Florin Balus, Matthew Bocci, Hamid Ould-Brahim, Ping Pan IETF 66, Montreal
What we have learned since last IETF • PW protection may mean different things to different people: • End-to-end path protection • Congestion relief • Multi-homed AC protection • Single-segment protection • Multi-segment protection • … • So, not only do we need protocol extension specification(s), we may need a framework/user document as well.
Key Changes from the previous version • Defined a Preference TLV and a Protection TLV • Preference TLV: provide the capability for PW’s to preempt each other in case of congestion • Protection TLV: provide the protection information for Path Protection • Removed 1:N protection option • This does not make sense after further discussion • Added more text on messaging processing
PW Path Protection • Protection TLV contains: • Reference ID: working and protection PW’s must be uniquely identified • Protection information: CAC-desired, fate-sharing working protection Reference ID is needed to know what to process on S-PE’s
PW Congestion Control • Preference TLV contains: • Preference level of the PW’s • Use setup and holding preference to control the preemption Preempt less important PW’s PW: high preference Send status back PW: low preference
Other protection cases… to be worked out in details Multi-homed PW Protection Individual PW’s PW Segment Protection Backup PW
Next Step • The current proposal supports • PW preemption • PW Path Protection • Like to • Iron out other issues • Work with the framework/user-case draft people • Gather more feedback from carriers • Make this into a WG Working Document THANK YOU ALL