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

[Stewart Bryant <[e-mail]>]

Please can you continue this conversation with the PWE3
WG in the cc list so that it has the correct level of expert
oversight.

Thanks

Stewart

On 21/06/2012 15:43, Lizhong Jin wrote:
>
> Hi Elwyn,
> Please see inline below.
>
> Thanks
> Lizhong
>
>
> Elwyn Davies <[e-mail]> wrote 2012/06/21 20:38:27:
>
> > 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'.
> [Lizhong] as an engineer, I interpret the configuration changing as 
> deleting and configuring again. Control word configuration changing 
> means deleting the old control word, and then configuring the new 
> control word, that means deleting PW configuration, and configuring 
> new PW configuration again. RFC4447 section 5.4.1 describe the 
> procedure of PW deletion and configuration. When you apply the above 
> procedure to PREFERRED to NOT PREFERRED transition, it works well, 
> while for NOT PREFERRED to PREFERRED transition, there is a problem.
> What if I add some description of the meaning of control word changing 
> at the end of s3, so as to make it clear?
>
> >
> > 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).
> [Lizhong] your above description is totally right. How about changing 
> the end of s3 as below:
> When Local PE changes the use of control word from PREFERRED to NOT 
> PREFERRED, the local PE would be able to negotiate the Control Word to 
> be not used by deleting the PW configuration with PREFERRED use of 
> control word,  and configuring the PW again with NOT PREFERRED use of 
> control word. All of these procedures have been defined in [RFC4447] 
> section 5.4.1.
>
> >
> > > > >
> > > > > >
> > > > > > 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.
> [Lizhong] How about add the following in s3: for the local PE, before 
> processing new configuration changing, the above message exchange 
> process should be finished.
>
> > >
> > >
> > > > >
> > > > > >
> > > > > > 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.
> [Lizhong] I will add a sentence in point "i" to say so. How about below:
> Note: above Label Release message and Label Withdraw message sending 
> does not require specific sequence.
>
> > >
> > > > >
> > > > > >
> > > > > > 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.
> [Lizhong] the passive role is not for any specific cases. The passive 
> role is for the processing of message (e.g, label mapping, label 
> request). I will explicitly say that in the section.
>
> > - 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] the control word configuration changing talking about in 
> this draft only happens on T-PE, not S-PE. The S-PE is a passive role 
> for the message processing. I will make this clear in the draft.
>
> > >
> > > > > [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.
> [Lizhong] accept
> > >
> > > > > >
> > > > > > 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.
> [Lizhong] ok, I could add Label Withdraw there.
> >
> >
> >


-- 
For corporate legal information go to:

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