Subject: RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt

From: "Ong, Lyndon" <[email-masked]>
Date: Thu, 15 Jun 2006 11:52:16 -0400

Hi Deborah,
 
Sorry for the lateness of the comments, but the draft is quite detailed.
Some
of the questions I have are more on the thought behind the procedures
than
the correctness of the procedures.
 
General Comment:
 
Not sure whether this is part of WG Last Call or not, but I certainly
think it would be good
to pass this through ITU Q.12 and Q.14/15 before it is submitted to the
IESG, so that the
definitions and procedures for call can be reviewed for any
inconsistencies.  Hopefully we
will in that way avoid having multiple definitions or defining
procedures that do not fit what
is desired for ASON.
 
I leave it to you and Adrian as to the right way to go about doing this.
 
More Detailed Comments:
 
1. Although the draft does not define a format for the Long Call ID, a
format has been
defined in ITU-T Recommendation G.7713.2, and it might be worth pointing
to this.
 
2. Want to be sure I understand the procedures for the Short Call ID.
Since the field is labeled 
"MUST be zero" in RFC 3209, there could be multiple interpretations:
-- a non-zero value will be received and discarded (zero inserted on
transmission)
-- a non-zero value will be treated as an error and generate an error
response
-- a non-zero value will be treated as an error and the message
discarded
 
It's noted in section 7 that the only way to successfully create
an LSP through a transit node following behavior's (a) or (b) above
would be to upgrade
the LSP - does this mean you could potentially have successful call
setup but failure
of the associated connection setup if the transit LSP behavior is not
correct?
 
3. Are there procedures for when to send a LINK_CAPABILITY object?  It
seems to
be totally optional at both ends.  Is this determined by policy?
 
4. Why is the procedure in section 6.2.1 that the responding side should
assume that the call is successful
if it does not receive an ack to its Notify message?  
 
5. Is refresh of the NOTIFY really necessary if there are active LSPs in
the call?  Possibly the LSP refresh 
could be sufficient, since this carries the short Call ID.  Is it
possible that the call would be dropped while
there are still active LSPs?
 
Cheers,
 
Lyndon

---

From: [email-masked]
Date: Thu, 15 Jun 2006 19:44:04 +0200

lyndon - some hints:

1: not ASON specific; hence such pointer in the applicability doc

2: not sure to understand the question -what is this a) or b) that you're 
referring to - for the first sub-item see section 6.2.2 for the second see 
section 8.2
 
3: during call setup & as described in section 6.7

4: this "a la ResvConf" process is recommended, if the problem persist 
(meaning "empty" call) apply 6.6.5 procedure upon local policy 

5: recommended (and much simple) - note: 6.6.4 ensures no problem can 
arise

-d.

"Ong, Lyndon" <[email-masked]>
Sent by: [email-masked]
15/06/2006 17:52
 
        To:     "Brungard, Deborah A, ALABS" <[email-masked]>, 
<[email-masked]>
        cc:     "Adrian Farrel" <[email-masked]>
        Subject:        RE: Working Group Last Call on 
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt

Hi Deborah,
 
Sorry for the lateness of the comments, but the draft is quite detailed. 
Some
of the questions I have are more on the thought behind the procedures than
the correctness of the procedures.
 
General Comment:
 
will in that way avoid having multiple definitions or defining procedures 
that do not fit what
is desired for ASON.

More Detailed Comments:

-- a non-zero value will be treated as an error and the message discarded
 
It's noted in section 7 that the only way to successfully create
an LSP through a transit node following behavior's (a) or (b) above would 
be to upgrade
the LSP - does this mean you could potentially have successful call setup 
but failure
of the associated connection setup if the transit LSP behavior is not 
correct?

 
5. Is refresh of the NOTIFY really necessary if there are active LSPs in 
the call?  Possibly the LSP refresh 
could be sufficient, since this carries the short Call ID.  Is it possible 
that the call would be dropped while
there are still active LSPs?
 
Cheers,
 
Lyndon

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 16 Jun 2006 14:51:33 +0100

Hi Lyndon,

> think it would be good to pass this through ITU Q.12 and Q.14/15
> before it is submitted to the IESG, so that the definitions and
> procedures for call can be reviewed for any inconsistencies.
> Hopefully we will in that way avoid having multiple definitions
> or defining procedures that do not fit what is desired for ASON.

How shall I put this, Lyndon?

CCAMP always welcomes input from members of the ITU-T community on the
content of our Internet-Drafts in any stage of the process up until the end
of working group last call. Since there are many members of that community
subscribed to the CCAMP list, and since (we assume) they are all familiar
with the ASON terminology and requirements, we can reasonably assume that
there are no outstanding issues that would require us to consult more
formally on this draft which is not related to ASON.

> format has been defined in ITU-T Recommendation G.7713.2, and it
> might be worth pointing to this.

As I understand the scope of G.7713.2, it specifies protocol extensions,
procedures and applicability for the use of GMPLS extensions to RSVP-TE at
the ASON UNI and E-NNI if those reference points are exposed as external
protocol interfaces. It seems clear to me that this I-D should not preclude
the use of the definition of a long call ID in this context, but I don't see
that it is particularly the place of this I-D to reference various different
encodings for call IDs in different contexts. This type of work is the job
of applicability statements that seek to apply particular protocols to
particular applications.

> would be to upgrade the LSP - does this mean you could potentially
> have successful call setup but failure of the associated connection
> setup if the transit LSP behavior is not correct?

> -- a non-zero value will be received and discarded (zero inserted on

In the opinions of the authors, such behavior would represent a defective
implementation since transit LSRs should not update fields of received
messages before transmitting them except where specifically described by the
procedures of the RFCs.

However, we recognise that defective implementations may exist, and need to
design the way that they are handled to be as graceful as possible. This is
covered in section 8.2.

> -- a non-zero value will be treated as an error and generate an error

This would represent a significant error in the implementation. There is no
text that describes this being correct behavior, and it would demonstrate a
lack of understanding of the principles of extensibility in RSVP.

Again, the graceful handling of this process is covered in section 8.2.

> -- a non-zero value will be treated as an error and the message

This would represent a very poor implementation, indeed. Graceful handling
of such broken implementations is only possible with the cooperation of
other network nodes and the notes in section 8.2.

You ask whether, in the presence of defective implementations as described
above it might...
> mean you could potentially have successful call setup
> but failure of the associated connection
> setup if the transit LSP behavior is not correct?

The answer is yes, of course.

The same is true for any call and connection separation.

Let us consider G.7713.3 (note that I would explain this using G.7713.2, but
that specification does not support call and connection separation). The
call is set up using a dedicated message between call controllers. Once this
has been done, the connections are set up as required. But suppose that
there is a simple problem of lack of bandwidth or lack of connectivity? The
call has been set up, but the connection fails.

Now suppose that there is a transit node that is a little blue today. It
receives the connection request and decides to turn it into a paper cut-out
model of the Eiffel Tower. The connection fails to set up as a result. Does
that mean that G.7713.3 is broken, or does it mean that there is bad, bad,
bad, node in the network?

> 3. Are there procedures for when to send a LINK_CAPABILITY object?
> It seems to be totally optional at both ends.  Is this determined by
> policy?

Either I don't understand your question or you haven't read sections 4.3,
6.2 and 6.7. Could you re-phrase and/or re-read?

> 4. Why is the procedure in section 6.2.1 that the responding side
> should assume that the call is successful if it does not receive an
> ack to its Notify message?

The intention is to cover all DCN failures in section 7. A very good
question to pose is whether a DCN failure between call end points should
cause the call (and associated connections) to be torn down. It is generally
accepted that, in a transport network, traffic should be king (within policy
control available to the operator).

So in this specific case there are two possible scenarios:
- The Ack did not reach the call responder, because the call response
   did not reach the call initiator.
  In this case, the call initiator will take actions commensurate with
  the call setup failing. It may tear the call, which would be helpful.
  If it doesn't tear the call, the call responder will observe that the
  call is not in use and that the communications with the call initiator
  have failed and will follow policy wrt the call.
- The Ack did not reach the call responder, because the Ack was
  lost.
  In this case, use of the call will be just fine.

Note that the delivery path for the call messages is very different from
that used for the connection messages.

> 5. Is refresh of the NOTIFY really necessary if there are active
> LSPs in the call?  Possibly the LSP refresh could be sufficient,
> since this carries the short Call ID.  Is it possible that the call
> would be dropped while there are still active LSPs?

The process is recommended not mandated. The reasons why the process is a
good idea are stated in section 6.7.

The fact that different timer values are appropriate when there are and are
not connections in use is described. But note that connection refresh is
hop-by-hop between connection controllers, while call refresh is between
call controllers.

Architecturally, it would be pretty odd to request the connection
controllers to provide information to the call controllers on the survival
of the call.

From a protocol point of view, it would be unfortunate to determine the
state of a call because of the state of communications between the 
connection
egress and the connection control immediately upstream.

Recall, we are talking about establishing connections across arbitrary
networks, not just across links.

Hope this helps.

Adrian