Subject: [mpls] Questions on draft-umansky-mpls-tp-ring-protection-switching-02

From: Zhi-Wei Lin <[email-masked]>
Date: Tue, 23 Mar 2010 11:47:24 -0400

Hi,

I have the following questions on this draft:

   - General: how are the messages sent? Are they sent on the working or
   protect link, or both? Are they sent into the failed link also, or just away
   from the failed link?
   - 5.2: the list of APS request code assignments are different from the
   linear-protection document. Can these two lists be aligned? They share many
   common commands. Also, the "Clear" command in linear protection should also
   be needed here?
   - 5.3.4.1: how does a node know the request is not destined for itself?
   In the destination node ID portion, document states that the destination is
   the adjacent node? Do you mean "adjacent node" is the node on the other side
   of the failure (or the adjacent node opposite to the failure)? How do you
   know the failure is not the adjacent node itself (in which case the message
   would never be responded to?)

Thanks
Zhi

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 23 Mar 2010 18:00:17 +0100

Hello Zhi,

You wrote:

>     * General: how are the messages sent? Are they sent on the working
>       or protect link, or both? Are they sent into the failed link also,
>       or just away from the failed link?

== APS messages are sent on the protection links only, sending
    them on both will add unnecessary complexity.
== APS messages are always send clockwise and counter-clockwise
    in the ring the APS process logic correlates all inputs to
    generate the proper response

>     * 5.2: the list of APS request code assignments are different from
>       the linear-protection document. Can these two lists be aligned?
>       They share many common commands. Also, the "Clear" command in
>       linear protection should also be needed here?

== we are aligned with the request codes defined in ITU-T ring
    protection recommendations. We see no need to change that.
== the Clear command should NOT be sent to other ring nodes, it
    is a *local* NMS command and input for the *local* state machine.
    Sending it to other nodes will create a deadlock situation.

>     * 5.3.4.1: how does a node know the request is not
>       destined for itself?

== the APS mesaage contains a destination address, each ring node
    has a ring-map that contains the address of each node.
    The APS process uses these to determine how to process
    the received request.

>       In the destination node ID portion, document
>       states that the destination is the adjacent node?

== indeed, APS messages are exchanged between adjacent nodes
    in the ring, if there are no requests the destination ID is
    that of the adjacent node.

>       Do you mean
>       "adjacent node" is the node on the other side of the failure (or
>       the adjacent node opposite to the failure)? 

== in case of a failure the destination ID is the node at the
    other side of the detected failure, this is determined by
    the APS process by looking at the ring map

>       How do you know the
>       failure is not the adjacent node itself (in which case the message

== in every node the APS correlates the APS messages received
    from both adjacent nodes and determines whether it should
    perform a local protection switch, or pass through the APS
    information (in both directions.
    This ensures that the protection works in case of e single
    link failure, a node failure (in fact two adjacent link
    afilures) and even in case of non-adjacent link failres that
    will segment the ring, but can still provide protection in
    each segment.

Cheers, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...

---

From: Zhi-Wei Lin <[email-masked]>
Date: Tue, 23 Mar 2010 13:18:06 -0400

Hi Huub,

   - If Clear command is not needed, then should it also be removed from the
   linear-protection document?
   - In the case of node failure, I think your description is not consistent
   with the text? Section 5.3.4.2 only describes transition from idle to
   switching when the destination node is itself. Do you need to add more text
   that if the node detects the destination node is an adjacent node that
   cannot be reached, it would also transition to switching?

Thanks
Zhi

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 23 Mar 2010 18:43:44 +0100

Hello Zhi,

You replied:

>     * If Clear command is not needed, then should it also be removed
>       from the linear-protection document?

Yes, it should.

>     * In the case of node failure, I think your description is not
>       consistent with the text? Section 5.3.4.2 only describes
>       transition from idle to switching when the destination node is
>       itself. Do you need to add more text that if the node detects the
>       destination node is an adjacent node that cannot be reached, it
>       would also transition to switching?

We describe the node failure in section 3.1.2.2. apparently it needs
more words to explain the operation of the APS process in the adjacent
nodes.

> Thanks

Thank you for your comments.

Cheers, Huub.

===
> On Tue, Mar 23, 2010 at 1:00 PM, Huub van Helvoort <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hello Zhi,
> 
> 
>     You wrote:
> 
>            * 5.3.4.1 <http://5.3.4.1>: how does a node know the request
>         is not
>              destined for itself?
> 
> 

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...