Hi Adrian,
Thanks for the quick response. Comments inline.
Cheers
Suresh
Adrian Farrel wrote:
Suresh,
Many thanks for the review:
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.
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.
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.
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."
Well, read RFC3473 where the Notify message is defined.
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."
* 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.
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.
OK.
* 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?
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.
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.
* 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!
:-). Fine with me.
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)."
Why?
The Abstract is stand-alone text and needs to be complete.
The Introduction is typically read without reference to the Abstract.
OK.
* 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.
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
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
Good catch. I have added the citation in section 9.1
OK.
Thanks,
Adrian
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf