Subject: [RTG-DIR] RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 14 Jun 2012 05:23:59 +0000

Hello,
I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document:   draft-ietf-pwe3-cbit-negotiation-03.txt
Reviewer:   Alexander ("Sasha") Vainshtein
Review Date:   13.06.12
IETF LC End date:  15.06.12
Intended Status:  Standards Track 

SUMMARY:

I think that the document is generally in good shape and almost ready for publication. 
However, I have some minor technical concerns as well as some editorial ones which, IMHO, should be resolved before publication.

MAJOR ISSUES:  None

MINOR ISSUES:

Technical:

 The actual C-bit negotiation protocol (extension of what has been defined in RFC 4447) is presented in the document 3 (three) times:

 -  In Section 3, items i) to iii) and the paragraph immediately following these items. This text uses the IETF capitalized requirement level terms (MUST) and hence looks like the normative definition of the protocol

 -   In the same Section, items 1 to 5. This text refers to an (IMHO not very informative) Figure 1 but does not contain the IETF capitalized requirement level terms. 

 - In Appendix A. This Appendix contains a block diagram of the C-bit negotiation procedure that follows/illustrates the text in items 1) - 7) of Section 3.

  The difference between the presumably normative definition and two others is that the first one explicitly states:  "Local PE MUST send a label withdraw message to remote PE if it has previously sent a label mapping, and wait until receiving a label release from the remote PE".  
 (Note: "Local PE" in the document is the PE that has changed configuration of CW usage (in this case, from NOT PREFERRED to PREFERRED.)

 The two other fragments do not mention waiting for the label release message from the remote PE, i.e. are not fully consistent with the normative one.

 My interpretation of the LDP procedures as per RFC 5036 is that an LSR that sends a label withdraw message MUST wait for the acknowledging    label release message from the peer, i.e. the presumed normative definition is correct. And in any case I think that all the all the descriptions of the protocol (texts, block diagrams etc.) must be fully consistent.

I also suggest to clarify whether sending the label release message by the local PE above should wait for the label release message from the remote PE if label withdraw message has been sent.  I expect that, upon receiving the label withdraw message from the local PE, the remote one, in addition to acknowledging it with a label release message would also immediately send its own label withdraw message to the local PE which would then, in its turn, send label release message back.

Editorial:

 1. With regard to multi-segment PWs, the draft says that "the (label) request message MUST be processed in ordered mode". It is not clear to me whether this refers to ordered label distribution mode of LDP as defined in RFC 5036, or to something else. At the same time, the procedure defined in the draft is compliant with the common PW label distribution procedures as defined in RFC 6073, so I suggest to consider referencing RFC 6073 (there is no such reference in the draft) instead of using a potentially misleading term. I also wonder if this draft should not be considered as updating RFC 6073 in addition to updating RFC 4447.

 2. As mentioned above, there are two text fragments defining the new C-bit negotiation procedure in the draft. I suggest to consider merging them into a single text that consistently uses the IETF capitalized terms for requirement levels while avoiding such vague terms as "could"  (e.g., " PE2 could wait for PE1 label  binding before sending its label binding with C-bit set"). Having a single text fragment that defines the procedure would also reduce the potential for inconsistencies.

 3. The text, as written, does not clearly distinguish between the PW control word (as a field in the packet) and the PW control word *use* in a PW instance. In most cases this is not a problem, since the draft is all about the CW use. However, there are several cases when this may result in misinterpretation, e.g. (the next two items are copy and paste quotes from the draft):

 -    When the peer PE successfully processed the label withdraw and label release, and removed the remote label binding, it MUST reset its local control word with the configured one... 

 - When Local PE changes its control word from PREFERRED to NOT PREFERRED...

(Please note also that *preferred* PW control word is defined in RFC 4385, but the meaning is completely different from one implied here).

I suggest to consider clarifying that these (and possibly some other) fragments refer to the PW CW usage and not to format or content of the CW. There is clearly more than one way to do that. IMHO and FWIW the most unambiguous one would be to define the relevant state variables of the PW end points (configured, transmitted and received C-bit) and to use them in the definition of the procedure, but this is definitely for the authors to decide.

Nits:  None found by the IETF draft checker.
 
Regards,
     Sasha
This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: "Malis, Andrew G \(Andy\)" <[email-masked]>
Date: Thu, 14 Jun 2012 01:57:15 -0400

Sasha,

Many thanks. We'll wait until the end of IETF last call and then take
action as directed by the ADs, who may have review comments of their own,
as well as the rest of the IESG.

Cheers,
Andy

On 6/14/2012 14:23 , "Alexander Vainshtein"
<[email-masked]> wrote:

Hello,
I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review. The purpose of
the review is to provide assistance to the Routing ADs. For more
information about the Routing Directorate, please see
http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF Last
Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

SUMMARY:

I think that the document is generally in good shape and almost ready for
publication. 
However, I have some minor technical concerns as well as some editorial
ones which, IMHO, should be resolved before publication.

MAJOR ISSUES:  None

MINOR ISSUES:

Technical:

 The actual C-bit negotiation protocol (extension of what has been defined
in RFC 4447) is presented in the document 3 (three) times:

 -  In Section 3, items i) to iii) and the paragraph immediately following
these items. This text uses the IETF capitalized requirement level terms
(MUST) and hence looks like the normative definition of the protocol

 -   In the same Section, items 1 to 5. This text refers to an (IMHO not
very informative) Figure 1 but does not contain the IETF capitalized
requirement level terms.

 - In Appendix A. This Appendix contains a block diagram of the C-bit
negotiation procedure that follows/illustrates the text in items 1) - 7)
of Section 3.

  The difference between the presumably normative definition and two
others is that the first one explicitly states:  "Local PE MUST send a
label withdraw message to remote PE if it has previously sent a label
mapping, and wait until receiving a label release from the remote PE".
 (Note: "Local PE" in the document is the PE that has changed
configuration of CW usage (in this case, from NOT PREFERRED to PREFERRED.)

 The two other fragments do not mention waiting for the label release
message from the remote PE, i.e. are not fully consistent with the
normative one.

 My interpretation of the LDP procedures as per RFC 5036 is that an LSR
that sends a label withdraw message MUST wait for the acknowledging
label release message from the peer, i.e. the presumed normative
definition is correct. And in any case I think that all the all the
descriptions of the protocol (texts, block diagrams etc.) must be fully
consistent.

I also suggest to clarify whether sending the label release message by the
local PE above should wait for the label release message from the remote
PE if label withdraw message has been sent.  I expect that, upon receiving
the label withdraw message from the local PE, the remote one, in addition
to acknowledging it with a label release message would also immediately
send its own label withdraw message to the local PE which would then, in
its turn, send label release message back.

Editorial:

 1. With regard to multi-segment PWs, the draft says that "the (label)
request message MUST be processed in ordered mode". It is not clear to me
whether this refers to ordered label distribution mode of LDP as defined
in RFC 5036, or to something else. At the same time, the procedure defined
in the draft is compliant with the common PW label distribution procedures
as defined in RFC 6073, so I suggest to consider referencing RFC 6073
(there is no such reference in the draft) instead of using a potentially
misleading term. I also wonder if this draft should not be considered as
updating RFC 6073 in addition to updating RFC 4447.

 2. As mentioned above, there are two text fragments defining the new
C-bit negotiation procedure in the draft. I suggest to consider merging
them into a single text that consistently uses the IETF capitalized terms
for requirement levels while avoiding such vague terms as "could"  (e.g.,
" PE2 could wait for PE1 label  binding before sending its label binding
with C-bit set"). Having a single text fragment that defines the procedure
would also reduce the potential for inconsistencies.

 3. The text, as written, does not clearly distinguish between the PW
control word (as a field in the packet) and the PW control word *use* in a
PW instance. In most cases this is not a problem, since the draft is all
about the CW use. However, there are several cases when this may result in
misinterpretation, e.g. (the next two items are copy and paste quotes from
the draft):

 -    When the peer PE successfully processed the label withdraw and label
release, and removed the remote label binding, it MUST reset its local
control word with the configured one...

 - When Local PE changes its control word from PREFERRED to NOT
PREFERRED...

(Please note also that *preferred* PW control word is defined in RFC 4385,
but the meaning is completely different from one implied here).

I suggest to consider clarifying that these (and possibly some other)
fragments refer to the PW CW usage and not to format or content of the CW.
There is clearly more than one way to do that. IMHO and FWIW the most
unambiguous one would be to define the relevant state variables of the PW
end points (configured, transmitted and received C-bit) and to use them in
the definition of the procedure, but this is definitely for the authors to
decide.

Regards,
     Sasha
This e-mail message is intended for the recipient only and contains
information which is CONFIDENTIAL and which may be proprietary to ECI
Telecom. If you have received this transmission in error, please inform us
by e-mail, phone or fax, and then delete the original and all copies
thereof.

---

From: Lizhong Jin<[email-masked]>
Date: Thu, 14 Jun 2012 17:47:43 +0800

Hi Sasha,
Thank you very much for the valuable comments. Please see my reply inline 
below.
I also attached the modified version for your check and reference.

Regards
Lizhong

Alexander Vainshtein <[email-masked]> wrote 2012/06/14 
13:23:59:

> Hello,
> I have been selected as the Routing Directorate reviewer for this 
> draft. The Routing Directorate seeks to review all routing or 
> routing-related drafts as they pass through IETF last call and IESG 
> review. The purpose of the review is to provide assistance to the 
> Routing ADs. For more information about the Routing Directorate, please 
see 
> Although these comments are primarily for the use of the Routing 
> ADs, it would be helpful if you could consider them along with any 
> other IETF Last Call comments that you receive, and strive to 
> resolve them through discussion or by updating the draft.
> 
> However, I have some minor technical concerns as well as some 
> editorial ones which, IMHO, should be resolved before publication.
> 
> MAJOR ISSUES:  None
> 
> MINOR ISSUES:
> 
> Technical:
> 
>  The actual C-bit negotiation protocol (extension of what has been 
> defined in RFC 4447) is presented in the document 3 (three) times:
> 
>  -  In Section 3, items i) to iii) and the paragraph immediately 
> following these items. This text uses the IETF capitalized 
> requirement level terms (MUST) and hence looks like the normative 
> definition of the protocol
> 
>  -   In the same Section, items 1 to 5. This text refers to an (IMHO
> not very informative) Figure 1 but does not contain the IETF 
> capitalized requirement level terms. 
> 
>  - In Appendix A. This Appendix contains a block diagram of the C-
> bit negotiation procedure that follows/illustrates the text in items
> 1) - 7) of Section 3.
> 
> others is that the first one explicitly states:  "Local PE MUST send
> a label withdraw message to remote PE if it has previously sent a 
> label mapping, and wait until receiving a label release from the remote 
PE". 
>  The two other fragments do not mention waiting for the label 
> release message from the remote PE, i.e. are not fully consistent 
> with the normative one.
> 
>  My interpretation of the LDP procedures as per RFC 5036 is that an 
> LSR that sends a label withdraw message MUST wait for the 
> acknowledging    label release message from the peer, i.e. the 
> presumed normative definition is correct. And in any case I think 
> that all the all the descriptions of the protocol (texts, block 
> diagrams etc.) must be fully consistent.
[Lizhong] agree, and we will change the second and third text fragment to 
reflect this.

> 
> I also suggest to clarify whether sending the label release message 
> by the local PE above should wait for the label release message from
> the remote PE if label withdraw message has been sent.  I expect 
> that, upon receiving the label withdraw message from the local PE, 
> the remote one, in addition to acknowledging it with a label release
> message would also immediately send its own label withdraw message 
> to the local PE which would then, in its turn, send label release 
> message back.
[Lizhong] the remote one will not send label withdraw after acknowledging 
with label release, because "liberal label retention" mode is applied. The 
sending label release message by local PE is not necessary to wait for the 
release from remote. Will clarify this in the draft.

> 
> Editorial:
> 
>  1. With regard to multi-segment PWs, the draft says that "the 
> (label) request message MUST be processed in ordered mode". It is 
> not clear to me whether this refers to ordered label distribution 
> mode of LDP as defined in RFC 5036, or to something else. At the 
> same time, the procedure defined in the draft is compliant with the 
> common PW label distribution procedures as defined in RFC 6073, so I
> suggest to consider referencing RFC 6073 (there is no such reference
> in the draft) instead of using a potentially misleading term. I also
> wonder if this draft should not be considered as updating RFC 6073 
> in addition to updating RFC 4447.
[Lizhong] yes, ordered mode follows ordered label distribution mode in 
RFC5036. And I agree, referencing RFC6073 would be more clear. And yes, 
the draft is also updating RFC6073.

> 
>  2. As mentioned above, there are two text fragments defining the 
> new C-bit negotiation procedure in the draft. I suggest to consider 
> merging them into a single text that consistently uses the IETF 
> capitalized terms for requirement levels while avoiding such vague 
> terms as "could"  (e.g., " PE2 could wait for PE1 label  binding 
> before sending its label binding with C-bit set"). Having a single 
> text fragment that defines the procedure would also reduce the 
> potential for inconsistencies.
[Lizhong] the first text fragment defines the requirement, and the second 
gives an usecase according to the first text. What if we move the use case 
to another sub-section, so as to make it more clear?

> 
>  3. The text, as written, does not clearly distinguish between the 
> PW control word (as a field in the packet) and the PW control word 
> *use* in a PW instance. In most cases this is not a problem, since 
> the draft is all about the CW use. However, there are several cases 
> when this may result in misinterpretation, e.g. (the next two items 
> are copy and paste quotes from the draft):
> 
>  -    When the peer PE successfully processed the label withdraw and
> label release, and removed the remote label binding, it MUST reset 
> its local control word with the configured one... 
> 
PREFERRED...
> 
> (Please note also that *preferred* PW control word is defined in RFC
> 4385, but the meaning is completely different from one implied here).
> 
> I suggest to consider clarifying that these (and possibly some 
> other) fragments refer to the PW CW usage and not to format or 
> content of the CW. There is clearly more than one way to do that. 
> IMHO and FWIW the most unambiguous one would be to define the 
> relevant state variables of the PW end points (configured, 
> transmitted and received C-bit) and to use them in the definition of
> the procedure, but this is definitely for the authors to decide.
[Lizhong] we will change the "control word" to "use of control word" in 
the draft, and make it clear.

> information which is CONFIDENTIAL and which may be proprietary to 
> ECI Telecom. If you have received this transmission in error, please
> inform us by e-mail, phone or fax, and then delete the original and 
> all copies thereof.
> 
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 14 Jun 2012 15:23:13 +0000

Lizhong hi,
Lots of thanks for a prompt response.

Please see some answers inline below (brown italics).

I will read the new version and provide additional comments later, hope this is OK.

Regards,
     Sasha

From: Lizhong Jin [mailto:[email-masked]]
Sent: Thursday, June 14, 2012 12:48 PM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt

Hi Sasha,
Thank you very much for the valuable comments. Please see my reply inline below.
I also attached the modified version for your check and reference.

Regards
Lizhong

Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote 2012/06/14 13:23:59:

> Routing ADs. For more information about the Routing Directorate, please see
> label mapping, and wait until receiving a label release from the remote PE".
[Lizhong] agree, and we will change the second and third text fragment to reflect this.
[[[Sasha]]] OK.

> to the local PE which would then, in its turn, send label release
[Lizhong] the remote one will not send label withdraw after acknowledging with label release, because "liberal label retention" mode is applied.
The sending label release message by local PE is not necessary to wait for the release from remote. Will clarify this in the draft.
[[[Sasha]]] I am not sure liberal label retention really applies here - IMHO it just says that unused label advertisements received by an NE are retained. And it seems that RFC 447 is not very clear on procedures for tearing down a PW. But as long as you clarify this point, it is not really important for this draft.

> in addition to updating RFC 4447.
[Lizhong] yes, ordered mode follows ordered label distribution mode in RFC5036. And I agree, referencing RFC6073 would be more clear. And yes, the draft is also updating RFC6073.
[[[Sasha]]] I am not sure ordered label distribution in 5036 really applies here, because my reading of 5036 suggests that it is used (or not used) per LSR.  I suspect that this may be the reason for the authors of 6073 not to mention it but explicitly define the process instead. But, as I have said, the procedure you've specified looks OK.

> potential for inconsistencies.
[Lizhong] the first text fragment defines the requirement, and the second gives an usecase according to the first text. What if we move the use case to another sub-section, so as to make it more clear?
[[[Sasha]]] I wonder if the second fragment really adds much to the first one (which defines the procedure). But as long as (1) it is clearly specified what is the normative specification and what is the use case, and (b) the use case is fully consistent with the normative specification, it is OK.

> the procedure, but this is definitely for the authors to decide.
[Lizhong] we will change the "control word" to "use of control word" in the draft, and make it clear.
[[[Sasha]]] Sounds OK.

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 14 Jun 2012 15:41:11 +0000

Lizhong, hi again!

I have read the updated draft, and it looks OK. There just an additional minor comment on the text that deals with  to MS-PWs.

The draft says "When S-PE receives a label request message from a remote PE, it MUST advertise the request message to the other remote PE." The intention is clear, but I suggest to consider changing it to something like "When an S-PE receives a label request message from one of its adjacent PEs (be it S-PE or another T-PE), it MUST send a matching label request message it is other adjacent PE (again, it may be an S-PE or a T-PE)". This modification, if it suits you, would serve two purposes:

-          It would clarify that an S-PE relays Label Request messages from one of its neighbors to the other one, and does not care (indeed, it does not usually know) whether these neighbors are T-PEs or S-PEs

-          It avoids the term "advertise" which, IMHO, does not apply to what label request messages do.

Regards,
     Sasha

From: Alexander Vainshtein
Sent: Thursday, June 14, 2012 6:23 PM
To: 'Lizhong Jin'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt

Lizhong hi,

Regards,
     Sasha

Hi Sasha,

Regards
Lizhong

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 14 Jun 2012 19:16:36 +0000

Lizhong hi (again),

After re-reading 4447 I have come to conclusion that a Label Withdraw message sent by one of the PEs to its peer would be responded with/acked by  a Label Release message, but it will not trigger a Label Withdraw message from the peer PE. This is based on the text that says that PW labels, once advertised, are withdrawn in just three cases:

  1.  When the local PW endpoint is deleted from the PE configuration
  2.  When the  local PW endpoint is administratively disabled by the user
  3.  When the local AC goes DOWN (only if the PW Status is not supported).

Actually the draft adds one more case to this list.

Regards,

     Sasha

________________________________
From: Alexander Vainshtein
Sent: Thursday, June 14, 2012 5:41 PM
To: Lizhong Jin
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt

Lizhong, hi again!

The draft says “When S-PE receives a label request message from a remote PE, it MUST advertise the request message to the other remote PE.” The intention is clear, but I suggest to consider changing it to something like “When an S-PE receives a label request message from one of its adjacent PEs (be it S-PE or another T-PE), it MUST send a matching label request message it is other adjacent PE (again, it may be an S-PE or a T-PE)”. This modification, if it suits you, would serve two purposes:

-          It avoids the term “advertise” which, IMHO, does not apply to what label request messages do.

Regards,
     Sasha

Lizhong hi,

Regards,
     Sasha

Hi Sasha,

Regards
Lizhong

[Lizhong] the remote one will not send label withdraw after acknowledging with label release, because "liberal label retention" mode is applied.
The sending label release message by local PE is not necessary to wait for the release from remote. Will clarify this in the draft.
[[[Sasha]]] I am not sure liberal label retention really applies here – IMHO it just says that unused label advertisements received by an NE are retained. And it seems that RFC 447 is not very clear on procedures for tearing down a PW. But as long as you clarify this point, it is not really important for this draft.

[Lizhong] yes, ordered mode follows ordered label distribution mode in RFC5036. And I agree, referencing RFC6073 would be more clear. And yes, the draft is also updating RFC6073.
[[[Sasha]]] I am not sure ordered label distribution in 5036 really applies here, because my reading of 5036 suggests that it is used (or not used) per LSR.  I suspect that this may be the reason for the authors of 6073 not to mention it but explicitly define the process instead. But, as I have said, the procedure you’ve specified looks OK.

---

From: Lizhong Jin<[email-masked]>
Date: Fri, 15 Jun 2012 11:41:51 +0800

23:41:11:

> Lizhong, hi again!
> 
> I have read the updated draft, and it looks OK. There just an 
> additional minor comment on the text that deals with  to MS-PWs.
> 
> The draft says “When S-PE receives a label request message from a 
> remote PE, it MUST advertise the request message to the other remote PE.
> ” The intention is clear, but I suggest to consider changing it to 
> something like “When an S-PE receives a label request message from 
> one of its adjacent PEs (be it S-PE or another T-PE), it MUST send a
> matching label request message it is other adjacent PE (again, it 
> may be an S-PE or a T-PE)”. This modification, if it suits you, 
> would serve two purposes:
> -          It would clarify that an S-PE relays Label Request 
> messages from one of its neighbors to the other one, and does not 
> care (indeed, it does not usually know) whether these neighbors are 
> T-PEs or S-PEs
[Lizhong] OK, accept. Thank you.

Lizhong

> Alexander Vainshtein <[email-masked]> wrote 
> 2012/06/14 13:23:59:
> 
> > Hello,
> [Lizhong] the remote one will not send label withdraw after 
> acknowledging with label release, because "liberal label retention" 
> mode is applied. 
> The sending label release message by local PE is not necessary to 
> wait for the release from remote. Will clarify this in the draft. 
> [[[Sasha]]] I am not sure liberal label retention really applies 
> here – IMHO it just says that unused label advertisements received 
> by an NE are retained. And it seems that RFC 447 is not very clear 
> on procedures for tearing down a PW. But as long as you clarify this
> point, it is not really important for this draft.
> 
> > 
> > Editorial:
> > 
> [Lizhong] yes, ordered mode follows ordered label distribution mode 
> in RFC5036. And I agree, referencing RFC6073 would be more clear. 
> And yes, the draft is also updating RFC6073. 
> [[[Sasha]]] I am not sure ordered label distribution in 5036 really 
> applies here, because my reading of 5036 suggests that it is used 
> (or not used) per LSR.  I suspect that this may be the reason for 
> the authors of 6073 not to mention it but explicitly define the 
> process instead. But, as I have said, the procedure you’ve specified 
looks OK.
> [Lizhong] the first text fragment defines the requirement, and the 
> second gives an usecase according to the first text. What if we move
> the use case to another sub-section, so as to make it more clear? 
> [[[Sasha]]] I wonder if the second fragment really adds much to the 
> first one (which defines the procedure). But as long as (1) it is 
> clearly specified what is the normative specification and what is 
> the use case, and (b) the use case is fully consistent with the 
> normative specification, it is OK. 
> 
> 
> > 
PREFERRED...

---

From: Lizhong Jin<[email-masked]>
Date: Fri, 15 Jun 2012 11:49:44 +0800

Hi Sasha,
Yes, and this draft use a label release received to release the PW labels. 
We will upload the revised version after the end of last call. Thank you 
for the valuable comments.

Regards
Lizhong

Alexander Vainshtein <[email-masked]> wrote 2012/06/15 
03:16:36:

> Lizhong hi (again),
> After re-reading 4447 I have come to conclusion that a Label 
> Withdraw message sent by one of the PEs to its peer would be 
> responded with/acked by  a Label Release message, but it will not 
> trigger a Label Withdraw message from the peer PE. This is based on 
> the text that says that PW labels, once advertised, are withdrawn in
> just three cases:

looks OK.
PREFERRED...