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

[Lizhong Jin<[e-mail]>]

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