Subject: [PWE3] draft-muley-dutta-pwe3-redundancy-bit-02.txt

From: <[email-masked]>
Date: Fri, 4 Jan 2008 12:29:29 -0500

I am thinking about the operationalizing of the PWE ACTIVE/passive
stand-by function. Without mandating specific mechanisms the draft
should  state the need for certain functionalities to be considered in
the implementation of the draft.
 
I propose to include the following sections or similar:
 
5.4 Permanent active PWE designation.
The system COULD provide for the permanent designation of one PWe as
Active. After the switch over to stand-by and the recovery of the active
the traffic would switch over to the active again. The "flapping
prevention mechanism- algorithm" should be implemented. This function is
OPTIONAL. 
 
5.5 AC PWE status signaling
A system COULD signal to the AC side the status of the PWE - Active,
down. The existing OAM signaling mechanisms could used for this
function. The signaling should be done on the non-switching END -PE
ONLY. This function is OPTIONAL.
 
_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "AISSAOUI Mustapha" <[email-masked]>
Date: Fri, 4 Jan 2008 14:36:43 -0600

Roman,
thank you for the suggestions. See my comments below.
 
Regards,
Mustapha.

________________________________

	From: [email-masked]
[mailto:[email-masked]] 
	Sent: Friday, January 04, 2008 12:29 PM
	To: [email-masked]
	Subject: [PWE3] draft-muley-dutta-pwe3-redundancy-bit-02.txt 

	I am thinking about the operationalizing of the PWE
ACTIVE/passive stand-by function. Without mandating specific mechanisms
the draft  should  state the need for certain functionalities to be
considered in the implementation of the draft.

	5.4 Permanent active PWE designation.
	The system COULD provide for the permanent designation of one
PWe as Active. After the switch over to stand-by and the recovery of the
active the traffic would switch over to the active again. The "flapping
prevention mechanism- algorithm" should be implemented. This function is
OPTIONAL.  
	 
	MA> What you may be suggesting is the concept of Primary PW and
Secondary PW rather than an Active/Standby designation. Active and
Standby are states which change over time. However, a Primary PW is a PW
that is activated in preference to all other PWs when it is UP and shows
"Active" status at both endpoints. This also means that the system
should revert to the Primary PW when it comes back up from a failure.
	The draft refers to the concept of Primary and Secondary PWs and
we could expand as required.
	Let me know if my understanding is incorrect.    
	 
	5.5 AC PWE status signaling
	A system COULD signal to the AC side the status of the PWE -
Active, down. The existing OAM signaling mechanisms could used for this
function. The signaling should be done on the non-switching END -PE
ONLY. This function is OPTIONAL. 
	 
	MA> I assume you are referring to the ability of a PE/T-PE to
translate a fault notification received in a PW status bit to the AC
specific fault notification. This applies mostly to the operational
status bits, i.e., AC up/down, PW up/down, and PW not forwarding. This
is covered in draft-ietf-pwe3-oam-msg-map-05 and implementations should
support it independently of the PW redundancy capability.
	I am not sure I see the application for passing the
"active/standby" status to the AC. I appreciate if you could 
	elaborate.

---

From: <[email-masked]>
Date: Fri, 4 Jan 2008 16:07:26 -0500

Mustapha
thank you for the response...
 
On the first issue, let me tell you where it is coming from - when
provisioning redundant PWEs in the topology as below
 
[RT0]---------[RT1]
|
|---------------[RT2]

with one end of both PWEs on  RT0 and other ends  terminating on
separate RTs [RT1] and [RT2] - from the provisioning perspective it is
advantageous  to designate one PWe as primary and another as secondary.
This maybe  rather specific to having PWE ends on separate physical
systems - but not necessarily so.  It may be the case that the route
taken by the primary PWE is more optimal
-performance and capacity wise- than the secondary or backup and you
would rather keep the traffic on the primary if possible all the time. I
do not want to involve TE at this point.

On the second issue
Yes, there is an OAM mapping draft. But what I wanted to say that in
this particular case .. will this draft cover the stand by/ active
status for the PWE specifically on the RT1 and RT2 and not on the RT0.
So this would be one-sided signaling on RT1/2 on switchover, as I see
it, and signaling on RT0 only if both PWEs fail. For the RT1 RT2 CPE in
my view it is critical to be able to know the status of PWEs
asap. The customer may have his own status e2e hellos ( this would
require lets say something like BFD-kind with nx hello missed giving us
nx delay in notification ) and this maybe may be  good enough, but he
may not have it and the notofication  mechanism from the RT1/RT2 would
be nice to have - I guess it would lead to faster notofication of the
status of PWEs.
 
please let me know if I should elaborate further
 
Thx
roman 

From: AISSAOUI Mustapha [mailto:[email-masked]] 
Sent: Friday, January 04, 2008 3:37 PM
To: Krzanowski, Roman; [email-masked]
Subject: RE: [PWE3] draft-muley-dutta-pwe3-redundancy-bit-02.txt 

Roman,
 
Regards,
Mustapha.

---

From: "AISSAOUI Mustapha" <[email-masked]>
Date: Wed, 16 Jan 2008 10:39:47 -0600

Roman,
sorry for the late response. See more below.
 
Mustapha.

	From: [email-masked]
[mailto:[email-masked]] 
	Sent: Friday, January 04, 2008 4:07 PM
	To: AISSAOUI Mustapha; [email-masked]
	Subject: RE: [PWE3] draft-muley-dutta-pwe3-redundancy-bit-02.txt

	Mustapha
	 
	On the first issue, let me tell you where it is coming from -
when provisioning redundant PWEs in the topology as below
	 
	[RT0]---------[RT1]
	|
	|---------------[RT2]
	
	with one end of both PWEs on  RT0 and other ends  terminating on
separate RTs [RT1] and [RT2] - from the provisioning perspective it is
advantageous  to designate one PWe as primary and another as secondary.
This maybe  rather specific to having PWE ends on separate physical
systems - but not necessarily so.  It may be the case that the route
taken by the primary PWE is more optimal
	-performance and capacity wise- than the secondary or backup and
you would rather keep the traffic on the primary if possible all the
time. I do not want to involve TE at this point. 
	MA> This is what I was referring to below. You would then
designate which of the PWs that are part of the same redundancy set is
the primary. Note that there is also the concept of 'precedence' which
could also provisioned on the secondary PWs to select in which order
they should be activated when the primary fails if more than one
qualify. There are implementations which already provide these two
capabilities. 
	I have no issue adding the concept of provisioning one PW as
'primary' and others as 'secondary' to the text as long as it is clearly
marked as optional.

	On the second issue
	Yes, there is an OAM mapping draft. But what I wanted to say
that in this particular case .. will this draft cover the stand by/
active
	status for the PWE specifically on the RT1 and RT2 and not on
the RT0. So this would be one-sided signaling on RT1/2 on switchover, as
I see it, and signaling on RT0 only if both PWEs fail. For the RT1 RT2
CPE in my view it is critical to be able to know the status of PWEs
	asap. The customer may have his own status e2e hellos ( this
would require lets say something like BFD-kind with nx hello missed
giving us nx delay in notification ) and this maybe may be  good enough,
but he may not have it and the notofication  mechanism from the RT1/RT2
would be nice to have - I guess it would lead to faster notofication of
the status of PWEs. 
	MA> I am not aware of an existing AC OAM protocol that can
signal 'active/standby' state. This is currently done by protection
protocols such as LACP (used in LAG) and APS. Is that what you meant? 

	Thx
	roman 

	From: AISSAOUI Mustapha
[mailto:[email-masked]] 
	Sent: Friday, January 04, 2008 3:37 PM
	To: Krzanowski, Roman; [email-masked]
	Subject: RE: [PWE3] draft-muley-dutta-pwe3-redundancy-bit-02.txt

	Roman,
	 
	Regards,
	Mustapha.

		From: [email-masked]
[mailto:[email-masked]] 
		Sent: Friday, January 04, 2008 12:29 PM
		To: [email-masked]
		Subject: [PWE3]
draft-muley-dutta-pwe3-redundancy-bit-02.txt 

		 
		5.4 Permanent active PWE designation.
		The system COULD provide for the permanent designation
of one PWe as Active. After the switch over to stand-by and the recovery
of the active the traffic would switch over to the active again. The
"flapping prevention mechanism- algorithm" should be implemented. This
function is OPTIONAL.  
		 
		MA> What you may be suggesting is the concept of Primary
PW and Secondary PW rather than an Active/Standby designation. Active
and Standby are states which change over time. However, a Primary PW is
a PW that is activated in preference to all other PWs when it is UP and
shows "Active" status at both endpoints. This also means that the system
should revert to the Primary PW when it comes back up from a failure.
		The draft refers to the concept of Primary and Secondary
PWs and we could expand as required.
		Let me know if my understanding is incorrect.    
		 
		5.5 AC PWE status signaling
		A system COULD signal to the AC side the status of the
PWE - Active, down. The existing OAM signaling mechanisms could used for
this function. The signaling should be done on the non-switching END -PE
ONLY. This function is OPTIONAL. 
		 
		MA> I assume you are referring to the ability of a
PE/T-PE to translate a fault notification received in a PW status bit to
the AC specific fault notification. This applies mostly to the
operational status bits, i.e., AC up/down, PW up/down, and PW not
forwarding. This is covered in draft-ietf-pwe3-oam-msg-map-05 and
implementations should support it independently of the PW redundancy
capability.
		I am not sure I see the application for passing the
"active/standby" status to the AC. I appreciate if you could 
		elaborate.