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

From: "Ong, Lyndon" <[email-masked]>
Date: Fri, 16 Jun 2006 13:03:11 -0400

Hi Adrian,

I appreciate the detailed response, and will look over the points
carefully.

Regarding the issue of ITU-T, however, it confuses me when you say this
draft is not
related to ASON: 
- if you are saying that this is IETF protocol work in support of
ASON-defined requirements then it seems to me that we should pass
this through ITU for their comments to ensure that it is in fact
meeting said requirements
- if you are saying that this is in support of IETF-defined requirements
then perhaps we should not be using the terms "call", "call and
connection
separation" and "ASON" in the draft and using other terms.

As far as community expertise, I can only speak for myself - I have been
attending 
CCAMP and ITU-T Q.14, however I do not typically attend Q.12, which
originally 
created G.8080.   

Cheers,

Lyndon

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Friday, June 16, 2006 6:52 AM
To: Ong, Lyndon; [email-masked]
Subject: Re: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt

Hi Lyndon,

> 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.

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.

> 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.

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.

> 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?

Let me pick through your three examples:

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

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 
> response

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 
> discarded

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

---

From: "Ong, Lyndon" <[email-masked]>
Date: Fri, 16 Jun 2006 15:26:09 -0400

hi Dimitri,

Yes, I recall the plan that Adrian and you presented, of a two
draft approach to the signaling issues.  Is there a schedule
for the second (applicability) draft?

Thanks,

Lyndon 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Friday, June 16, 2006 11:07 AM
To: Ong, Lyndon
Cc: Adrian Farrel; [email-masked]; Brungard, Deborah A, ALABS;
[email-masked]
Subject: RE: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt

lyndon -

- did you read them attentively ? -

if yes, you will see that the first question you asked on the list is
not to be addressed as part of this process but when the protocol
operations are going to be detailed as part of a document that will
describe ASON signaling using GMPLS RSVP-TE (as discussed during IETF 63
& 64)

"Ong, Lyndon" <[email-masked]>
16/06/2006 19:09
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <[email-masked]>, 
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
<[email-masked]>
        Subject:        RE: Working Group Last Call on 
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt

Hi Dimitri,

I appreciate the hints as well, but Adrian has given a more detailed
email response before I had the chance to look up the cross-references
from your email :o)

Sorry about the "a)" and "b)" - forgot to label the dashed items in the
email with letters.

Cheers,

Lyndon 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Thursday, June 15, 2006 10:44 AM
To: Ong, Lyndon
Cc: Adrian Farrel; [email-masked]; Brungard, Deborah A, ALABS;
[email-masked]
Subject: RE: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt

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:
 
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:

 
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: "Mack-Crane, T. Benjamin" <[email-masked]>
Date: Tue, 20 Jun 2006 08:12:51 -0500

Hi Adrian,

I apologize for responding on the last day, but my schedule kept me from
looking at this sooner.

Some responses in-line.

Regards,
Ben

> Sent: Monday, June 19, 2006 9:19 AM
> To: Mack-Crane, T. Benjamin; Brungard, Deborah A, ALABS;
> [email-masked]
draft-ietf-ccamp-gmpls-rsvp-te-
> call-00.txt
> 
> Hi Ben,
> 
> Welcome to the debate.
> 
> > I looked over this draft over the weekend and I have some
> > comments and questions.
> 
> Many thanks.
> Responses in line.
> 
> > 1)       It is hard to understand why a new feature (call control)
> > is being designed as an extension to a notification message.
> > The resulting protocol design obscures the function of the
> > protocol and creates special case processing that may lead
> > to problems.  Is there a reason that new message types were
> > not specified for call request and response?
> 
> Strong words!
> Actually we did discuss defining a new message following the model of
> G.7713.3, but we decided that the scope of the Notify message already
> includes end-to-end communication, negotiation and notification, and
that
> this was consequently within scope of the Notify message.

OK.  I was just commenting, as an outsider, on the relatively confusing
semantics of the result.

> 
> Speaking as an author of this work, it is a little frustrating to have
you
> wait until the last day of the working group last call to comment in
this
> way on a protocol process that has been around the working group for a
> considerable time. In my view (speaking as an author) I don't think
that
> WG
> last call should be used in this way.
> 
> > 2)       Given the stated intent of maintaining strict independence
> > between call and connection control, were other (existing) call
> > control protocols considered (rather than beginning a new call
> > control protocol specification)?
> 
> Yes. Very much so.
> But, the title of the I-D is "Generalized MPLS (GMPLS) RSVP-TE
Signaling
> Extensions in support of Calls" so obviously this draft wouldn't
discuss
> that sort of thing.
> If you have other proposals for handling calls through other
protocols,
> I'm
> sure that you could write an applicability I-D in CCAMP if no
> modifications
> to the protocol are required, or take your proposals for changes to
the WG
> that owns the proposed protocol.
> 
> > 3)       The network models being used in section 4.3 and section 7
are
> > not clear.  In particular the relationships between the call
> > controllers, network boundaries, ingress/egress nodes, and
> > ingress/egress links are not clear.  Figures would be very helpful
here.
> 
> Figures are always helpful, and usually (but not always) better than
> words.
> 
> In order to be sure to clarify the network models that you are finding
> confusing, it would be helpful if you asked specific questions or
proposed
> text.

It is not clear how the form of initiation of a call affects the
information available about the egress link. In part this may be
affected by whether the ingress node is inside or outside the network
(IGP) boundary.  It would seem that the situation at the egress would
have something to do with this as well.  It is unclear where the egress
trail termination point is expected to be, e.g. inside or outside the
network boundary, and, if inside, at the near or far side of the egress
node's matrix.

This may just be me having trouble parsing the text, which is why I
thought a picture would help (e.g. showing the ingress/egress nodes,
location of trail terminations, location of network boundary or
reference points, like UNI or NNI or unsignaled interface, etc.).  I
can't propose text or figures because I am unsure what point is being
made here.

> 
> > 4)       Simultaneous Call and connection establishment can
> > be very handy in the common case of a call with a single
> > connection.  This model should be supported (and in fact
> >  it is in the case of so called "connection setup without a
> > call").
> 
> Two points:
> 
> a. "Connection setup without a call" cannot, by any stretch of the
> imagination, be considered to be "simultaneous call and connection
> establishment". How could it? If there is no call established, the
call
> cannot be established simultaneous to anything.

A call is defined as "an agreement between endpoints" and any connection
entails an agreement to be connected (as a connection request can be
rejected by the egress endpoint).  In the case of "connection setup
without a call" the terms of the agreement are implicit or commonly
understood.  For example, primary and secondary LSPs belong to the same
call, but do not require a separate call setup.  It is not such a
stretch to think that some common cases may benefit from carrying call
request information in the connection request rather than requiring an
additional protocol exchange to do this.  On the other hand, ...(see
below)

> 
> b. Simultaneous Call and Connection setup could have some uses on
single
> hop
> connections where (as you say) there is a single connection per call.
But
> this seemed to be a very limited subset of requirements.
> - What about supporting more than one conneciton per call? This must
> always
> be available within the solution.
> - What about connecitons that span more than one hope? This, too, must
> always be available within the solution.
> Following the oft-quoted (and reasonable) design premise that you do
not
> optimise for special cases, we have built a solution that can handle
all
> of
> the required network configurations yet fits within the defined
> requirements.
> RFC 4158 is pretty clear on the requirements that call and connection
> separation is required, while (if I recall the reference correctly)
G.7713
> says that solutions can choose to use simultaneous call and connection
> setup
> or not. We chose "not" because of the clear architectural benefits.

One could start with the general case, and only optimize later if clear
benefits can be realized.  So I understand your point here.

> 
> >5)       The call control mechanism defined appears to support
> > only IPv4 or IPv6 addressed endpoints from a single address
> > space.  Is this correct?
> 
>  I don't think so. Can you give an example of a network that is
worrying
> you?

Networks don't worry me, but it is useful to support address
independence in operator networks.  I'm not sure where my understanding
went wrong (separate address spaces and/or other than IP addressed
endpoints).  I suppose that's an exercise for the reader.

> Adrian
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 20 Jun 2006 14:21:59 -0400

Hi Lou,

Thanks for the clarification, thought maybe there was
some ulterior motive since it is the only subfield given
that label (as opposed to "Reserved").  

Still think a separate object would be cleaner, though.

Cheers,

Lyndon 

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, June 20, 2006 11:15 AM
To: Ong, Lyndon
Cc: Adrian Farrel; Ong, Lyndon; [email-masked];
[email-masked]

At 01:50 PM 6/20/2006, Ong, Lyndon wrote:
>One concern, though, is
>whether there were strong reasons for originally requiring that the 
>field be set to zero.

Lyndon,
         There is a long standing protocol design approach to set unused
fields to zero.  This is done precisely to enable future use of the
field.  IMO (and if my memory holds) this was so well accepted by the
3209 authors it didn't occur to us to enumerate all the implications of
"MUST be zero".  I think we did a bit better in rfc3473, but the change
was only in response to the brain damage that was seen in 3209
interpretations...

Lou