[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments on draft-kim-ccamp-cpr-reqts-01.txt
hi, to fuel the discussion (and even if the topic is not going to be
discussed during the f2f meeting) here below some comments after a first
reading
1. "Then, GMPLS based IP networks come to be capable of handling control
channels separated from data channels. It means that channels carrying
data and control packets do not have an impact upon each other. Several
control channels such as SONET/SDH DCC channels and Ethernet OAM
channels defined by the OIF, MPLS based LSPs applied as dedicated
control channels, public IP networks, out-of-fiber based dedicated
control channels, and so on can be configured independent from data
channels for the purpose."
indeed, but this has an architectural impact, we are currently dealing
with "converged" networks hence if the control channels do involve the
need for a separated control infrastructure even logically there is a
price to pay - it would be of interest to have such considerations
discussed in this document -
2. "- Standby control channels: Physical control channels which are not
currently carrying the control information, but can carry them upon the
failure of active control channel. Once one of standby control channels
is used to carry the control information, the standby control channel
becomes an active control channel."
what is the purpose of maintaining "standby channels" this aspect should
be further discussed is it to provide some rate shaping to the control
traffic ?
3. "In traditional IP networks or MPLS networks, there is an implicit
one-to-one association of a control channel to a data channel. Under the
one-to-one association between control channels and data channels, the
protection of control channels may be resolved using the protection
schemes for data channels such as 1+1, 1:1, and 1:N protections. In
other words, where there is fate sharing, failures of data channels
could instantly influence the own control channels."
why is there a distinction made with "MPLS networks" i.e. what does
chnage here from having an label based forwarding ?
4. the distinction between the quasi and the non-associated mode is
quite unclear
"- Quasi-associated mode in which control packets between nodes A and B
follow a predetermined routing path over several control channels while
the traffic channels are routed directly between A and B;
- Non-associated mode in which control packets between two network
elements A and B are routed over several control channels, while traffic
signals are routed directly between A and B."
could you explain the difference between these two terms ?
5. "As recognized in the IP world, IP routing protocols have slow
convergence time due to the hello interval and expiration times for the
normal operation of IP networks. Under this situation, fast and reliable
recovery is very difficult from one or more failures occurred over
interfaces between adjacent nodes. "
"slow" is not an absolute indication ... you should point out here
"slow" compare to what ? by the way i am not in agreement with this
statement there are currently ongoing efforts within IETF to allow for
fast IP re-routing (meant to provde "simple" techniques)
6. "When RSVP variant protocols are used between adjacent nodes, if
there is no self-refresh procedure, the failure of control channels may
result effects such as unwanted connection teardown. In particular, as
described in [ITU-G7712], such a failure that could not transport ASTN
messages over the SCN may impact restoration when ASTN is used to
provide restoration of existing connections. It is therefore critical
for a control network to provide the resilience of control channels that
could sufficiently use direct and indirect ones between adjacent nodes."
indeed if you don't use a feature (in present case RSVP resilience to
cnotrol channel failure) you can't benefit from it - the same would
apply with whatever new mechanism you are going to define - hence this
argument is not valid
7. it is totally unclear to me how with the previous section arguments
you come out and require MPLS 1+1 for control plane resilience - that's
probably a very nice and very cumbersome solution but i really doubt
this is satisfying much specific requirements when designing the IP
control plane topology
8. the rest of the document (as section 5.1) is solution specific thus
beyond the scope of the document itself - this is not a document about
LMP requirements for control channel management afaik
note: more detailed comments could follow depending on the progress we
are going to make on this specific topic
thanks,
- dimitri.
-------- Original Message --------
Subject: I-D ACTION:draft-kim-ccamp-cpr-reqts-01.txt
Date: Tue, 25 Oct 2005 10:50:01 -0400
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Requirements for the Resilience of Control Plane
Author(s) : Y. Kim
Filename : draft-kim-ccamp-cpr-reqts-01.txt
Pages : 13
Date : 2005-10-25
The resilience of control plane refers to the ability of control
plane to continue its operation even under failure conditions of
control components such as control entities, control nodes, and
control channels. This document describes requirements for providing
the resilience capability of control plane (in other words, control
network) in non-(G)MPLS and (G)MPLS. This contribution, as a document
that proposes a framework to provide the resilience capability of
control plane, include terminologies, basic concepts of control
networks, possible configurations, necessities and requirements,
additional considerations including the relationship with other
protocol such as LMP for the resilience of control plane.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt
To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-kim-ccamp-cpr-reqts-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-kim-ccamp-cpr-reqts-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.