Incoming liaison (1) from ITU-T SG15

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

Here is the text of an incoming liaison just received.
In due course it will be posted at the IETF's liaison web site. Until then
you can see the original at http://www.olddog.co.uk/incoming.htm

Cheers,
Adrian

============
From: ITU-T SG15
To: CCAMP
For: Action
Deadline: 15 March 2005
Subject: Crankback in GMPLS Systems

Q14 wishes to thank CCAMP for information regarding the crankback
signalling capability.  <draft-ietf-ccamp-crankback-03.txt> was discussed
and is helpful to Q14 in the development of crankback requirements.  As
requested, we have the following comments on the I-D for your
consideration of the next version of the draft:

1.       Semantics of the term "node".  Due to the GMPLS principle of
maintaining separation of control and transport (data/bearer) planes,
there are two meanings for the term "node".  First, an instance of a
signalling protocol (and/or routing protocol) that has some transport
resources in its scope.  Second, a transport plane resource such as a
cross connect.  Using the first meaning, a node is not the context for the
interface identifiers that are passed in crankback TLVs.  Throughout the
document the particular meaning can be determined by the context of the
term.  Examples are:

- Section 5.2, the sentence "Otherwise, multiple nodes might attempt to
repair the LSP." means the control functions of signalling and routing.

- Section 7.1 "As described above, full crankback information SHOULD
indicate the node, link and other resources, which have been attempted."
refers to the transport resource.

There are some occasions where the use of the term appear to be ambiguous
and clarity would be appreciated.  In particular TLV types 10 and 32.  If
type 10 represents a routing and signalling function, then what TLV
describes the "transport plane node" (e.g., cross connect or Network
Element)?  If type 32 means "transport plane nodes", then a different TLV
may be needed to identify the "routing/signalling nodes" that have already
participated in crankback attempts.
Having a clearer distinction between control plane functions and transport
plane resources would be helpful.

2.       When crankback information is received at a "routing/signalling
node", can it be used by the routing path computation function for other
LSP requests than the LSP whose signalling caused the crankback action?

3.       Section 6.1 "Segment-based Re-routing" option.  It is not clear
what this means.  Can multiple "routing/signalling nodes" perform
crankback on the same LSP at the same time if this flag is set?

4.       Section 4.3 History persistence.  If a repair point (a
"routing/signalling node") is unsuccessful in a crankback attempt, is it
possible for it to be not involved when another repair point (e.g., closer
to the source) succeeds in a crankback attempt.  If so, how does the first
repair point know to clear its history?

5.       Section 4.5 Retries.  Some guidance on setting the number of
retries may be helpful as this is a distributed parameter.  Is it set to
be the same value at all points that can perform crankback within one
network?

An electronic copy of this liaison and the attachments can be found at
<ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICAT
IONS/index.html >