Re: LMP & neighbor discovery (verify_id)

[Michiel van Everdingen <MvanEverdingen@lucent.com>]

Hello Jonathan,

It seems that the whole control channel concept is *only* useful for this
new description to "discover the connectivity of the data ports". By means
of the control channel, the node knows where to send the beginVerify message
to.

Please let me know if the control channel is needed for other things as
well.

The described approach for neighbor discovery seems quite manual to me.
- The operator needs to manually "associate control channels with
  interfaces" (see http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00609.html)
- The operator needs to manually provision control channels over the control
  network between node pairs.

In case above tasks can be done automatically, please let me know how.

To my opinion, things get much simpler if we would
- remove the concept of "control channel" and accept that signalling
  messages are carried over the "control network".
- include a section on neighbor discovery; see the proposal in
  http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00750.html
- keep initial discovery and subsequent verification separate.


Best regards,

Michiel


Jonathan Lang wrote:
> 
> Yanguang,
> 
> To clarify things, we've added a few lines of text to the example of Section
> 5.1 explaining how VerifyId is bound to the remote node.
> 
> Thanks,
> Jonathan
> 
> 5.1. Example of Link Connectivity Verification
> 
>    Figure 1 shows an example of the link verification scenario that is
>    executed when a link between Node A and Node B is added. In this
>    example, the TE link consists of three free ports (each transmitted
>    along a separate fiber) and is associated with a bi-directional
>    control channel (indicated by a "c"). The verification process is as
>    follows:
>    o  A sends a BeginVerify message over the control channel to B
>       indicating it will begin verifying the ports that form the TE link.
>       The LOCAL_LINK_ID object carried in the BeginVerify message
>       carries the identifier (IP address or interface index) that A
>       assigns to the link.
>    o  Upon receipt of the BeginVerify message, B creates a VerifyId and
>       binds it to the TE Link from A. This binding is used later when B
>       receives the Test messages from A, and these messages carry the
>       VerifyId. B discovers the identifier (IP address or interface index)
>       that A assigns to the TE link by examining the LOCAL_LINK_ID object
>       carried in the received BeginVerify message. (If the data ports are
>       not yet assigned to the TE Link, the binding is limited to the Node Id
>       of A.) In response to the BeginVerify message, B sends to A the
>       BeginVerifyAck message. The LOCAL_LINK_ID object carried in the
>       BeginVerifyAck message is used to carry the identifier (IP address or
>       interface index) that B assigns to the TE link. The REMOTE_LINK_ID
> object
>       carried in the BeginVerifyAck message is used to bind the TE link Ids
>       assigned by both A and B. The VerifyId is returned to A in the
>       BeginVerifyAck message over the control channel.
>    o  When A receives the BeginVerifyAck message, it begins transmitting
>       periodic Test messages over the first port (Interface Id=1). The Test
>       message includes the Interface Id for the port and the VerifyId that
> was
>       assigned by B.
>    o  When B receives the Test messages, it maps the received Interface Id
>       to its own local Interface Id = 10 and transmits a TestStatusSuccess
>       message over the control channel back to PXC A.  The TestStatusSuccess
>       message includes both the local and received Interface Ids for the
> port
>       as well as the VerifyId. The VerifyId is used to determine the
> local/remote
>       TE link identifiers (IP addresses or interface indices) for which the
> data
>       links belong.
>    o  A will send a TestStatusAck message over the control channel back to
>       B indicating it received the TestStatusSuccess message.
>    o  The process is repeated until all of the ports are verified.
>    o  At this point, A will send an EndVerify message over the control
>       channel to B to indicate that testing is complete.
>    o  B will respond by sending an EndVerifyAck message over the control
>       channel back to A.
>    Note that this procedure can be used to "discover" the connectivity of
> the data
>    ports.
> 
> <...snip...>


-- 
+------------------------------------------------------------------+
| Michiel van Everdingen                                           |
| Systems Engineer                                                 |
| Lucent Technologies - Optical Networking Group                   |
| Botterstraat 45, 1271 XL       Phone : +31 35 687 4883           |
| P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976           |
| Huizen, The Netherlands        mailto:MvanEverdingen@lucent.com  |
+------------------------------------------------------------------+