Re: [Gen-art] Gen-art last call review of draft-ietf-pwe3-cbit-negotiation-04

Stewart Bryant <stbryant@cisco.com> Thu, 21 June 2012 13:56 UTC

Return-Path: <stbryant@cisco.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E7C21F86B5; Thu, 21 Jun 2012 06:56:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWljcwnA9NqY; Thu, 21 Jun 2012 06:56:26 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4793621F866B; Thu, 21 Jun 2012 06:56:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=14440; q=dns/txt; s=iport; t=1340286986; x=1341496586; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=RXruekzt2+pbMOWk2YFIWR9iuOnjtrT+vcxol+n+kgc=; b=ASVR0DNPM+xKHZEu3wis2Dp4h4PMdJ6RTzY+ZjN1TZSpmWux5Q84dZf4 xeLGsWLjGATmAwNIwErO7FM7kNNnQM3tpFoXdp4ZNmCZ2uY12n4mQCxOM S8OmfYjbxzBj3ulv7xif0lv2LBmVpIkmXPNPNkL3/9FY52kMiMP9cc52f o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EANYn40+rRDoJ/2dsb2JhbABFtVSBB4IYAQEBBBIBAiNAARALFAQJFg8JAwIBAgFFBg0BBQIBARUCB4doAQuaAoNIEJw7iy4ahgMDkU2DXY4bgQRigmCBVQcC
X-IronPort-AV: E=Sophos;i="4.77,451,1336348800"; d="scan'208";a="49725329"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 21 Jun 2012 13:56:12 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5LDuAXO028602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2012 13:56:12 GMT
Received: from dhcp-bdlk10-data-vlan300-64-103-106-107.cisco.com (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q5LDu75S016416; Thu, 21 Jun 2012 14:56:08 +0100 (BST)
Message-ID: <4FE327F7.4000008@cisco.com>
Date: Thu, 21 Jun 2012 14:56:07 +0100
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: Elwyn Davies <elwynd@folly.org.uk>
References: <OFAAEAB3D5.D300977C-ON48257A22.00581007-48257A22.005F0A02@zte.com.cn> <1340282307.31554.36408.camel@mightyatom.folly.org.uk>
In-Reply-To: <1340282307.31554.36408.camel@mightyatom.folly.org.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-pwe3-cbit-negotiation.all@tools.ietf.org, General Area Review Team <gen-art@ietf.org>, Lizhong Jin <lizhong.jin@zte.com.cn>, pwe3 <pwe3@ietf.org>, "pwe3-chairs@tools.ietf.org" <pwe3-chairs@tools.ietf.org>
Subject: Re: [Gen-art] Gen-art last call review of draft-ietf-pwe3-cbit-negotiation-04
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jun 2012 13:56:27 -0000

Bringing this to the attention of the PWE3 WG
since that need to know that this discussion is happening
and will have a view as to what is already well
known in terms of RFC4447 behavior and what
needs clarification via this draft.

Stewart

On 21/06/2012 13:38, Elwyn Davies wrote:
> Hi, Lizhong.
>
> I have removed the bits that we are agreed on to shorten the mail a bit.
>
> I don't think we have converged just yet.
>
> Regards,
> Elwyn
>
> On Wed, 2012-06-20 at 01:17 +0800, Lizhong Jin wrote:
>> Hi Elwyn,
>> Thank you for the prompt reply. See inline below.
>>
>> Lizhong
>>    
>>
>> Elwyn Davies <elwynd@folly.org.uk> wrote 2012/06/19 23:16:08:
>>>>> Document: draft-ietf-pwe3-cbit-negotiation-04.txt
>>>>> Reviewer: Elwyn Davies
>>>>> Review Date: 19 June 2012
>>>>> IETF LC End Date: 15 June 2012
>>>>> IESG Telechat date: 21 June 2012
>>>>>
>>>>> Summary:
>>>>> Not ready. The proposal for the NOT PREFERRED to PREFERRED
>>>> transition
>>>>> case does not appear to be compatible with the existing RFC 4447
>>>>> standard in the way stated and there are a number of other minor
>>>> issues.
>>>>> The draft is also in need of an editing pass by an author whose
>>>> mother
>>>>> tongue is English as there are parts where the syntax is misleading
>>>>> Major issues:
>>>>> s3: The discussion of the NOT PREFERRED to PREFERRED transition case
>>>>> (buried at the end of s3 - causing me to ask 'what about this case?'
>>>>> during reading of s2 and most of s3)  implies that some existing RFC
>>>>> 4447 procedure applies. Clearly, if the PW is not using the control
>>>> word
>>>>> then there is nothing to do.  On the other hand, inspection of s6.2
>>>> of
>>>>> RFC4447 indicates that once the two PEs have agreed on c = 1, 'setup
>>>> is
>>>>> complete' and Label Mapping messages would therefore be
>>>>> 'unexpected' (see item '-i' in second set of bullets in s6.2 of RFC
>>>>> 4447). So, what procedure is to be used? And what implications does
>>>> this
>>>>> have for backwards compatibility?  Wouldn't it be generally simpler
>>>> to
>>>>> apply the PREFERRED to NOT PREFERRED mechanism to all case?
>>>> [Lizhong] this draft is to solve the case to change a PW from c=0 to
>>>> c=1, that means one PE should change its use of control word from NOT
>>>> PREFERRED to PREFERRED. RFC4447 is already there and deployed, and the
>>>> PE will not always send its locally configured preferrence according
>>>> RFC4447, see PE1 behavior in section 2 step 1&2. That's why we could
>>>> not simply apply the mechanism at the end of section 3. Hope it is
>>>> clear.
>>> There are two issues here:
>>> - Clarity: RFC 4447 does not have any discussion of what might happen if
>>> the configuration value changes.  The draft focusses on on transition
>>> direction but does not mention the other except for one paragaph right
>>> at the end of s3.  It is therefore reasonable that somebody looking at
>>> this draft would wonder 'what about the other transition direction?'.
>>> Whether or not anything needs to be done it would save people wondering
>>> if you put in a sentence in the introduction to explain that the other
>>> direction is not (or is) a problem.
>> [Lizhong] accept. Add following:
>> When PE changes the preference for the use of control word from
>> PREFERRED to NOT PREFERRED, it should follow [RFC4447], and there is
>> no problem.
> See below...
>>> - Technical: The paragraph in s3 implies that the PREFERRED to NOT
>>> PREFERRED direction will result in some part of the RFC 4447 protocol
>>> being (re-)invoked.  What part is not made very clear.  As far as I can
>>> see sending more messages other than Label Release or Label Withdraw for
>>> this PW is not part of the RFC 4447 protocol and hence will cause an
>>> error.  Alternatively if it isn't reinvoked, the PW will continue to use
>>> control words.  Please explain what is going on here.  The fact that RFC
>>> 4447 has been deployed doesn't explain what is going on.
>> [Lizhong] now I understand you concern. The last sentance of s3 is not
>> clear. How about the following:
>> In that case, local PE will always send Label Withdraw message if
>> already sending Label Mapping message, and then send new Label Mapping
>> message with C-bit value following the procedures defined in
>> [RFC4447].
> I think we have reached the heart of the issue here:  RFC 4447 does not
> mention changing the control word configuration.  The combination of the
> existing text in the draft and what you have just weittrn above
> indicates that *in both transition directions* the PE changing
> configuration notifies its peer by sending a Label Withdraw. It is not
> immediately obvious to me that you could deduce this from RFC 4447 - if
> it is then there needs to be a pointer to the relevant section in RFC
> 4447 to enlighten the ignorant like me.  Otherwise the PREFERRED to NOT
> PREFERRED transition is *not* just 'follow the RFC 4447 procedures'.
>
> If I now understand correctly, the situation is as follows:
> - in both cases when there is a control word preference transition, send
> a Label Withdraw.
> - in the NOT PREFERRED to PREFERRED case send Label Release also (order
> not important), wait for a responses from peer, then send Label Request
> and negotiate use of control word using Label Mapping C bit as for a new
> PW (might result in either using or not using control word depending on
> state in peer).
> - in the PREFERRED to NOT PREFERRED case, just negotiate C bit to 0
> using Label Mapping - label will be maintained. [Need to check that RFC
> 4447 is expecting/will allow this sequence.]
>
> If I have this straight, I think that the PREFERRED to NOT PREFERRED
> case needs some more words in s3 and an introduction in s2. (And it
> would be easier to understand with this case in a separate sub-section -
> sorry to harp on about this).
>
>>>>> Minor issues:
>>>>> s3: Has there been any discussion on possible race conditions?
>>>>   Changing
>>>>> the configuration value during the message exchange strikes me as
>>>>> dangerous - it is probably sufficient to note that changes should be
>>>>> suppressed during the Label Mapping message exchange but I am not
>>>>> totally sure about this.
>>>> [Lizhong] The message would be processed in sequence in TCP-based LDP
>>>> session. I do not see a problem here. But we do have a note in section
>>>> 3 for multi-segment PW for sequence processing.
>>> There are several network round trips in the message exchanges.  The
>>> protocol and the configuration mechanism in a PE are potentially
>>> separate threads.  There is scope, depending on the implementation, for
>>> the user at the 'remote' PE to change the configuration during the
>>> message exchange making for a potential race condition.
>> [Lizhong] we discussed the race condition on the PWE3 maillist from
>> Spike, and for multi-segment PW, we add a note to ensure the sequence
>> processing for implementation.
> I look forward to the revised text.
>>   
>>
>>>>> s3, bullet '-i':  I completely misparsed this section on first
>>>> reading
>>>>> and I am still not absolutely sure what message sequence is being
>>>>> specified.  Working back from later sections I *think* that the
>>>>> intention is:
>>>>> IF Mapping sent THEN { send Withdraw; send Release;}
>>>>> Wait to receive Release
>>>>> The implication at present is that a Mapping might not have been
>>>> sent
>>>>> and then only a Release is needed: is this a possibility? Please
>>>>> clarify.
>>>>> The picture in Appendix A suffers from the same problem.
>>>> [Lizhong] Adrian raise the same comment, and I change it as below:
>>>>         -i.  PE MUST send a Label Release message to remote PE. If a
>>>> PE
>>>>              has previously sent a Label Mapping message to a remote
>>>> PE,
>>>>              it MUST also send a Label Withdraw message to the remote
>>>> PE,
>>>>              and wait until it receives a Label Release message from
>>>> the
>>>>             remote PE.
>>> What does it send first if both must be sent?  The text in the rest of
>>> the document implies withdraw then release.  This new text sort of
>>> implies release then withdraw but isn't really clear.
>> [Lizhong] both should be sent, and does not require the sending
>> sequence. The two messages does not have dependence.
> In that case, it is important to say so.
>>>>> s3, discussion of multi-segment PWs: The statement that S-PE's
>>>> SHOULD
>>>>> assume an initial passive role seems to have several problems:
>>>>> - Does this mean that changing the configuration of an S-PE would
>>>> not
>>>>> provoke the new mechanisms?
>>>>> - The passive role situation is only specified for some sorts of
>>>> linked
>>>>> FECs in RFC 6073 - what about other cases?
>>>>> - What are the consequences for ignoring the SHOULD in this case? (I
>>>>> have to say I am unsure that RFC 6073 deals with this problem
>>>> either.)
>>>> [Lizhong] we follow RFC6073, and passive role is only applied for the
>>>> PW FEC, other cases are out of scope.
>>> Why? This needs an explanation. Also this doesn't cover the point about
>>> whether reconfig of an S-PE is allowed and how this squares with the
>>> passive role.
>>>> SHOULD means highly recommended. We do not meet any problem when
>>>> implementing RFC6073. Do you suggest to change this to MUST?
>>> Whenever a specification includes a 'SHOULD' the question arises of what
>>> alternatives there might be and what is the reason for preferring the
>>> suggested solution.  In the original setup, it is fairly clear that life
>>> is easier letting setup progress from  one end to the other (although
>>> this is not spelt out - I would have argued for this had  I reviewed the
>>> doc).  For the configuration change this is less obvious.  Regarding the
>>> point about reconfig of the  S-PE, it is going to make life more
>>> complicated if the S-PE has to tell the T-PE to be active so it can be
>>> passive.  I would therefore argue that probably the notion of passivity
>>> is irrelevant to the transition use case.  Whether it should be SHOULD
>>> or MUST is therefore moot.
>> [Lizhong] how about the following? Because we just refer to RFC6073, and does not add anything new.
>> An initial passive role is defined in [RFC6073] for S-PE.
> I can't see that this really helps.
> There are still two points at issue here:
> - Why are the cases other than the one in RFC 4447 that refers to a
> passive S-PE out of scope?  There aren't any statements to this effect
> in the document.
> - It is difficult for a S-PE that has its control word configuration
> change to act passively.  If it is really passive than nothing will
> happen until the label is withdrawn.  Otherwise it can't be descibed as
> passive for this action.  The text in the current draft actually
> describes what is specified in RFC 6073 when talking 'passive' rather
> than explaining what happens when the control word configuration
> changes.
>>   
>>>> [Lizhong] has been revised in v-04.
>>> Not as far as I can see.
>> [Lizhong] write "pseudowire" directly in the text, not PW.
> There are lots of instances of PW still left in v04. Expand acronym =>
> define what it means on first usage i.e pseudowire (PW).  Same for the
> various other acronyms that aren't defined in the text.
>>>>> s2: Expand acronym PE.
>>>> [Lizhong] accept
>>>>
>>>>> s2, 2nd sentence: s/configurable/configured/
>>>> [Lizhong] configurable is right.
>>> Leave that one to the RFc Editor.
>>>>> s2, 3rd and 4th sentences: I *think* this text is trying to say:
>>>>>    The intention of the control word negotiation is that the control
>>>> word
>>>>> will be used when both endpoints are configured with control word
>>>> usage
>>>>> PREFERRED.  However if one endpoint is initially configured with
>>>> control
>>>>> word usage NOT PREFERRED but later changes to PREFERRED, a PW
>>>> between
>>>>> the endpoints will not transition to usage of the control word as
>>>>> explained below.
>>>> [Lizhong] no, the case is that operator deploys PW with control word
>>>> used in the first phase. In the second phase, they want to upgrade
>>>> their PW service to use control word. Two different deployment
>>>> timeframes.
>>> That is what my sentence says.
>> [Lizhong] ok.
>>
>>>>> s3: It would be much clearer if s3 was divided into 3 sub-sections
>>>>> (possibly reordered):
>>>>> - PREFERRED to NOT PREFERRED transition
>>>>> - NOT PREFERRED to PREFERRED transition
>>>>> - Multi-segment case (which should refer to both previous cases)
>>>>> The pointer to the diagram in Appendix A could usefully occur in the
>>>>> introduction to s3.  If this was adopted s3.1 could either be a
>>>> fourth
>>>>> sub-section or a sub-sub-section of the PREFERRED to NOT PREFERRED
>>>>> section.
>>>> [Lizhong] PREFERRED to NOT PREFERRED does not introduce any new.
>>>> Multi-segment case is fully inherited from single-segment case. It
>>>> would be redundancy to have sub-sections here.
>>> I disagree strongly.  The multi-segment case affects the other RFC and
>>> needs to be made to stand out so that implementors can see where the
>>> changes occur.  The PREFERRED to NOT PREFERRED case also ought to be
>>> separated whether or not I am right about this case.
>> [Lizhong] how about only divide multi-segment? The case of PREFERRED to
>> NOT PREFERRED case is only for reference, and the text is not many.
> That is so, but it is a change of subject and the fact that it will then
> be in the table of contents makes it easier for implementors to find the
> relevant text.  I wouldn't call it 'redundant'.
>
>>>>> s3, last para/Appendix A:  The diagram doesn't cover the PREFERRED
>>>> to
>>>>> NOT PREFERRED transition.
>>>> [Lizhong] no, there is a "no" branch under "NOT Preferred to
>>>> Preferred" to cover "PREFERRED to NOT PREFERRED". Anyway, the diagram
>>>> discription should be "NOT Preferred to Preferred" which is wrong in
>>>> v-04.
> Need to check it reflects the Label Withdraw message needed in the
> PREFERRED to NOT PREFERRED case.
>
>
>


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html