[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on LMP draft version 04
hi,
my 2 cents on this, most of the questions you have raise
from the terminology glue with respect to sdh/oth related
specs
other people may have the same questions the day LMP would
be applied to GbE networks for instance
therefore i propose we have a terminology document (what
has been called a decoder ring) when applying LMP to SDH
and OTH networks, this has shown to help the (non familiar)
reader when looking at documents such as the one you mention
here above
at this point we will be sure that the points on which
people may disagree are really related to the proposed
methods and not as Platon described due to the mirror
reflect of what people think people are. But always
remember that the scope of LMP is not to replace (when
applied to sdh/oth) existing features already available
in these technologies but just to provide the needed
mechanisms in order to enable the gmpls control plane
to have the "usable" information for subsequent gmpls
operations.
thanks,
- dimitri.
Michiel van Everdingen wrote:
>
> Hello Yakov,
>
> > 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.
>
> This is still not clear to me. Do you see a problem in
> http://www.ietf.org/internet-drafts/draft-everdingen-ccamp-lmp-update-00 ?
>
> It seems we have had a terminology problem on the term "link".
> According to ITU-G.852.2, a link is a set of linkConnections (=dataLinks).
>
> Each of these dataLinks has a termination point on both sides
> of the dataLink. These termination points can either be a 'CTP' or
> a 'TTP'.
>
> A special case of 'link' is the 'TE-link' which is the set of
> linkConnections that can be considered equivalent for GMPLS routing
> purposes.
>
> > 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.
>
> What is in-band ?
> The dataLinks have an in-band access point identifier. DCC connections
> are to be considered out-of-band.
>
> > If by "DCN" you mean the network used to by the control plane
>
> Yes.
>
> > then
> > please note that the test message itself is transmitted over the data
> > plane, not over the control plane.
>
> There is no IP based "data plane" through which you can send "test messages".
> We'll have to use the access point identifier.
>
> Best regards,
>
> Michiel
>
> Yakov Rekhter wrote:
> >
> > 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.
>
> --
> +------------------------------------------------------------------+
> | Michiel van Everdingen |
> | Systems Engineer |
> | Lucent Technologies - Optical Networking Group |
> | Larenseweg 50 Phone : +31 35 687 4883 |
> | P.O. Box 1168, 1200 BD Fax : +31 35 687 5976 |
> | Hilversum, The Netherlands mailto:MvanEverdingen@lucent.com |
> +------------------------------------------------------------------+
--
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
Website: http://www.rc.bel.alcatel.be/~papadimd/index.html
Address: Alcatel - Optical NA, Fr. Wellesplein, 1
B-2018 Antwerpen, Belgium
Phone: Work: +32 3 2408491 - Home: +32 2 3434361