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

[Lizhong Jin<[e-mail]>]

This email is to send the review discussion to PWE3 list as the request 
from AD.

Thanks
Lizhong
 

Lizhong Jin wrote 2012/06/21 22:43:54:

> 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 
mighthappen 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 
changesshould 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 clearthat 
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.
> > 
> > 
> >