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

[Stewart Bryant <[e-mail]>]

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 <[e-mail]> 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