Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-linear-protection-07.txt

From: Lou Berger <[email-masked]>
Date: Sun, 03 Jul 2011 11:47:23 -0400

Hello,

I have been selected as the Routing Directorate reviewer for this
draft. The Routing Directorate seeks to review all routing or
routing-related drafts as they pass through IETF last call and
IESG review, and sometimes on special request. The purpose of the
review is to provide assistance to the Routing ADs. For more
information about the Routing Directorate, please see
http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing
ADs, it would be helpful if you could consider them along with any
other IETF Last Call comments that you receive, and strive to
resolve them through discussion or by updating the draft.

Document: draft-ietf-mpls-tp-linear-protection-07.txt
Reviewer: Lou Berger
Review Date: 7/3/2011
IETF LC End Date: 2011-07-05
Intended Status: Standards Track

Summary:

I have some concerns about this document that I think should
be resolved before publication.

Comments:

Overall the document is well written and provides a lot of
detail.  That said, I see a number of issues. Some of the
identified issues may be resolved through discussion (i.e.,
correction of my misinterpretations!), others will require
changes to the text.

In terms of readability, the document uses a state machine based
approach to define protocol behavior.  While definition of state
machines is not novel in protocol specifications, I did find it a
bit hard to follow the presentation in this document.  Particularly
from the perspective of verifying that all cases are covered.  The
state table in Appendix A is certainly helpful, but I would have
preferred that it be normative as well as be accompanied by one or
more state diagrams.  There are also inconsistencies in use of
RFC2119 and numbering conventions, which are pointed out below.

Line numbers obtained from
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-mpls-tp-linear-protection-07.txt
will be used in this review.

Major Issues:

- State synchronization after message loss:

  The PSC protocol uses a soft-state messaging approach to
  synchronize state between PSC protocol peers. Two basic
  implications of soft-state messaging are (a) that peers can and
  will get of sync during periods of message loss, and (b) each
  state message must represent the full and *current* state of the
  message sender. (b) is critical for recovering for one or more
  lost messages.  A key point is that intermediate state changes
  will not be visible to a peer during periods of prolong PSC
  message loss.  So this all leads to two discussion points: state
  convergence time and loss of intermediate states.

  - State convergence time:

  The current PSC protocol definition, see section 4.1, has
  messages representing a change being retransmitted 3x fast, then
  followed by a less frequent "continuous" refresh message (5
  second default refresh period).  An implication of this approach
  is that peers may get out of sync for {n * refresh interval}
  after a period of PSC message loss.  To me this seems like a
  potentially long period of time.  A simple change that would
  improve protocol behavior would be to trigger the 3x fast
  transmission whenever a peer reports that it has recovered from
  a reception problem (remote SFc).  This approach is already in
  place for on case (remote NR).  For simplicity, perhaps it would
  be best to require whenever a peer reports any change.  (I can
  provide proposed language if it helps.)

  Another alternative would be to adopt the changes that were made
  to RSVP, another soft state protocol, to address operationally
  observed message loss.  (See the reliable message delivery
  sections of RFC 2961.) But this is probably too major a change
  at this time.

  An easily fixed related point: Section 4.1 is missing the formal
  definition of the sending of refresh messages.  (It is presented
  as informative in section 4.3.3.) Propose adding at line 637
  something along the lines of:

     After the transmission of the three rapid messages, the LER
     MUST retransmit the most recently transmitted PSC message on
     a continual basis.

  - Loss of intermediate states

  As defined, PSC messages don't represent full sender state as is
  the norm for soft-state protocols, but rather provide the most
  recent 'request' (see section 4.2.2.). This means that if there
  are any states that can only be reached via intermediate states
  (as opposed to just via the same event type/request), the state
  machines between sending and receiving peers can get out of
  sync.  I haven't convinced myself that any of these cases exists
  (state diagrams would make it perfectly clear!), so am not sure
  this is a blocking issue. I mention it here to ensure all aware
  of the issue and those more familiar with the protocol (perhaps
  even working on implementations) can confirm that they too don't
  see such cases.

- Priority of inputs (FS vs SF-P)

  Per section 4.3.2, FS is lower priority than SF-P.  Per lines
  397/394 and 400-403, section 6.1.2 of [SurvivFwk], and RFC4427
  the difference between MS and FS is that an MS triggered switch
  to the protection path only will occur when the protection path
  is in normal state (i.e., no SF-P) while FS ignores the state of
  the protection path.  Unless I'm missing something (which is
  always possible!) this means that FS should be *higher* priority
  than SF-P.  This impacts the handling of the FS input for
  multiple states in section 4.3.3. and Appendix A.

- Relationship to data plane behavior

  Section 3 briefly talks the "protection switching actions" that
  an LER may take, and that the "MEP SHOULD initiate a protection
  switch operation" (lines 417/8).  But the document really stops
  short of defining what actions a local LER should take on
  particular state changes.  It seems to me that
  required/recommended data-plane behavior should be explicitly (rather
  than implicitly) identified in section 4.3.3.

Minor issues

- use of RFC2119 language

  The following are cases where it looks like RFC2119 language was
  improperly used or omitted.  There are also cases where SHOULD
  is used, but handling of other cases is not specified:

  - Section 3, lines 280-282 say that the "logical decomposition"
    depicted in Figure 1 and described in the remainder of the
    section is for "for descriptive purposes" and external
    behavior is defined in Section 4.  To me this means that all
    of section 3 is informative in nature and *not* normative.  Is
    this correct?

    If it is correct, i.e., the section is informative, then
    RFC2119 language needs to be removed from the section.

    Iff it is incorrect, i.e., the section is normative, than the
    following are problematic:

    - Line 330, needs to use rfc2119 language to parallel line 332

    - Lines 358, 364, 418, 423, 512, 518, 574, 576, 585.  Are
      there cases where it is reasonable for the "SHOULDs" to not
      be followed?  In other words aren't these "MUSTs"?  I not,
      probably should have a bit of text exploring these cases.

    - Lines 427, 435: this usage of "SHALL" really seems
      informative in nature, propose: s/SHALL include/includes

    - Line 370: s/shall/SHALL

    - Line 479: s/should/MUST

    - Line 490: if informative (which I think it is): s/should/are
      if normative: s/should/MUST

    - Line 503: s/shall/SHALL

    - Line 521: s/shall/SHALL

    - Line 579: s/should/MUST

   Again, these changes presume that this section is normative, if
   informative, then usage of 2119 language needs to be removed
   from the section.

  - Line 612, 617: these are informative/narrative sentences
    s/MUST/must|will
    s/SHALL/are

  - Lines 629, 638: aren't these MUSTs?  If not needs some
    explanatory text.

  - Line 643 missing "default": s/an/a default

  - Section 4.3.3: There are a lot of "SHOULDs" in this section.
  Given this text relates to the synchronization of state between
  peers, what happens when one peer implements the "SHOULD" and the
  other peer does not?  In order to avoid implementations that are
  compliant with this document but can't interoperate, either this
  case needs to be covered or these "SHOULDs" need to be "MUSTs".

- Lines 205-206: The meaning of "maintain traffic" is not clear.

- Lines 215-217: suggest making it explicit (rather than implied)
  that 1:1 unidirectional and 1:n are "out of scope of this
  document"

- Lines 225-219: so is support for 1+1 for P2MP in or out of
  scope? This section really should be explicit on this point.

- Lines 353 and 354.  draft-ietf-ccamp-mpls-tp-cp-framework and
  [SurvivFwk] allow for the use of [RFC4872] or [RFC4873].  Your
  draft excludes [RFC4873], is this intentional?  If so, why?

- Lines 400-403, 444-446.  The definitions for local MS and remote
  MS are subtly different. 400-403 says "switched from the working
  path to the protection path".  While 444-446 says "switch the
  traffic to the path that was not being used previously".  While
  I personally prefer this definition, Section 4.3.3 seems to say
  that 444-446 should read "switch the traffic from the working
  path to the protection path".

- Line 665. No definition is given for the "Reserved" field.  A
  typical definition for such fields is "The Reserved field MUST
  be set to zero on transmission and MUST be ignored on receipt."

- Lines 678-681. Are 2 bits really sufficient for the long term?
  There are 23 unused bits in the header, perhaps you want to give
  one to this field?

- Numbering consistency

  The document is inconsistent with how it indicates field values.
  Unless there's a sub-structure to a field, e.g., a flags field,
  values should be listed in decimal not in binary.  Impacts lines
  688, 692, 699, 708, 716, 723, 729, 737, 750-755.  If these lines
  really refer to bit fields, then the bits need to be defined.

- Line 732.  Is DNR limited to transmission behavior only?  If not,
  need to change this line.

- Lines 742-760. Are 2 bits really sufficient for the long term?
  There are 23 unused bits in the header, perhaps you want to give
  one to this field?  If there really is a need for future
  extensions (per line 755) then a wider field is really needed.

- Lines 774-784: How is the absence of faults indicated? Perhaps 0
  or 255 should be used for this case?

- Lines 820: strictly speaking this field is not part of "TLV
  information", also receive behavior is not specified (see
  comment on line 665 above.)

- Lines 822-824, The TLV format definition is missing. (I.e. how
  big are the T & L fields, does L include T&L or not, are there
  any padding requirements...)

- Lines 853, 856, 866: text  is informative, should not include
  RFC2119 language.

- Handling of PA:F:L/FS after SFC-P

  If for some reason the prioritization of FS and SF-P remain as
  is (see major issue above), the current state machine
  definitions result in a the FS state being lost when an SF-P is
  cleared.  Consider the case of the following states and inputs
  (in parentheses): N--(FS)--> PA:F:L--(SF-P)--> UA:P:L--(SFc)-->
  WTR--(WTRExp)--> WTR--(remNR)-->N

  As the operator set FS, shouldn't the state return to PA:F:L not
  N?

- SF-P can mask SF-W

  Consider the scenario where the protection path fails and then
  the working path fails.  As I read Section 4.3.3 and appendix a,
  the order of states and inputs (in parentheses) are as follows:
  N--(SF-P)--> UA:P:L--(SF-W)--> UA:P:L--(SFc-P)--> N (sending NR(0,0))

  This seems wrong. When the protection path SFc is received
  shouldn't the result be a protection switch / PF:W:L (NR(1,0)?

- Remote SF impacts protection switching when using unidirectional
  protection

  As I read section 4.3, a remote SF will impact the behavior of
  the protection bridge of an LER even when 1+1 unidirectional
  protection is being used.  My understanding is that the bridges
  are supposed to switch autonomously in this mode.  Did I miss
  something?

- IANA Considerations, section 5
  Don't you want an IANA registry for the TLV types that may be
  defined in the future per section 4.2.7?

Nits:

Line 146: s/bandwidth/resources
Line 147: s/is/are
Line 393: Add (SFc)
Line 417: Expand MEP
Lines 519-526: These lines duplicate what's immediately following
               in 3.6.1, suggest dropping them.
Line 559: s/is recovering/has recovered
Line 592: the terminology SF(1,0) hasn't been defined at this
          point in the document, need a forward reference.
Line 730: s/is recovering/has recovered
Line 853: s/The value/Except during a protection switch, the value

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 5 Jul 2011 11:15:17 +0300

Lou, and all,

>   than implicitly) identified in section 4.3.3.

I would like to bring to your attention a recent email thread "1+1 linear LSP protection and MPLS-TP data plane: are they compatible?" 0n the MPLS WG mailing list:

- http://www.ietf.org/mail-archive/web/mpls/current/msg06581.html
- http://www.ietf.org/mail-archive/web/mpls/current/msg06582.html
- http://www.ietf.org/mail-archive/web/mpls/current/msg06583.html
- http://www.ietf.org/mail-archive/web/mpls/current/msg06584.html
- http://www.ietf.org/mail-archive/web/mpls/current/msg06585.html
- http://www.ietf.org/mail-archive/web/mpls/current/msg06586.html
- http://www.ietf.org/mail-archive/web/mpls/current/msg06587.html
- http://www.ietf.org/mail-archive/web/mpls/current/msg06588.html
- http://www.ietf.org/mail-archive/web/mpls/current/msg06590.html
- http://www.ietf.org/mail-archive/web/mpls/current/msg06592.html.

This thread was all about implementing the Rx selector for 1+1 protected LSPs within the constraints on the MPLS and PW data planes set by RFC 3031, 3032 and 4447.

The original specific issue I've raised in this thread has been eventually resolved.

But the general problem that IMHO should be addressed by the draft is the difference between the MPLS data plane and those of traditional transport networks (SONET/SDH, OTN) regarding the way the client traffic and server path OAM are separated:
- in the case of the latter, the server trail OAM is an integral path of the server "overhead": it cannot be removed or suppressed
- in the case of the former, the OAM is just one more "labeled client" carried by the server: if it is not present, the data plane of the server path could not care less.

I believe that this difference deserves careful analysis (either in the draft in question or in a more generic document).

Regards,
     Sasha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Lou Berger
> Sent: Sunday, July 03, 2011 6:47 PM
> To: [email-masked]
> Cc: [email-masked]; draft-ietf-mpls-tp-linear-
> [email-masked]
> Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-linear-protection-
> 07.txt
>
> Hello,
>

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Lou Berger <[email-masked]>
Date: Tue, 05 Jul 2011 07:07:39 -0400

Sasha,
	I think you may be reading too much into my comment.  I was just asking
for a (consistent level of) description of bridge behavior...

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 05 Jul 2011 07:33:29 -0400

Yaacov,

Thank you for the quick response to the majority of the topics I raised.

I only have a response to a few of your responses.  See below.  (I've
cut out closed points.)

On 7/5/2011 5:14 AM, Weingarten, Yaacov (NSN - IL/Hod HaSharon) wrote:
> Lou, hi
> 
> First off - I would like to thank you for your very thorough and
> complete review of the document and the protocol.

critiques are always easier than authoring...

> ...

> [yw>] 358 - will be changed to be informative, 364 - will change to
> SHALL, 415 & 418 - will change to informative, 423 - ??, 512, 515, 518 -
> will change to informative, 574, 576, & 585 - will change to informative

not sure what the '??' means here, are you asking a question?

> ...

> [yw>] Will add a statement that this is out-of-scope and may be
> described in a separate applicability document.

okay, but note that this means [RFC5654] 65.C. is not covered by the
document.

> ...

> [yw>] Will consult regarding this!

> ...

> [yw>] Will consult regarding this!

> [yw>] The current understanding was that this field is ignored when the
> Request field is not indicating a fault condition see lines 725 & 733

I did see those, I was suggesting to use an explicit rather than
implicit value for such cases.  If you leave the values as is, then
section 4.2.5 really should say that such cases exists.  Perhaps, add
something along the lines of "When a fault condition is indicated in the
PSC Request field," to the start of line 776.

> ...

> [yw>] Will consult regarding this.

> ...

> [yw>] What you are suggesting, IMHO, is an optimization.  If the FS is
> still being asserted, then immediately after going into Normal the FS
> would be recognized and cause the domain to reenter PA:F:L.  We (i.e.
> the authors) made a conscious decision to not describe this optimization
> after a rather lengthy discussion when it was brought to our attention
> and this was explained to the different commenters at the time.
> 
> - SF-P can mask SF-W
> 
> [yw>] Similar to the previous consideration.
> 

Okay, I understand the approach the authors are taking.  Although to
ensure proper implementation and interoperability, this approach needs
to be made explicit in the document, probably somewhere in section 4.3.
Furthermore, Section 3 needs to address this in the description of
generation and handling of "local requests".

>   defined in the future per section 4.2.7?

You may have missed the prior 2 comments.

> ...

Thanks again for the quick response.

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 05 Jul 2011 08:50:08 -0400

Yaacov,
	I'm also not sure which line I was referring to either.  There's
probably some other "SHOULD" in the document that this applies to...

Lou

On 7/5/2011 7:40 AM, Weingarten, Yaacov (NSN - IL/Hod HaSharon) wrote:
> Lou, hi
> 
> Just a note regarding the "423 ??" - It was just noting that I could not
> find any Normative text on line 423.  Could be that you meant 427, that
> I listed separately that I will remove the normative SHALL!
> 
> I did not miss those last two notes - but I need to consult with others
> (possibly the WG chairs) on these.
> 
> BR,
> yaacov
> 
> From: ext Lou Berger [mailto:[email-masked]] 
> Sent: Tuesday, July 05, 2011 2:33 PM
> To: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: RtgDir review: draft-ietf-mpls-tp-linear-protection-07.txt
> 
> Yaacov,
>

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 5 Jul 2011 11:14:01 +0200

Lou, hi

At this point, I would like to address some of the "Minor issues" that
you pointed out.  I think that the Top-level issues that you raise may
need a little more time and consideration on the part of the entire
group of authors and will be addressed in a separate message.

You wrote (first part of message snipped):

Minor issues

  - Section 3, lines 280-282 say that the "logical decomposition"
    depicted in Figure 1 and described in the remainder of the
    section is for "for descriptive purposes" and external
    behavior is defined in Section 4.  To me this means that all
    of section 3 is informative in nature and *not* normative.  Is
    this correct?
[yw>] In general Section 3 is meant to be informative in all issues
relating to the logical blocks in the decomposition and the actions that
they may take in processing the protocol.  However, there are additional
topics that are mentioned in this section, e.g. use of control-plane
recovery, triggers for protection, use of timers, that (IMHO) may
include some normative statements.  Therefore, I will try to relate to
each of your comments below based on this division of the text.

    - Line 330, needs to use rfc2119 language to parallel line 332
[yw>] Will correct the sentence to read - "The commands Forced Switch,
Manual Switch, Clear,
and Lockout of Protection (..) MUST be supported."

[yw>] OK

    - Line 370: s/shall/SHALL
[yw>] Think it is informative (based on the general assessment of
Section 3)

    - Line 479: s/should/MUST
[yw>] Same as above (370)

    - Line 490: if informative (which I think it is): s/should/are
      if normative: s/should/MUST
[yw>] will change to "are"

[yw>] OK

    - Line 521: s/shall/SHALL
[yw>] Same as above (370)

    - Line 579: s/should/MUST
[yw>] Same as above (370)

   Again, these changes presume that this section is normative, if
   informative, then usage of 2119 language needs to be removed
   from the section.
[yw>] Will remove the 2119 language from - 351, 358, 367, 427, 435, 463,
475, 478, 562

[yw>] OK

[yw>] OK

[yw>] OK

[yw>] Will change to SHALL/MUST

- Lines 205-206: The meaning of "maintain traffic" is not clear.
[yw>] Will correct to read "...when there is a need to verify that the
traffic continues to be transported on a bi-directional LSP that is
co-routed."

- Lines 215-217: suggest making it explicit (rather than implied)
  that 1:1 unidirectional and 1:n are "out of scope of this
  document"
[yw>] Will add the following text to the end of the statement - "and are
out of scope for this document"

- Lines 353 and 354.  draft-ietf-ccamp-mpls-tp-cp-framework and
  [SurvivFwk] allow for the use of [RFC4872] or [RFC4873].  Your
  draft excludes [RFC4873], is this intentional?  If so, why?
[yw>] Not intentional - will add the reference

[yw>] Will correct lines 444-446 to align with 400-403

- Line 665. No definition is given for the "Reserved" field.  A
  typical definition for such fields is "The Reserved field MUST
  be set to zero on transmission and MUST be ignored on receipt."
[yw>] Will change the Reserved fields to Reserved1 & Reserved2 and add
the description appropriately.

- Numbering consistency

[yw>] Will use the decimal values

- Line 732.  Is DNR limited to transmission behavior only?  If not,
  need to change this line.
[yw>] Will change "...is requesting that the protection domain continues
to transmit data over the protection path," to read "...is requesting
that the protection domain continues to transport the data as if it is
in a protecting state,"

- Lines 820: strictly speaking this field is not part of "TLV
  information", also receive behavior is not specified (see
  comment on line 665 above.)
[yw>] See reply to line 665 above

[yw>] OK

- SF-P can mask SF-W

Nits:

Line 146: s/bandwidth/resources
[yw>] OK
Line 147: s/is/are
[yw>] OK
Line 393: Add (SFc)
[yw>] OK
Line 417: Expand MEP
[yw>] Changed to LER, this is the only appearance of MEP in the document
and therefore the expansion seems extraneous.
Lines 519-526: These lines duplicate what's immediately following
               in 3.6.1, suggest dropping them.
[yw>] OK
Line 559: s/is recovering/has recovered
[yw>] OK
Line 592: the terminology SF(1,0) hasn't been defined at this
          point in the document, need a forward reference.
[yw>] Changed the text to read "PSC messages that indicate a SF
condition on the working path and that the protection path is not being
used to transport protected traffic (as described in the next section)."
Line 730: s/is recovering/has recovered
[yw>] OK
Line 853: s/The value/Except during a protection switch, the value
[yw>] OK

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 5 Jul 2011 13:40:18 +0200

Lou, hi

BR,
yaacov

-----Original Message-----
From: ext Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, July 05, 2011 2:33 PM
To: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Cc: [email-masked]; [email-masked];

Yaacov,

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 26 Jul 2011 16:40:06 -0400

Yaacov, Authors,
	Thank you for taking the time to provide a detailed response.  Yaacov
and I had a brief discussion on this mail and I tried to capture the
high points below.  I expect that Yaacov will run the details to ground.

On 7/20/2011 8:29 AM, Weingarten, Yaacov (NSN - IL/Hod HaSharon) wrote:
> Note:  Resent with the promised attachment!!
> Lou, hi
> 
> I wanted to get back to you on the issues that were not addressed in our
> previous exchanges and verify that we can get closer to resolution of
> the issues, based on answers from some of the other authors and Ads -
> see my proposed resolutions below - 
> 
> Would appreciate your reply - so that we can close the actions prior to
> Quebec.
> 
> Thanx and Best Regards,
> yaacov
> 
> Cc: [email-masked];
> Subject: RtgDir review: draft-ietf-mpls-tp-linear-protection-07.txt
> 
> Hello,
> 
> [yw>] After discussion amongst the authors and AD, we suggest to add the
> following statement to Section 4.1 (after the paragraph that explains
> the general behavior):
> "An implementation that is concerned about the potential for end points
> to become
> out of sync as a result of lost messages MAY choose to send messages
> more
> frequently at every state change. Such behavior is consistent with the
> protocol
> specified here and will be handled correctly by the receiver."

[Comment from before discussion]
So the result is out of sync in some cases and not in others, for some
implementations?  This seems like it will result in, at least,
operational confusion and, more likely, slower than expected protection
processing.  IMO requiring 3x on all state changes is simpler and less
likely to result in out of sync states for extended periods of time {n *
slow refresh interval}.  Note, I'm not suggesting the full fix that was
made to RSVP, just the wider use of a mechanisms that is already defined.

I'm not sure why you'd want this to be a MAY.  Is it to deal with
existing implementations?  If so, I suggest to at least make it a SHOULD
and drop the reference to motivation.

[From conversation]
Yaakov will discuss with co-authors to make this a MUST.

> [yw>] Will add this statement.
> 
> [yw>] After some involved discussion amongst the authors it was shown
> (in a spreadsheet supplied by Eric Osborne, attached) that there are no
> "catastrophic" scenarios of loss of synchronization between the two
> end-points.  Certainly there are no cases of unnecessary duplication of
> data packets (1+1 always duplicates the packets, but the receiving end
> point must only select one of these).  The only border case for 1:1
> protection is one where one LER may be sending data on W while the other
> LER may be sending the data on P.  When considering the cases that Eric
> points out, I think that they can be characterized to be in two
> situations that are both readily, aligned:
> 1. The cases of a one-sided identification (either an Operator command
> to one LER, or a unidirectional fault) of a trigger, that will be
> aligned when the far-end point reacts to the remote message.
> 2. The cases where one LER is in a Protection state and the other LER
> receives a Lockout of Protection command - this will be aligned when the
> protecting side receives the remote LO message.
> This is a side-effect of using a single phased protocol.  And in order
> to make this more clear in the document, I suggest that we add a
> statement to Section 4.3.1 (at the end of the second paragraph stating:
> "As a side-effect of using a single-phased protocol, there will be a
> short period during state transitions of one-sided triggers (e.g.
> operator commands, or unidirectional SF) when one LER may be
> transporting/selecting the data from one transport path while the other
> end point is transporting/selecting from the other transport path.  This
> should become coordinated once the remote message is received and the
> far-end LER performs the protection switching operation."
> Will this clarify the problem?
[from discussion]
The point of my comment was to raise this as a potential issue with
those who are more knowledgeable with the protocol.  Your assurance that
you have considered this possibility and there are no issues is all I
was looking for.  No text change is requested/needed.  So point should
be closed.

> [yw>] Other authors reminded me of the difference between data-plane
> linear protection and control-plane protection that directly affects
> this issue - Since the PSC messages are being transmitted over the
> protection path in the data-plane, then if there is a SF-P condition,
> these messages cannot be transmitted, so that if there is a FS at this
> point - there would be no way to notify the far-end LER!  Therefore, we
> are "forced" to up the priority of the SF-P to be higher than that of
> the FS!

[from discussion]
We agreed that there is a difference between FS and MS and in the case
of an SF-P this difference is lost.  I proposed that (a) the priority of
FS be raised above SF-P in this document and (b) you add a note (perhaps
in section 4.3.3) that when FS is issued when the protection path is in
a failed/errored state that it is possible that the remote side will not
act see the FS until the fault clears.  Yaacov will discuss with authors.

> [yw>] Not sure what your concern was here.  To my understanding the data
> plane behavior of the LER consists of the following possible actions -
> 1. Transmit a PSC message indicating the current state (Req + FPath +
> Path) of the LER, 2. Decide where the data should be transported, i.e.
> either on the Working or the Protection path, and 3. Decide from which
> path to select the data.  These actions are described in Sections
> 4.3.3.x, i.e. the PSC message is indicated in the bullets that explain
> the reaction to the input, the actions of where to transport (and
> select) the data is stated in the opening paragraph of each state, where
> (in some form or other) it states "When the LER is in this state, data
> is transported on ...".
> There was thought (amongst the authors) that the following statement in
> Section 3.2 was causing the concerns: " These remote messages indicate
> the status of the transport path from the viewpoint of the far-end LER,
> and may indicate if the local MEP SHOULD initiate a protection switch
> operation." And therefore we will change this to state: " Remote
> messages indicate the status of the transport path from the viewpoint of
> the far-end LER.  These messages may drive state changes on the local
> MEP, as defined later in this document."
> Will this be acceptable?
> 

[from discussion]
Agreed to use SHALL in the existing language related to data plane in
section 4.3.3.x. May also add a general comment stating that data plane
state is described per PSC state and not per transition/event.

> [yw>] <content snipped>  These were addressed in the previous exchanges
> 
> [yw>] addressed previously
> 
> [yw>] addressed previously
> 
> [yw>] addressed previously
> 
> [yw>] addressed previously
> 
> [yw>] addressed previously
> 
> [yw>] addressed previously
> 
> [yw>] addressed previously
> 
> [yw>] addressed previously
> 
> [yw>] addressed previously
> 
> [yw>] addressed previously
> 
> [yw>] After consultation - it seems that the feeling amongst the authors
> is to remain with only two bits as this would be rather disruptive for
> "early adoptions" of the standard that is already implemented and
> waiting for release.

fair enough.  I can understand not making changes that aren't absolutely
required.

> [yw>] addressed previously
> 
> [yw>] addressed previously
> 
> [yw>] While there was less reluctance to widen this field, we were still
> advised not to include changes that might involve going back to the WG.
> In addition, it is not clear to me that there is a need for additional
> bits for this field.

fair enough.  I can understand not making changes that aren't absolutely
required.

> [yw>] addressed previously

> [yw>] addressed previously
> 
> [yw>] Since this document does not describe any TLV fields, just a
> placeholder for future ones - do not feel that there is a need to
> specify this information at this point, but rather leave it to the
> documents that may define specific TLVs.  In answer to another point
> that you raise will request that IANA administer a registry of the
> future TLVs.
> 
> [yw>] addressed previously
> 
> [yw>] These were addressed previously

> generation and handling of "local requests".
[post discussion]

This issue is still open.  Yaacov to consider how to address in draft.

> [yw>] Will add statements as follows to clarify 1+1 unidirectional
> protection:
> 1. In Section 3.2 (Remote requests) at the end of the first paragraph:
> "When using 1+1 Unidirectional protection, an LER that receives a remote
> request SHALL NOT perform any protection switching action, i.e. will
> continue to select traffic from the working path and transport traffic
> on both paths."
> 2. At the end of the last paragraph of Section 4.3.1 stating: "For 1+1
> unidirectional protection, the state of the selector will only be
> switched in reaction to a local message.  When receiving a remote
> message, a LER that is configured for 1+1 unidirectional protection,
> will transfer to the new remote state, however it will continue to
> select data according to latest known local state."
> Will this clarify the protection actions for this protection scheme?
> 
> [yw>] Have added the request for an additional registry for the TLV
> types.
> 
> Nits:
> 
> [yw>] all addressed previously
> 

That's it.

Much thanks!

Lou

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 20 Jul 2011 14:15:42 +0200

Lou, hi

Thanx and Best Regards,
yaacov

-----Original Message-----
From: ext Lou Berger [mailto:[email-masked]] 
Sent: Sunday, July 03, 2011 6:47 PM
To: [email-masked]
Cc: [email-masked];

Hello,

Summary:

Comments:

Line numbers obtained from
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-mpl
s-tp-linear-protection-07.txt
will be used in this review.

Major Issues:

Minor issues

- Numbering consistency

- SF-P can mask SF-W

Nits:

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 20 Jul 2011 14:29:25 +0200

Thanx and Best Regards,
yaacov

-----Original Message-----
From: ext Lou Berger [mailto:[email-masked]] 
Sent: Sunday, July 03, 2011 6:47 PM
To: [email-masked]
Cc: [email-masked];

Hello,

Summary:

Comments:

Major Issues:

Minor issues

- Numbering consistency

- SF-P can mask SF-W

Nits: