Subject: [mpls-tp] New version of WG Linear Protection draft

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 26 Jul 2010 19:04:19 +0200

Hi all,

I would like to bring to your attention the existence of a new version
of draft-ietf-mpls-tp-linear-protection that will be the version that
will be presented to the WG on Wed.  

Note that this version is greatly changed from the previous version, as
a result of some comments that were received after the Anaheim meeting
and the reconsiderations that these prompted.  The authors would
appreciate review comments of this new version so that we can move this
forward in the near future.

Best regards,
 
Yaacov Weingarten
Industry Environment, Packet Transport
Nokia Siemens Networks
Hod Hasharon, Israel 45241
Tel: +972-9-775 1827
Mob: +972-54-220 0977

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Mon, 26 Jul 2010 23:54:24 +0200

Could somebody explain to me what was the cutoff deadline of July, 12 intended for?

Thanks in advance

Italo

________________________________
Da: [email-masked] [mailto:[email-masked]] Per conto di Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Inviato: lunedì 26 luglio 2010 19.04
A: [email-masked]
Oggetto: [mpls-tp] New version of WG Linear Protection draft

Hi all,

I would like to bring to your attention the existence of a new version of draft-ietf-mpls-tp-linear-protection that will be the version that will be presented to the WG on Wed.

Note that this version is greatly changed from the previous version, as a result of some comments that were received after the Anaheim meeting and the reconsiderations that these prompted.  The authors would appreciate review comments of this new version so that we can move this forward in the near future.

Best regards,

Yaacov Weingarten

Nokia Siemens Networks

Tel: +972-9-775 1827

Mob: +972-54-220 0977

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 27 Jul 2010 10:23:18 +0200

Sorry that I misspoke - what will be presented are the considerations
(based on comments) that led the editors and authors to rework the I-D
and how we are working at fixing the concerns raised, and that this new
version is based on those considerations.

The main point is that we request that you review the new version and
submit more comments so that we can advance the work between now and
Beijing!

Best Regards,

yaacov

From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Sent: Monday, July 26, 2010 20:04
To: [email-masked]
Subject: [mpls-tp] New version of WG Linear Protection draft

Hi all,

Best regards,

Yaacov Weingarten

Nokia Siemens Networks

Tel: +972-9-775 1827

Mob: +972-54-220 0977

---

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

Best Regards,

yaacov

Hi all,

Best regards,

Yaacov Weingarten

Nokia Siemens Networks

Tel: +972-9-775 1827

Mob: +972-54-220 0977

---

From: "t.petch" <[email-masked]>
Date: Tue, 27 Jul 2010 18:13:32 +0200

----- Original Message -----
From: "BUSI, ITALO (ITALO)" <[email-masked]>
To: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>;
<[email-masked]>
Sent: Monday, July 26, 2010 11:54 PM
Subject: [mpls-tp] R: New version of WG Linear Protection draft

Could somebody explain to me what was the cutoff deadline of July, 12 intended
for?

<tp>
to allow people adequate time to review I-Ds in advance of a meeting by
preventing people from submitting, at the last minute, a much revised
document for discussion.

</tp>

Thanks in advance

Italo

________________________________
Da: [email-masked] [mailto:[email-masked]] Per conto di
Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Inviato: lunedì 26 luglio 2010 19.04
A: [email-masked]
Oggetto: [mpls-tp] New version of WG Linear Protection draft

Hi all,

I would like to bring to your attention the existence of a new version of
draft-ietf-mpls-tp-linear-protection that will be the version that will be
presented to the WG on Wed.

Note that this version is greatly changed from the previous version, as a result
of some comments that were received after the Anaheim meeting and the
reconsiderations that these prompted.  The authors would appreciate review
comments of this new version so that we can move this forward in the near
future.

Best regards,

Yaacov Weingarten

Nokia Siemens Networks

Tel: +972-9-775 1827

Mob: +972-54-220 0977

--------------------------------------------------------------------------------

> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: Zhi-Wei Lin <[email-masked]>
Date: Tue, 27 Jul 2010 19:23:30 -0400

New version of WG Linear Protection draft
Hi Yaacov,

I sent the below previously but it didn't seem to reach the mailing list, so
this is a resend...

It seems the new version did not address some of my comments sent for the
1st version? http://www.ietf.org/mail-archive/web/mpls/current/msg04094.html</exchweb/bin/redir.asp?URL=http://www.ietf.org/mail-archive/web/mpls/current/msg04094.html>

In addition to those from 1st version, below are some comments on the newest
(2nd) version:

   - 3.1.1, p. 9: Server layer alarm indication mentions configurability of
   a hold-off timer. In what document is this configurability specified?
   - 3.1.1, p. 9: control plane mentioned compliance with RFC 4872 when
   GMPLS used. A sentence should be added that if GMPLS is used, then this
   document will no longer apply since the two protocols seem to be
   incompatible. Can both co-exist in the same network with some LSPs being
   controlled by GMPLS while other LSPs being controlled by this document's
   protocol?
   - 3.1.1, p. 9: clear description: misspelled "opeartor". Should be
   "operator"
   - 3.1.1, p. 10: Clear Signal Fail: heading should be changed to "Clear
   Fail/degrade condition". Since signal degrade is supported, I assume this
   command should clear either, thus title should apply to both not just
   "signal fail"
   - 3.1.1, p. 10: Forced Switch and Manual Switch should have the same 1st
   sentence. So manual switch should read: "if the operator requested that
   traffic be switched from one of the working paths to the protection path".
   - 3.1.2, p. 10: general question: which field is carrying the remote
   indications? I assume these are the PSC/FPath/Path messages? Maybe a
   statement to that effect would help.
   - 3.1.2, p. 10: remote SF: "this remote message shall include an
   indication of which transport path is affected...", how is this done? I do
   not see any fields in the message to indicate which transport path is
   affected? If this is strictly indicating "working or protect", then instead
   of above text, it should read: "...shall include an indication of *whether
   the working or protect* path is affected..."
   - 3.1.2, p. 10: remote SF: last sentence states that the control logic
   can determine whether failure is uni or bidirectional. I assume this is
   handled by comparing the local server layer/OAM/control plane info and the
   received remote info. A sentence to that effect would help clarify this,
   such as: "PSC Control Logic determines failure as unidirectional or
   bidirectional by examining the local server layer/OAM/control plane
   indications and the received/remote requests."
   - 3.1.4, p.11-12 & 4.1/ p.14: redundant text on the PSC message intervals
   and default values. Text should only appear in one section to avoid
   redundant specification. Suggest to keep in 4.1, and remove from 3.1.4.
   - 4.1, p. 13: 1st para states that control packet transport over
   protection path only. In that case, if the protection path is failed and
   operator issues a Lockout command, how would the remote LER receive the "LO"
   command? Maybe it doesn't matter since LO prevents use of protection path
   anyway? A statement regarding this may be helpful.
   - 4.1, p. 14: 2nd para: default 3-message is 3.3 ms. What is the
   configurable value range and steps? Is it 1 ms to 10 ms, with 0.1 ms
   increments? What about the continous w/ default at 5 sec? Is the range from
   1 sec to 60 sec, with 1 sec increments? Since you are transmitting
   configuration info in the PSC messages (e.g., PT field is a configured field
   that you are advertising), these transmission values should also be
   advertised as part of the PSC message to ensure that all LERs in a network
   are consistently configured. With the above suggested range, I assume (2)
   8-bit fields are adequate for this.
   - 4.1, p. 14: last sentence of last para: "...fail condition is detected
   on the protection path, the received PSC..." This is not possible. If the
   PSC message is sent only on protection path and protection path is failed,
   there is no received PSC message.
   - 4.2.2, p. 15: general: this section makes reference to setting of FPath
   and Path values, and seems to overload the meaning of "0" for FPath. I
   suggest that
   - "0" for FPath means no anomaly,
      - "1" for FPath means "anomaly on protection path", and
      - "2" for Fpath means "anomaly on working path".
      - This will avoid the overloading, and also (see later comments)
      provide a more clear indication of status of links during
message exchanges.
      - 4.2.2, p. 15: general: signal degrade is one of the conditions that
   needs to be handled, but no code is defined for this. Please include a
   signal degrade indication.
   - 4.2.2, p. 15: general: the various fields (PSC, FPath) seem to suggest
   that only a single fail/degrade condition can exist on either working or
   protect. What messages would be sent if working is in failed state and
   protect is in degraded state? There does not seem to be any way to indicate
   this. I suggest the following changes:
   - PSC Request field has a single "Detected Fault Condition" message. The
      type of fault and applicability of fault would be described by FPath field
      - 8-bit FPath be divided into (2) 4-bit fields, one is FPath-Protect
      and one is FPath-Working (can be shown in message as 0/0). This
way you can
      signal condition of protection and working paths independently of each
      other. Each of the two 4-bit fields would be:
      - "0": no anomaly
         - "1": Signal Fail detected
         - "2": Signal Degrade detected
         - 4.2.2, p. 15: lockout: "both FPath and Path should be set to 0".
   "0" for Fpath means anomaly on protection path, which may not be the case.
   If "0" is overloaded to mean ignore, you may have situation of failure or
   degrade of protection or working path that you would want the remote LER to
   know about during a LO process (meaning FPath should not be ignored as it
   continues to provide valid status of the working or protection path even
   during LO procedure).
   - 4.2.2, p. 15: forced switch should be renamed "forced switch to
   protection"
   - 4.2.2, p. 15: manual switch should be renamed "manual switch to
   protection"
   - 4.2.2, p. 15: forced switch: how does FPath indicate that the working
   path is being blocked? FPath is defined as indicating the failure/degrade
   condition of the path, not the blocking of the path? Is this field being
   overloaded again? I suggest to delete this sentence as it does not add any
   clarification to use of forced switch.
   - 4.2.5, p. 16: see above comments regarding reformating this to two
   separate fields, one for protection and one for working.
   - 4.3.2, p. 18: signal degrade needs to be added and prioritized (signal
   degrade on protection, signal degrade on working inserted between #5 & #6)
   - 4.3.3: p. 19-28: general: many of the codes used here have overloaded
   the FPath field and difficult to know what is the exact condition of working
   and protect paths. For example, 4.3.3.1, p. 19 local forced switch produces
   code of "FS(1,1)" -> FPath = 1 means anomaly on working path. This is not
   the case, the condition of the path could be: protect is clear, degraded or
   failed, and working is clear, degraded or failed. The condition of the paths
   have nothing to do with whether a forced switch is issued by an operator. If
   my above suggestions are accepted, then the codes can be:
   - FS(0/0,1) = protect is clear and working is clear, but a forced switch
      is issued
      - FS(0/1,1) = protect is clear and working is failed, but forced
      switch is issued
      - FS(0/2,1) = protect is clear and working is degrade, but forced
      switch is issued
      - FS(2/0,1) = protect is degraded and working is clear, but forced
      switch is issued
      - etc.
      - With this, not only can control logic be able to act on the FS
      command, but also have information regarding the extent of the
condition for
      both working and protection paths
      - 4.3.3.1, p. 19: need to add signal degrade as an input
   - 4.3.3.1, p. 19: in many cases the message sent depends on whether the
   protection is unidirectional or bidirectional. For example, for local signal
   fail on working case, Path = 0 for unidirectional protection, and Path = 1
   for bidirectional protection, so the message should be SF(0/1,0) =
   unidirectional protection, SF(0/1,1) = bidirectional protection
   - 4.3.3.2, p. 20-21: general: Transition from unavailable state to
   Protecting failure state (or Protecting administrative state) is also
   possible. If unavailable state is entered due to a signal failure-protection
   or signal degrade-protection, and a lockout is later issued (or a signal
   fail-working is detected when original was signal degrade-protection), then
   transition would be to protecting failure state. Please include this
   scenario as part of 2nd para. or after 2nd para.
   - 4.3.3.3, p. 22: general: as with other sections, add text on the
   possible transitions to different states before going into details of each
   response. For example if you are in protecting administrative state due to
   manual switch, then protecting administrative state may transition to
   unavailable state upon detection of signal fail-protection, protecting
   failure state upon detection of signal fail-working, and normal state upon
   clear command.
   - 4.3.3.4, p. 24: general: as with other sections, add text on the
   possible transitions to different states before going into details of each
   response. For example if you are in protecting failure state due to signal
   degrade-working, then protecting failure state may transition to unavailable
   state upon lockout command, stay in protecting failure state upon detection
   of signal fail-working, protecting administrative state upon forced switch
   command, and wait-to-restore state upon clear of signal fail/degrade.

That's it for now. I hope that the authors would respond to each point
individually so that I know whether my comments are being addressed or that
they are meaningless and to be ignored (the original comments I made I did
not see any point-by-point response).

Thanks
Zhi