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

["Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[e-mail]>]

Zhi-Wei, hi

 

Thank you for your review of the new version, you seem to have been very
comprehensive.  Before I reply inline to your specific comments I would
like to make some general comments that may be cross-referenced in the
details.

 

1.	I cannot guarantee that all of your concerns will be resolved,
due to the nature of overlapping comments from different people and the
different considerations of the different editors.  However, I can
guarantee you that all your comments were taken into consideration.  I
wish to apologize for not sending an itemized reply - however, since we
received a number of differing comments, and we entered a process to try
and address all of them in a coherent manner, it was time-consuming and
then difficult to get back to each individual commenter.  However, I
will try to be more responsive in the future.
2.	The protocol that we are proposing in this draft is intended to
be a switching-coordination protocol, it is not a CC/CV OAM tool.  It is
a client of the management system - in the sense that the management
system is responsible for configuring certain parameters (e.g. timers)
and supplying switching triggers (e.g. operator commands).  Aside from
reporting problems of misconfiguration, there was no intention that the
protocol would report to anyone (except the opposite end-point of the
protection domain) that there is a reason for performing a traffic
switch.  Therefore, at any one point in time the protocol intends to
only report a single fail/degrade/block condition - multiple conditions
is the purview of the management system (IMHO).
3.	The question of dealing with Signal Degrade, is an open issue
(IMO) - there is an ongoing discussion on the mailing list regarding
another draft related to this issue.  The authors and the group need to
decide how to address this issue, if it is relevant.

 

Detailed answers inline below.

 

Best Regards,

yaacov

 

________________________________

From: ext Lin, Zhi-Wei [mailto:[e-mail]] 
Sent: Tuesday, July 27, 2010 19:41
To: Weingarten, Yaacov (NSN - IL/Hod HaSharon); [e-mail]
Cc: [e-mail]
Subject: RE: [mpls-tp] New version of WG Linear Protection draft

 

Hi Yaacov,

 

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

 

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?

[yw>] We were requested to remove this information from this draft.  Its
proper place would be in a management system document or MIB.  

*	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?

[yw>] I will add a phrase clarifying that the GMPLS procedures SHALL be
used exclusively.  I believe that you can run GMPLS only on a subset of
your network, so the answer to your second question should be - yes.

*	3.1.1, p. 9: clear description: misspelled "opeartor". Should be
"operator"

[yw>] will correct

*	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"

[yw>] See note 3 in the main body.  In general, I personally am confused
by SD and how to deal with it, or whether it shouldn't just be
considered a SF condition.

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

[yw>] will correct

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

[yw>] do not understand the question.  The remote indications are PSC
messages that are received at a point in time, and may be saved
internally by the state record (implementation issue)

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

[yw>] The message that is received from the remote end-point will be
SF(1,1) - if the failure condition is on the working path and SF(0,1) if
the failure condition is on the protection path. If we are talking about
1:n protection (which is out-of-scope for this document) and the failed
working path is #5 then the message received from the far-end will be
SF(5,5).  So can you please clarify the question?

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

[yw>] The last sentence of the bullet just highlights a given situation
without stating how this is determined.  The only way that the two cases
are differentiated is by one end-point identifying a SF condition while
the other end-point does (bi-directional  fault)  or does not
(uni-directional fault) identify the SF condition.  

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

[yw>] will correct

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

[yw>] There is a statement in section 4.3.3.2 that states that when in
Unavailable state the control messages may not be transmitted.

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

[yw>] See my previous answer concerning the ranges of the holdoff
timers.  The numbers that are given are only an example for 50ms
protection switching.

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

[yw>] Do you have a suggestion for how to better state this?

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

[yw>] This is problematic when we want to extend this for 1:n protection
and this is one of the reasons for the choice for the "overloading" that
you claim.

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

[yw>] See my note 3 above.

*	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

[yw>] See my note 2 above.  In any one message the coordination protocol
is only reporting a single failure. 

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

[yw>] The intention here is that the LO command indicates that the
affected path is the protection path (FPath=0) and that the protection
path is not carrying any working traffic (Path=0)

*	4.2.2, p. 15: forced switch should be renamed "forced switch to
protection"

[yw>] do not agree

*	4.2.2, p. 15: manual switch should be renamed "manual switch to
protection"

[yw>] do not agree

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

[yw>] section 4.2.5 states that FPath indicates the path that is
reporting a failure or affected by an administrative command - an
example of the latter would be the FS

*	4.2.5, p. 16: see above comments regarding reformating this to
two separate fields, one for protection and one for working

[yw>] See my previous answer

.

*	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)

[yw>] See my previous answers and note 3.

*	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

[yw>] See my previous answers and note 2

*	4.3.3.1, p. 19: need to add signal degrade as an input

[yw>] See my previous answers and note 3

*	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

[yw>] disagree - one of the requirements of protection is to maintain
the bidirectional paths, so that even if it is a unidirectional  failure
both end-points need to report Path=1 in protecting-failure state.

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

[yw>] Do not understand your scenario. If in unavailable state and you
receive a LO - you will remain in unavailable, since LO is blocking the
protection path not going over to protecting state.

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

[yw>] These scenarios are detailed in the responses to the particular
remote message.

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

[yw>] do not understand the scenario

 

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-Wei Lin, P.E. ([e-mail])

Communications Engineering/CPM

NYCT, 2 Broadway, D3.65, New York, NY 10004

Tel: [phone] / Fax: [phone]

 

 

________________________________

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Sent: Tuesday, July 27, 2010 4:23 AM
To: Weingarten, Yaacov (NSN - IL/Hod HaSharon); [e-mail]
Subject: Re: [mpls-tp] New version of WG Linear Protection draft

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: [e-mail] [mailto:[e-mail]] On
Behalf Of ext Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Sent: Monday, July 26, 2010 20:04
To: [e-mail]
Subject: [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

Industry Environment, Packet Transport

Nokia Siemens Networks

Hod Hasharon, Israel 45241

Tel: [phone]

Mob: [phone]