Re: [mpls] [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-linear-protection-04

Jie, hi

Thank you for your very detailed comments, see replies in-line

BR,
yaacov

>> -----Original Message-----
>> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On
>> Behalf Of ext Jie Dong
>> Sent: Friday, February 11, 2011 10:44 AM
>> To: mpls-tp@ietf.org; mpls@ietf.org
>> Subject: Re: [mpls-tp] mpls wg last callon draft-ietf-mpls-tp-linear-
>> protection-04
>> 
>> Dear authors,
>> 
>> Here are some comments on linear protection draft.
>> 
>> 1. In section 1.2, it says:
>> " The basic protocol is designed for use in conjunction with the 1:1
>> protection architecture (for both unidirectional and bidirectional
>> protection) and for 1+1 protection of a bidirectional path (for both
>> unidirectional and bidirectional protection switching). "
>> 
>> Would you please explain why coordination is needed for
unidirectional
>> protection switching in 1+1 protection of a bidirectional path?
>> Because
>> section 4.7.2 of tp-survive-fwk says:
>> "In 1+1 unidirectional protection switching there is no need to
>> coordinate
>> the protection state between the protection controllers at both ends
>> of the
>> protection domain."

yw> Yes, you are correct that there is no need for coordination for
unidirectional protection however this protocol could be used by the
endpoints to coordinate information regarding the state of the network. 
>> 
>> I guess you mean 1+1 protection may need coordination to keep traffic
>> on
>> co-routed paths, but that would be bidirectional protection
switching.
>> Hope this could be made clearer in this draft.

yw> we will try to clarify this better in the next version.
>> 
>> 2. Section 2.1, Acronyms
>> The full name of "LER" should be "Label Edge Router"
>> "PST" is an old term replaced by SPME (Sub-Path Maintenance Entity),
>> but
>> neither is used in the following sections, so it may be removed from
>> acronyms.

Yw>  You are correct and this will be corrected as suggested.
>> 
>> 3. In Section 3, there is only one level-2 subsection (3.1), so what
>> about
>> promote the level-3 subtitles (3.1.1, 3.1.2, ...) to level-2, and
>> level-4
>> (3.1.6.1) to level-3?

yw> Thank you for pointing this out!
>> 
>> 4. Section 4, 3rd paragraph, s/single-phase/single-phased, to be
>> consistent
>> with 2nd paragraph.

yw> Thank you
>> 
>> 5. Section 4.1, 4th paragraph,
>> " In the event a signal fail condition is detected on the protection
>> path,
>> the received PSC specific information should be evaluated."
>> The statement is vague. What would be the state and action when a
>> signal
>> fail is detected on the protection path? Would you please elaborate
on
>> this
>> point?

yw> will try to clarify in the next version.
>> 
>> 6. Section 4.2.2, 4th paragraph,
>> " The Fpath field SHALL identify the path that is reporting the
>> failure
>> condition (i.e. if protection path then Fpath is set to 0...".
>> Since PSC message are only transmitted on protection path, if
>> protection
>> path has signal fail, the PSC message may not be able to be sent out
>> to
>> far-end.

yw>  Actually, if there is a signal failure on the protection path,
there is a possibility that the messages may not be received by the
far-end, however, it is advisable that the source end-point continue to
transmit these messages.
>> 
>> 7. Section 4.3.2, there is signal degrade on working path as input,
>> but no
>> signal degrade on protection path.

yw> Currently, the signal degrade input in this list is a place holder -
the issue of how to deal with SD in general is for further study as
stated in section 4.2.2.  Note - there have been lengthy discussions at
several IETF meetings on how to deal with SD without any conclusions.

>> 
>> 8. Section 4.3.3, I go through this part fast, a general question is:
>> are
>> the PSC operations for 4 different protection types identical ? In
>> this
>> section there is no description about operation of each specific
>> protection
>> type, but to my understanding, there may be different operations,
>> e.g., for
>> bidirectional 1:1 protection, the end point may need to switch the
>> sink
>> selector and transmitting bridge simultaneously according to some
>> input, but
>> for unidirectional 1:1 the end point may only need to switch the
>> transmitting bridge OR the sink selector. And the PSC message sent
may
>> also
>> be different for different protection types. (Please correct me if
>> there is
>> anything wrong with this thought).

yw> Can you clarify for which scenario you believe that the messages
generated should be different dependent upon the protection type (aside
from the value of the protection type field)?  The exact actions of the
selector and transmitting bridges are not fully described in the
document aside from the note at the end of section 4.3.1.  In addition,
in the introductory text of each state description in section 4.3.3.3.x
describe how the user data is being transmitted.  Is there a feeling
that we need to describe this separately for each scenario?
>> 
>> 
>> Best Regards,
>> Jie
>> 
>> > -----Original Message-----
>> > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On
>> > Behalf Of Loa Andersson
>> > Sent: Thursday, February 03, 2011 7:42 PM
>> > To: mpls-tp@ietf.org; mpls@ietf.org
>> > Cc: ahmpls-tp@lists.itu.int
>> > Subject: [mpls-tp] mpls wg last call on
>> draft-ietf-mpls-tp-linear-protection-04
>> >
>> > Working Group,
>> >
>> > this is to start a four week working group last call on
>> > "MPLS-TP Linear Protection" (draft-ietf-mpls-tp-linear-protection-
>> 04).
>> >
>> > Please send comments to the mpls-tp@ietf.org mailing list.
>> >
>> > This working group last call ends on February 28, 2011.
>> >
>> >
>> >
>> > Loa, George and Ross
>> >
>> > MPLS wg co-chairs
>> >
>> >
>> >
>> > --
>> >
>> >
>> > Loa Andersson                         email:
>> > loa.andersson@ericsson.com
>> > Sr Strategy and Standards Manager            loa@pi.nu
>> > Ericsson Inc                          phone: +46 10 717 52 13
>> >                                               +46 767 72 92 13
>> > _______________________________________________
>> > mpls-tp mailing list
>> > mpls-tp@ietf.org
>> > https://www.ietf.org/mailman/listinfo/mpls-tp
>> 
>> 
>> 
>> _______________________________________________
>> mpls-tp mailing list
>> mpls-tp@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls-tp