Subject: RE: Active/Standby Status Bit

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Mon, 6 Nov 2006 19:05:07 -0800

> -----Original Message-----
> From: AISSAOUI Mustapha [mailto:[email-masked]] 
> Sent: Monday, November 06, 2006 5:04 PM
> To: Luca Martini (lmartini)
> Cc: [email-masked]
> Subject: Active/Standby Status Bit
> 
> Luca,
> Here is the description of the "PW not forwarding" bit as per 
> RFC 4447:
> 
> "The presence of the lowest bit (PW Not Forwarding) acts only 
> as a generic failure indication when there is a link-down 
> event for which none of the other bits apply."
> 
> So, we still need a bit to indicate a failure which is not 
> explicilty indicated by the AC and PSN failure bits. A good 
> example of using this bit is when an LSP switches its path 
> and if the new path MTU does not match anymore that signaled 
> in the PW FEC, this bit is used to signal the remote PE. 
> There may be other types of failures which could use this bit.
> 
With respect to u-PE dual homing applications to two different n-PE
devices, it is still not clear to me why we cannot use "PW forwarding"
bit (since the MTU for the standby PW is already signaled between u-PE &
standby n-PE). If the problem is its definition as defined in RFC 4447,
then we can generalize its definition a bit more. However, if there is a
more fundamental problem, then lets elaborate on what that is.

-Ali

> I can only conclude that we need a separate bit for the 
> "Active/Standby"
> status.
> 
> Mustapha. 
>

---

From: "AISSAOUI Mustapha" <[email-masked]>
Date: Tue, 7 Nov 2006 12:57:04 -0600

Ali,
See below.

Mustapha. 

> From: Ali Sajassi (sajassi) [mailto:[email-masked]] 
> Sent: Monday, November 06, 2006 10:05 PM
> To: AISSAOUI Mustapha; Luca Martini (lmartini)
> Cc: [email-masked]
> Subject: RE: Active/Standby Status Bit
> 
>  
> 
> > Here is the description of the "PW not forwarding" bit as per RFC 
> > 4447:
> > 
> > "The presence of the lowest bit (PW Not Forwarding) acts only as a 
> > generic failure indication when there is a link-down event 
> for which 
> > none of the other bits apply."
> > 
> explicilty 
> > indicated by the AC and PSN failure bits. A good example of 
> using this 
> > bit is when an LSP switches its path and if the new path 
> MTU does not 
> > match anymore that signaled in the PW FEC, this bit is used 
> to signal 
> > the remote PE.
> With respect to u-PE dual homing applications to two 
> different n-PE devices, it is still not clear to me why we 
> cannot use "PW forwarding"
> bit (since the MTU for the standby PW is already signaled 
> between u-PE & standby n-PE). If the problem is its 
> definition as defined in RFC 4447, then we can generalize its 
> definition a bit more. However, if there is a more 
> fundamental problem, then lets elaborate on what that is.

MA> The MTU for tunnel LSP can change if the LSP path for the primay PW
or the secondary PW changes. If the new MTU value is lower than the one
signaled in the PW FEC iterface parameter field, an alarm should be
raised since the PE will drop packets on that PW. So, this is a fault
condition which we currently  signal using the "PW not forwarding bit".

When the PW is in standby state, there is no fault or alarms which are
generated. It just an indication to the remote PE to preferably not send
traffic over that PW.

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Tue, 7 Nov 2006 21:14:00 +0200

Mustapha, Ali and all,
After the yesterday presentation I have been under impression that, in the case of a dual-homed MTU-s, the status bit would only sirnal to the "standby" PE-r not to send its BUM traffic over the standby PW. 
 
Ali's text below seems to suggest that PE-r should not send ANY traffic over the "standby" PW.
 
Do I miss something? 
Or is it a real difference in interpretation (between, say, draft-muley and VPLS dual-homing)?
 
Regards,
                Sasha

________________________________

From: AISSAOUI Mustapha [mailto:[email-masked]]
Sent: Tue 11/7/2006 06:57
To: Ali Sajassi (sajassi)
Cc: [email-masked]
Subject: RE: Active/Standby Status Bit

Ali,
See below.

Mustapha.

---

From: "Dutta, Pranjal" <[email-masked]>
Date: Wed, 8 Nov 2006 01:01:11 +0530

Sasha,
                 Here is some clarifications. 
 
1) The draft proposed to block traffic at secondary PE-rs which is standby for the MTU-s. Now in H-VPLS if you see only BUM 
   traffic will reach secondary PE-rs. The unicast learned traffic will be be flowing to/from MTU-s only via primary/active PE-rs
 
2) In practical deployments in H-VPLS we might end up with control plane scalability issues if per PW   blocking/unblocking/ state change is done and so we do the same per PW group. So we are using the Group ID in FEC 128 or Grouping TLV in FEC 129 for per PW group state change with one single message.
 
Thanks,
Pranjal 

From: Sasha Vainshtein [mailto:[email-masked]]
Sent: Wed 11/8/2006 12:44 AM
To: AISSAOUI Mustapha; Ali Sajassi (sajassi)
Cc: [email-masked]
Subject: RE: Active/Standby Status Bit

Mustapha, Ali and all,

Do I miss something? 
 
Regards,
                Sasha

Ali,
See below.

Mustapha.

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Tue, 7 Nov 2006 22:37:07 +0200

Pranjal,
Thank you for a prompt response and clarification.
 
I am not completely sure that the secondary PE-r shall never send any known unicasts over the Spoke PW.
E.g., during the failure recovery process:

*	
	Originally, all the traffic for MTU-s is handled by the Pimary PE-r
*	
	After the failure all the traffic will be handled by the Secondary PE-r
*	
	Once the Primary Spoke recovers, MTI-S signals the Spoke to the Secondary PE-r as standby, but it still receives valid unicast frames for this MTU-s. Do you expect it to start dropping them immediately, or should it go on with forwarding them until while (presumably) withdrawing relevant MAC addresses?

Speaking in more generic terms:

1.	A regular PW architecture includes 3 entities:

	*	An attachment circuit
	*	A PW endpoint
	*	A Forwarder connecting one to the other in a 1:1 way

2.	In the PE-r case:

	*	The attachment circuit is, to the best of my understanding replaced by the Spoke PW
	*	The VSI acts as a many-to-many Forwarder.

3.	These (undrawn:-) diagrams lead me to the following question: which entity is going to interpret the Active/Standby signal? There are, IMHO, 3 options:

	*	It is interpreted by the (PSN-facing) PW endpoint. This could be the case in draft-muley but, IMHO, not in the H-VPLS case
	*	It is interpreted by the Spoke PW end point (applicable only for the H-VPLS case)
	*	It is interpreted by the Forwarder (allowing each forwarder to interpret it according to its specific nature and, IMHO, equally applicable to all cases).

Did I miss something?

Regards,

                    Sasha

From: Dutta, Pranjal [mailto:[email-masked]]
Sent: Tue 11/7/2006 07:31
To: Sasha Vainshtein; AISSAOUI Mustapha; Ali Sajassi (sajassi)
Cc: [email-masked]
Subject: RE: Active/Standby Status Bit

Sasha,

 
Thanks,
Pranjal 

Mustapha, Ali and all,

Do I miss something? 
 
Regards,
                Sasha

Ali,
See below.

Mustapha.

---

From: "Dutta, Pranjal" <[email-masked]>
Date: Wed, 8 Nov 2006 03:48:18 +0530

Hi Sasha,
                    Please refer my answers inline.
 
Regards,
Pranjal 

From: Sasha Vainshtein [mailto:[email-masked]]
Sent: Wed 11/8/2006 2:07 AM
To: Dutta, Pranjal; AISSAOUI Mustapha; Ali Sajassi (sajassi)
Cc: [email-masked]
Subject: RE: Active/Standby Status Bit

Pranjal,

*	

[Pranjal] In practical terms it makes more sense to make a PW/PW Group from Active to Standby state after sending the MAC address withdrawal so that unicast traffic gets relearned over the "latest" active PW. IMHO I would prefer to leave it as implementation specific and keep it open. 

	*	An attachment circuit 
	*	A PW endpoint 

2.	In the PE-r case: 

	*	It is interpreted by the (PSN-facing) PW endpoint. This could be the case in draft-muley but, IMHO, not in the H-VPLS case 
	*	It is interpreted by the Spoke PW end point (applicable only for the H-VPLS case) 
	*	
	*	[Pranjal] The draft-pdutta-standby deals this application. In H-VPLS we need to block 
	*	             the spoke PW between MTU-s and PE-rs. We have also included a Ring Topology in the    
	*	             draft where we require PW between two PEs or can have multi-homing as well(requirement  
	*	            specified in section 5.2 draft-ietf-l2vpn-vpls-bridge-interop-xx).The mechanism is generic  
	*	             which can be extended to any application that may require to block a standby PW. draft- 
	*	             muley discussed about other applications of SS-PW and  MS-PW where standby PW 
	*	             blocking is required with standby bit. 
	*	
	*	It is interpreted by the Forwarder (allowing each forwarder to interpret it according to its specific nature and, IMHO, equally applicable to all cases).
	*	
	*	[Pranjal] In H-VPLS we have left it open to implementation on HOW to block a PW. The standby bit
	*	is to block the PW endpoint. In H-VPLS case additional actions can be taken to assist the forwarder according to its specific nature. (e.g like we have specified in last paragraph in section 6.3 in the draft that MAC flushing by the PE-rs itself may be possible as PE-rs is now notified about standby/active state)

Did I miss something?

Regards,

                    Sasha

Sasha,

 
Thanks,
Pranjal 

Mustapha, Ali and all,

Do I miss something? 
 
Regards,
                Sasha

Ali,
See below.

Mustapha.