Re: Comments on LMP draft version 04

[Yakov Rekhter <yakov@juniper.net>]

Michiel,
  
> We are very disappointed that you have not provided the
> clarifications as requested in
> - http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00735.html
> - http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html
> nor the method of neighbor discovery as proposed in
> - http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00750.html
> 
> Please find below comments on the LMP draft, version 04
> (http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-04.txt).
> Hopefully clarification can be provided in a next
> version.
> 
> Best regards,
> 
> Greg Bernstein (Ciena Corporation)
> Michiel van Everdingen (Lucent Technologies)
> 
> 
> General: please clarify what a control channel is. Only when that
> is clarified, we can comment on the mandatory need to manage this
> control channel (section 3). If a control channel can be many
> things, please mention these things so we can comment on these
> interpretations one by one.

It is a pair of IP interfaces that are mutually reachable.
Note that "mutually reachable" doesn't imply that these two
interfaces are (directly) connected by an IP link; there may
be an IP network between the two.

> 
> Some first comments assuming an interpretation that was recently
> provided on this list:
> 
> A. "control channel on top of a control network"
>    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00725.html
>    - From section 1: "To enable communication between nodes for
>      routing, signaling, and link management, control channels must
>      be established between the node pair".
>      Please clarify why control channels must be established. The
>      control network seems enough to enable communication.

It should be abundantly clear to an informed reader that while the
existence of the control network is necessary for enabling
communication, it is by no means sufficient.

To elaborate a bit for uninformed readers, if the two interfaces
are separated by an IP network, faults in the IP network may result
in the lack of (IP) path from one interface to another, and therefore
in the lack of the ability to communicate between the two interfaces.
Note however, that not every failure in the control network affects
a given control channel, hence the need for establishing and managing
control channels.

>    - From section 2: "...the control channel MUST terminate on
>      the same two nodes that the TE link spans"
>      What information is terminated at the end of a control channel ?
>      ('electrically terminated' as mentioned in the 4th paragraph of
>       section 3 does not provide much information).
>      Compare e.g. LSP termination (in which an MPLS label is
>      terminated/removed), TCP termination (in which the TCP header is
>      terminated/removed) and STS-1 termination (in which STS-1 line
>      overhead is terminated/removed). What is terminated/removed at
>      the end of a control channel ?

The GMPLS information (e.g., LMP) carried over the control channel.
  
> B. "a control network is one instantiation of a control channel"
>    http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00835.html
>    How to read sentences (taken from draft-ietf-ccamp-lmp-04.txt)
>    like:
>    - "Control channel management is used to establish and maintain
>       control channels between adjacent nodes."

Read as follows:

  "Control channel management is used between a pair of nodes
   that are connected by at least one TE link to establish and 
   maintain a pair of IP interfaces that are mutually reachable." 

>    - "LMP requires that a pair of nodes have at least one active bi-
>       directional control channel between them."

Read as follows:

  "LMP requires that a pair of nodes have at least one active (bi-directional)
  (a) pair of IP interfaces that are mutually reachable between them."

>    - "the control channel MUST terminate on the same two nodes that
>       the TE link spans"

Read as follows:

  "the pair of IP interfaces that are mutually reachable MUST belong to the
   same pair of nodes that the TE link belongs to."

>    when a control network is used to instantiate the "control
>    channel" (i.e. try to replace "control channel" with "control
>    network" in the indicated sentences) ?
> 
> 
> LMP version 4 now includes some neighbor discovery (3rd paragraph
> section 3 and start of section 5). A separate draft is provided
> to specify discovery in the case of "out-of-band control channels"
>   http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt

Section 3 is describing the in fiber, in band case detailed in OIF
UNI 1.0.  Section 5 is describing data bearing link discovery.  The new
draft is describing out of band control channel discovery.

> Why separating the "in-band" and the "out-of-band" cases in different
> drafts, especially if a method exists that does not make any assumption
> on the configuration of the control network ?
>   http://www.ietf.org/internet-drafts/draft-everdingen-ccamp-lmp-update-00

An imponderable. The out of band control channel discovery work was
initially done by George Swallow as part of the OIF UNI 1.0 work, but was
shelved because, I think, it was considered too advanced.

> Section 1, 4th paragraph: "a data-bearing link may be either a
> 'port' or a 'component link' depending on its multiplexing capability".
> The multiplexing capabilities are present at the *end-points* of the
> data-bearing link. The data-bearing link itself does not have
> multiplexing capabilities. See
>   http://www.ietf.org/internet-drafts/draft-everdingen-ccamp-lmp-update-00
> on how to use alternative terminology (TTP & CTP).

We'll modify the sentence as follows:

   "a data-bearing link may be considered by each node that it 
    terminates on as either a 'port' or a 'component link' depending 
    on the multiplexing capability of the endpoint on that link"

> Section 1, 4th paragraph: the "timeslot label" that is needed to
> identify a "link resource" is not mentioned anymore in the remainder
> of the document.

That is correct.

> Section 3.2: what IGP is meant here ? The IGP building the topology
> of the "control plane" or the "signaling plane" ? See for definitions
> of these terms:
>   http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00725.html

The IGP that is used by the GMPLS control plane. To avoid
any further confusion we should probably replace "IGP" with
"OSPF-TE/ISIS-TE".
  
> Section 14.8: In case the test message is transmitted over the DCC
> "with bit-oriented HDLC framing format", is this by-passing the
> DCN ? Please spend more words on how to prevent conflicts (e.g.
> using a proprietary PPP protocol id to prevent the test message
> to be handled by the normal routing mechanisms of DCN ?)

If by "DCN" you mean the network used to by the control plane, then
please note that the test message itself is transmitted over the data 
plane, not over the control plane. The Test message would never be sent 
through the DCN network.

Yakov.