[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mpls
Subject:    Re: [mpls] [mpls-tp] Questions
From:       Huub van Helvoort <hhelvoort () chello ! nl>
Date:       2010-03-23 17:00:17
Message-ID: 4BA8F3A1.2040905 () chello ! nl
[Download RAW message or body]

Hello Zhi,

You wrote:

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

== 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
>       would never be responded to?)

== 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...
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
[prev in list] [next in list] [prev in thread] [next in thread]