-- 
For corporate legal information go to:

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


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


> Hi Elwyn,
> Please see inline below.
> 

> Thanks
> Lizhong
> 

> Elwyn Davies <elwynd@folly.org.uk> 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 <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 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.

> > 

> > 

> >