Subject: [Gen-art] Gen-ART review of draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt

From: Suresh Krishnan <[email-masked]>
Date: Wed, 06 Dec 2006 14:44:04 -0500

I am the assigned Gen-ART reviewer for 
draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt.

For background on Gen-ART, please see the FAQ at 
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

Please resolve these comments along with any other Last Call comments 
you may receive.

Summary: This draft is basically ready for publication, but has nits 
that should be fixed before publication.

Comments:

Substantial:
============

* General comment about backward compatibility

I think legacy transit nodes resetting the Call ID to zero on 
transmission is a major issue that needs to be addressed more visibly in 
the draft.

* Section 6.1

The following sentence needs to be tightened.

The text
"Note that a Call MAY NOT be imposed ..."

needs to be changed to

"Note that a Call MUST NOT be imposed ..."

since it is a prohibition to do so.

Semi-substantial:
=================
* Section 5.1
   I did not understand what this sentence means. Does it mean the 
notify message does not have to follow the path of LSPs or it must not 
follow the path of LSPs? Adding some clarifying text on why it is so, 
may be a good idea.
"The Notify message is a targeted message and does
  not follow the path of LSPs through the network."

* Section 6.5 Call Collision

For the Call ID Contention error case, I do not see why we need to check 
the remote source address, instead of always returning an error.

* Section 6.6.5

"If a teardown request Notify message is received
  for an unknown Call ID, it is, nevertheless, responded to in the
  affirmative."

Why not return a Call Management/Unknown Call ID error instead?

* IANA considerations
   If there are existing implementations it would be nice to suggest 
values for the RSVP objects and error codes to the IANA

Minor:
======

* The following text is repeated in both the abstract and the 
introduction. One of them can be removed.

"A Call does not provide the actual connectivity for transmitting user
  traffic, but only builds a relationship by which subsequent
  Connections may be made. In GMPLS such Connections are known as Label
  Switched Paths (LSPs)."

* Section 4.3.1
   Suggest replacing

"In this case the ingress..."

with

"In the case where the ingress..."

since "this case" has not been defined.

Editorial:
==========
There is a reference to RFC2747 in the references section but it is not 
referenced anywhere in the draft. I would suggest removing the reference

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 7 Dec 2006 12:55:01 -0000

Suresh,

Many thanks for the review:
> I think legacy transit nodes resetting the Call ID to zero on transmission 
> is a major issue that needs to be addressed more visibly in the draft.

Why? It is not common practice to include text that describes how to 
circumvent the effects of broken implementations.

The problem we have here is that we are not writing a BCP for RFC3209 or 
RFC3473. And we do not wish to be judgmental (in this I-D) about existing 
implementations. In fact, I have no evidence that any implementations do 
actually get this wrong (no-one will stand up in public and say "I am a 
fool"), but several people raised the question of "what if an implementation 
did this bad thing".

In my view these people were wreckers and were not interested in the 
protocol being successful, but nevertheless, we added the text you are 
commenting on. Basically, it says what might happen in the legacy case with 
broken nodes. I don't think this should have more prominence.

> since it is a prohibition to do so.

Good catch. Thanks.

> Semi-substantial:
> =================
> * Section 5.1
>   I did not understand what this sentence means. Does it mean the notify 
> message does not have to follow the path of LSPs or it must not follow the 
> path of LSPs? Adding some clarifying text on why it is so, may be a good 
> idea.

Well, read RFC3473 where the Notify message is defined.

It means "does not need to". I will update accordingly.

> the remote source address, instead of always returning an error.

Erm, because then both ends of the call would return an error.
We would end up with no call.
Presumably, both ends of the call would retry and possibly have the same 
effect.

There is no issue with setting up this call: it is just a matter of deciding 
who is in charge. Hence a simple resolution process.

> Why not return a Call Management/Unknown Call ID error instead?

How would the sender of the call tear respond to the error? Does it mean 
that the call still exists, but that the responder can't correlate the call 
ID, or does it mean that the call should be removed from the sender?

What is the desired effect?

As documented:
- Before
   End A believes call exists
   End B has never heard of call
- After
   End A believes call is gone
   End B does not have the call

As you suggest:
- Before
   End A believes call exists
   End B has never heard of call
- After
   End A removes the call through an error state
   End B does not have the call

Simpler to utilise the mainpath code, reduce the number of code branches, 
and not introduce another error message.
The responder (B) is free to raise an alarm if it wants.

> * IANA considerations
>   If there are existing implementations it would be nice to suggest values 
> for the RSVP objects and error codes to the IANA

If the implementors in the WG are happy to have this go forward without 
suggested values, then so am I.
We have enough problems with contested suggested values as it is!

>  Connections may be made. In GMPLS such Connections are known as Label

Why?
The Abstract is stand-alone text and needs to be complete.

The Introduction is typically read without reference to the Abstract.

> since "this case" has not been defined.

Changed to...
   Network-initiated Calls arise when the ingress (and correspondingly
   the egress) lie within the network and there may be no need to
   distribute additional link capability information over and above the
   information distributed by the TE and GMPLS extensions to the IGP.
...in order to preserve the grammer

> Editorial:

Good catch. I have added the citation in section 9.1

Thanks,
Adrian

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 07 Dec 2006 13:30:57 -0500

Hi Adrian,
   Thanks for the quick response. Comments inline.

Cheers
Suresh

Adrian Farrel wrote:
>> transmission is a major issue that needs to be addressed more visibly 
>> in the draft.
> 
> RFC3473. And we do not wish to be judgmental (in this I-D) about 
> existing implementations. In fact, I have no evidence that any 
> implementations do actually get this wrong (no-one will stand up in 
> public and say "I am a fool"), but several people raised the question of 
> "what if an implementation did this bad thing".
> 
> commenting on. Basically, it says what might happen in the legacy case 
> with broken nodes. I don't think this should have more prominence.

If you have good reason to believe all(or even most of) the existing 
implementations are well behaved, I am fine with the text staying as is.

> It means "does not need to". I will update accordingly.

How about this text

" The Notify message is a targeted message and does
   not have to follow the path of LSPs through the network."

>> For the Call ID Contention error case, I do not see why we need to 
>> check the remote source address, instead of always returning an error.
> 
> There is no issue with setting up this call: it is just a matter of 
> deciding who is in charge. Hence a simple resolution process.

OK.

> that the call still exists, but that the responder can't correlate the 
> call ID, or does it mean that the call should be removed from the sender?
> 
> Simpler to utilise the mainpath code, reduce the number of code 
> branches, and not introduce another error message.

I don't think hiding error conditions is a good idea. But since I do not 
feel strongly about this, I am fine with the text staying as is.

> We have enough problems with contested suggested values as it is!

:-). Fine with me.
> The Introduction is typically read without reference to the Abstract.

OK.

> ...in order to preserve the grammer

OK.

> 
>> Editorial:
>> ==========
>> There is a reference to RFC2747 in the references section but it is 
>> not referenced anywhere in the draft. I would suggest removing the 
>> reference
> 

OK.