Subject: [PWE3] draft-jin-pwe3-cbit-negotiation-01

From: Raymond Key <[email-masked]>
Date: Fri, 19 Nov 2010 20:53:41 +1100

Hi PWE3 working group,
 
In the recent IETF79, we have presented the draft "Pseudowire Control Word Negotiation Mechanism Analysis and Update"  
http://tools.ietf.org/html/draft-jin-pwe3-cbit-negotiation-01 
 
This draft describes the problem of control word negotiation mechanism specified in RFC4447. Based on the problem analysis, possible solutions and their potential shortcomings are also discussed.
 
The authors would like to have more feedback from the mailing list before working on the next version. Grateful if you could review the document and post comments on the mailing list.
 
Thanks,
Raymond Key

---

From: Sami Boutros <[email-masked]>
Date: Mon, 22 Nov 2010 21:10:32 -0800

I personally like option 1 in this draft, describing how to re-enable 
control word via dynamic LDP signaling.

However, you would need to clarify the steps more..
saying in step 3 that PE2 MUST send a label request and in step 5 
that PE1 MUST respond to the label request with the configured CW 
setting on PE1 which was set, as well in step 6 PE2 MUST wait for PE1 
label binding before sending it's label binding with CW set.

As well, it may be good extending the flow chart described in 
appendix A in rfc 4447 with option 1.

Not sure, if it is worth mentioning the other options since they have issues.

Option 2, how will we be able to re-enable CW? isn't that the issue 
we are trying to fix?

Option 3, This is avoiding to solve the problem.

Option 4, I don't think this will fly.

Thanks,

Sami
At 01:53 AM 11/19/2010, Raymond Key wrote:
>Hi PWE3 working group,
>
>In the recent IETF79, we have presented the draft "Pseudowire 
>Control Word Negotiation Mechanism Analysis and Update"
><http://tools.ietf.org/html/draft-jin-pwe3-cbit-negotiation-01>http://tools.ietf.org/html/draft-jin-pwe3-cbit-negotiation-01 
>
>
>This draft describes the problem of control word negotiation 
>mechanism specified in RFC4447. Based on the problem analysis, 
>possible solutions and their potential shortcomings are also discussed.
>
>The authors would like to have more feedback from the mailing list 
>before working on the next version. Grateful if you could review the 
>document and post comments on the mailing list.
>
>Thanks,
>Raymond Key
>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pwe3

---

From: Sami Boutros <[email-masked]>
Date: Tue, 23 Nov 2010 02:30:19 -0800

Hi PWE3 working group,

We have presented "PW Stitching Procedures in MPLS-TP Networks" at 
IETF78 and 79
http://tools.ietf.org/html/draft-boutros-pwe3-mpls-tp-ms-pw-00

This informational draft extends the PW stitching procedures defined 
in "draft-ietf-pwe3-segmented-pw-18.txt".
It describes the PW status exchange when connecting 2 PW segments 
with one or both of them are static running inband PW OAM messages 
specified in "draft-ietf-pwe3-static-pw-status-00.txt".
It describes what PW status value to use when (1) one PW segment is 
being locked using (LI) or put in Loopback (LB) or (2) when the 
MPLS-TP LSP carrying the PW segment is being locked or put in LoopBack.
Lock Instruct (LI) and Loopback (LB) OAM functions for MPLS-TP 
networks specified in"draft-ietf-mpls-tp-li-lb-00.txt".

The authors are seeking more feedback from the mailing list, and 
would be grateful if you could review the document and post comments 
on the mailing list.

Thanks,

Sami

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 23 Nov 2010 20:13:26 -0600

Hi Raymond,

Regarding step 5 in Option 1, shouldn't the SHOULD be a MUST? If the
locally configured CW parameter isn't used when PE1 sends label mapping,
we're back to square 1 right?

Regards,

Reshad.

     5. PE1 will send label mapping message with Cbit=1 again to PE2

        (Note: PE1 SHOULD send label mapping with locally configured CW

         parameter).

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Raymond Key
Sent: Friday, November 19, 2010 4:54 AM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: [PWE3] draft-jin-pwe3-cbit-negotiation-01

Hi PWE3 working group,
 
In the recent IETF79, we have presented the draft "Pseudowire Control
Word Negotiation Mechanism Analysis and Update"  
http://tools.ietf.org/html/draft-jin-pwe3-cbit-negotiation-01 
 
This draft describes the problem of control word negotiation mechanism
specified in RFC4447. Based on the problem analysis, possible solutions
and their potential shortcomings are also discussed.

Thanks,
Raymond Key

---

From: [email-masked]
Date: Wed, 24 Nov 2010 11:20:10 +0800

Hi Reshad,
See in line below for my comments.

Thanks
Lizhong

"Reshad Rahman (rrahman)" <[email-masked]> wrote on 2010-11-24 
10:13:26:

> Hi Raymond,
> 
> Regarding step 5 in Option 1, shouldn’t the SHOULD be a MUST? 
[Lizhong] Yes, should be a MUST, and also for step 3 as Sami pointed out.

> If the
> locally configured CW parameter isn’t used when PE1 sends label 
> mapping, we’re back to square 1 right?
[Lizhong] Yes, then it should be specified that the PE1 MUST send label 
mapping with locally configured CW parameter. I believe this is 
reasonable.

[email-masked]
> document and post comments on the mailing list.

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

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 24 Nov 2010 06:12:59 -0600

I agree with Sami. Maybe the other options should be in appendix with an
explanation of why they were not chosen?

Regards,

Reshad.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sami Boutros (sboutros)
Sent: Tuesday, November 23, 2010 12:11 AM
To: Raymond Key; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [PWE3] draft-jin-pwe3-cbit-negotiation-01

However, you would need to clarify the steps more..
saying in step 3 that PE2 MUST send a label request and in step 5 that
PE1 MUST respond to the label request with the configured CW setting on
PE1 which was set, as well in step 6 PE2 MUST wait for PE1 label binding
before sending it's label binding with CW set.

As well, it may be good extending the flow chart described in appendix A
in rfc 4447 with option 1.

Not sure, if it is worth mentioning the other options since they have
issues.

Option 2, how will we be able to re-enable CW? isn't that the issue we
are trying to fix?

Thanks,

Sami

Hi PWE3 working group,

 
 
Thanks,
Raymond Key

---

From: Ed <[email-masked]>
Date: Thu, 25 Nov 2010 11:47:30 +1100

Hi Raymond,

Option 1 seems to be simply to resignal the FEC - with the corresponding
traffic forwarding impact. Can PE2 send a new label mapping with cbit=1 be
sent without requiring label withdrawal message and label request message,
for example?

Also, does the the changing of the control word from PREFERRED to
non-PREFERRED need to be considered as well?

Thanks

Regards,
Edward

On Wed, Nov 24, 2010 at 11:12 PM, Reshad Rahman (rrahman) <[email-masked]
> wrote:

> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Sami Boutros (sboutros)
> *Sent:* Tuesday, November 23, 2010 12:11 AM
> *To:* Raymond Key; [email-masked]
>
> *Cc:* [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: [PWE3] draft-jin-pwe3-cbit-negotiation-01
>
>
>
> saying in step 3 that PE2 MUST send a label request and in step 5 that PE1
> MUST respond to the label request with the configured CW setting on PE1
> which was set, as well in step 6 PE2 MUST wait for PE1 label binding before
> sending it's label binding with CW set.
>
> As well, it may be good extending the flow chart described in appendix A in
> rfc 4447 with option 1.
>
> Option 2, how will we be able to re-enable CW? isn't that the issue we are
> trying to fix?
>
> In the recent IETF79, we have presented the draft "Pseudowire Control Word
> Negotiation Mechanism Analysis and Update"
> specified in RFC4447. Based on the problem analysis, possible solutions and
> their potential shortcomings are also discussed.
>
> The authors would like to have more feedback from the mailing list before
> working on the next version. Grateful if you could review the document and
> post comments on the mailing list.
>
> Thanks,
> Raymond Key

---

From: [email-masked]
Date: Thu, 25 Nov 2010 19:18:39 +0800

Hi Edward,
See the comments in line. Thanks.

Lizhong

Ed <[email-masked]> wrote on 2010-11-25 08:47:30:

> Hi Raymond,
>  
> Option 1 seems to be simply to resignal the FEC - with the 
> corresponding traffic forwarding impact. Can PE2 send a new label 
> mapping with cbit=1 be sent without requiring label withdrawal 
> message and label request message, for example?
[Lizhong] maybe not allowed, for this behavior will break existing CW 
negotiation mechanism.

> non-PREFERRED need to be considered as well?
[Lizhong] good idea, should be considered in next version.

> I agree with Sami. Maybe the other options should be in appendix 
> with an explanation of why they were not chosen?
>  
> Regards,
> Reshad.
>  
[email-masked]
> I personally like option 1 in this draft, describing how to re-
> enable control word via dynamic LDP signaling.
> 
> setting on PE1 which was set, as well in step 6 PE2 MUST wait for 
> PE1 label binding before sending it's label binding with CW set.
> 
issues.