Subject: Re: [PWE3] Missing operation in draft-ietf-pwe3-static-pw-status-00

From: [email-masked]
Date: Wed, 9 Jun 2010 15:00:16 +0800

Dear Luca,
I mean, if the PW is un-provisioned only on one PE, there is no T-LDP 
session for static PW to send label withdraw. Then it is necessary for the 
PE to send a PW status with 0x00000001 to adjacent PE.

For the graceful restart, I agree with Greg's comments, and only consider 
the case that control plane of a PE failed and NSF, separation of CP and 
DP. As I know, some vendors have provided L2VPN graceful restart based on 
RFC3478 on the precondition that CP and DP are separated. Of course, the 
graceful restart implementation is quite different between IP FEC and PW 
FEC, but this is an implementation issue.

Best Regards
Lizhong Jin

Luca Martini <[email-masked]> 
发件人:  [email-masked]
2010-06-09 02:55

收件人
[email-masked]
抄送
[email-masked], [email-masked], 
[email-masked], [email-masked]
主题
Re: [PWE3] Missing operation in draft-ietf-pwe3-static-pw-status-00

[email-masked] wrote:
>
> Hi Luca,
> For the static PW that using G-ACH to signal PW status, when the PW is 
> locally deleted by operator, it is necessary for the PE to send a PW 
> status TLV with the PW status code "0x00000001 - Pseudowire Not 
> Forwarding" to the adjacent PW on the static PW segment. This 
> operation is missing in the draft, and should be explicitly described.
What do you mean by "Deleted" ?
If the PW is un-provisioned, then you should probably send a label 
withdraw, not a status message.
If the PW is just taken out of service , then the above status code is 
correct.

>
> What's more, as I suggested at IETF 77 Anaheim, when LDP session is in 
> graceful restart state and can not be used for PW status signaling, it 
> is also valuable to for this PW to signal PW status through G-ACH. To 
> be clear, PW status signaling through G-ACH will only be enabled when 
> LDP session is in graceful restart state.
>
Currently Graceful restart for LDP has not been designed to support PWs. 
That does not mean it cannot be designed, to do so , but it might be 
quite detrimental to use graceful restart. For example , let's suppose 
that a PE reboots unexpectedly, in the PW case , the remote PE can 
switch immediately to a backup PW , and provide minimal service 
disruption. If we have graceful restart , the PE would have to wait for 
the expiration time to pass , which would cause a significant service 
interruption.

We cannot use the GACH just because the LDP session is in GR state. IT 
ould make sense that the GACH communication channel would not be 
operational as well.

What I think we need to do is write a separate document on how Graceful 
restart of the LDP or more in general other control protocols is to be 
handled by the PW.

Let me start by pointing out that LDP is not a controlling protocol in 
the case of a simple IP FEC. Hence the procedures for graceful restart 
in rfc3478 cannot be used as stated for PW FECs.
There was a draft (draft-jiang-pwe3-ldp-gr-00 
<https://datatracker.ietf.org/doc/draft-jiang-pwe3-ldp-gr/>) last year 
that attempted to approach this topic, but failed.

I believe that we need to answer several questions , for example:

Is Graceful restart even useful for PWs ?
How do we avoid extended traffic interruptions if we want to support 
Graceful restart for the PW FECs ?
Maybe we can just support a planned restart instead ?
Since LDP is the control protocol for PWs, but does not normally control 
the destination of IP packets, are the procedures in rfc3478 even going 
to work properly ?
Graceful restart is supposed to allow for faster convergence in an IP 
network, however do we even care about fast switch back of PWs ? ( in 
most cases local policy does nto even allow PWs to switch back to the 
main PW after a service interruption. )

Luca

> Best Regards
> Lizhong Jin
> --------------------------------------------------------

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.