[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Thanks Adrian.
We've allowed additional discussion on your response summary to continue
for some time, can you now please summarize if any changes have been
identified?
I noted your email on the MPLS list, I have not seen any issues
identified with the interpretation used by this document.
I did not identify any technical issues. I've run both the idnit check
and my personal American-English check tool (famous among my draft
co-authors), and found a couple of grammer nits/typos.
(1) Nit check gave one warning on a missing reference - a typo in
section 6.6.1: RFC3743 should be RFC3473.
(2) My check tool gave the following:
- inconsistent use of "Connection" and "connection" e.g. 5.2 uses the
small cap. I don't have a preference which is used.
- identified multiple instances where the addition of a comma would be
helpful (I'll send a marked up copy to you for consideration against
British use).
- 3.1, 6.2, 6.2.1, 6.5, 6.6, 8.1, 10.2 need to have a ":" before their
lists
- 3.3, 1st sentence: Segments capabilities --> Segment capabilities
- 5.4.1 ATTIBUTE --> ATTRIBUTE
- 5.5 "in favor of [RFC3471]" --> "and [RFC3471]"
- 6.1 "or if a further" --> "or if another"
- 6.2 "value is assigning" --> "value in assigning"
- 6.6.3 "for at least the five times" --> "for at least five times"
- 6.7 "link failures, and" "link failures, or"
- 6.7 "If an LSR" --> "If a node"
- 7.1 "domains do not share this sort of information." --> "domains do
not usually share this type of information."
- 9.1 "that the process of call establishment independent of LSP setup
may be used ..setup" --> "that as the process of call establishment is
independent of LSP setup, this may be used to apply an extra level of
authentication and policy compared to a hop-by-hop LSP setup"
- 9.1 "Insect" --> "IPsec"
- 11 "input to and" --> "input and"
- 12.1 "GMPLS-FUNCT" --> "RFC4426"
Thanks,
Deborah
-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Wednesday, July 12, 2006 3:54 PM
To: Brungard, Deborah A, ALABS
Cc: ccamp@ops.ietf.org
Subject: Re: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Hi,
> The Working Group Last Call has closed on this document.
>
> Authors/editors please summarize the comments and document
> how they will be addressed.
Thanks Deborah, it's interesting to be on the receiving side for a
change
:-)
I noted the following comments during WG last call.
1. Desirability of liaison to ITU-T SG15 (Lyndon)
Lyndon suggested that this I-D should be liaised to SG15 prior to
becoming
an RFC to ensure that terminology is correct and that it meets the
requirments for supporting ASON calls.
Our response here is that:
a. This I-D is not specifically targeted at satisfying RFC4139.
b. An applicability statement will be produced describing how this and
other I-Ds/RFCs can be used to meet the requirements set out in
RFC4139. That work will definitely be liaised to the ITU-T.
c. The terms used in this document are not specific to ASON, but
in general they have been taken from RFC4139 and RFC4397
both of which received substantial and useful review by SG15.
No further action is planned by the authors.
2. Format of Long Call ID (Lyndon)
Lyndon points out that a format for the long call ID has been defined in
G.7713.2 and suggests that this might be included by reference.
The authors note that the format of an ASON call ID is defined in
several
places (including G.7713.1 and G.7713.2), but the intention of the draft
is
not to be limited to ASON applicability. Therefore other call ID formats
would also be supported, and the format is out of scope for the draft.
An applicability statement will be produced describing how this and
other
I-Ds/RFCs can be used to meet the requirements set out in RFC4139, and
that
will definitely include the encoding of ASON call IDs. That work will be
liaised to the ITU-T.
No further action is planned by the authors.
3. Location of Short Call ID in Path message (Lyndon and Ben)
Both Lyndon and Ben questioned the location of the short call ID in the
Session object.
a. Impact of existing, non-conformant implementations
The draft currently describes the behavior if non-conformant transit
LSRs react to the use of the previously reserved bits of the Session
object. They might reject the Path message, or they might zero out
the short call ID.
Lyndon asked whether it might be better to use a separate object
to avoid this issue completely.
The authors had previously discussed this point at some length and
believe that protocol design should not be shaped by the possiblity
of dysfunctional implementations. Further, the use of a new object
might also cause problems with defective implementations.
The authors propose no changes to the I-D for this point, but will
send mail to the MPLS mailing list to check that the 'owners' of
RSVP-TE have no issue with this use of a previkously reserved
field.
b. Illogicality of use of Session object
Ben and Lyndon expressed the view that it would be more
logical to place the short call ID in a new object than to
complicate the concept of the Session. The possibility of
using the Association object was also raised.
The authors had discussed this at some length over the
last two years that the I-D has been in production, and
recently on the mailing list. Our conclusion is that:
i. The Association object is for associating LSPs with
each other. The call ID is used to associate LSPs
with a call.
ii. A separate object would be perfectly functional.
iii. There is already some logical association between the
session and the LSPs in the call, and it makes sense to
extend this.
iv. The key on the Notify message is the session.
v. The current I-D is also perfectly functional, and has been
successfully implemented.
Given that no specific draw-back to the current encoding has been put
forward except for a feeling of illogicality among some readers, the
authors
propose no further action except for polling the MPLS WG as described
above.
4. Procedures for including LINK_CAPABILITIES object
A comment was made that this appears to be totally optional without any
defined procedures for how an LSR should decide wheter to include the
object.
The authors agree with this view, and it is intentional. The draft
states...
The LINK CAPABILITY object is introduced to support link capability
exchange during Call setup and MAY be included in a Notify message
used for Call setup. This optional object includes the bundled link
local capabilities of the Call initiating node (or terminating node)
indicated by the source address of the Notify message.
This text makes it quite clear that the object is completely optional.
The authors propose to make no changes for this point.
5. Question about processing rules in section 6.2.1
There was a detailed quesiton about the procedure in seciton 6.2.1.
The authors believe that this was answered and concluded on the mailing
list.
The authors propose to make no changes for this point.
6. Refresh Notify
Lyndon asked whether the refresh of the Notify message is really
necessary
if there are active LSPs in the call? Possibly the LSP refresh
could be sufficient, since this carries the short Call ID. He also asked
if it possible that the call would be dropped while there are still
active LSPs.
The authors consider that you cannot infer the status of the call when
there
are no connections on the call. They believe that a single mechanism
should be used to monitor the call status in all circumstances.
The draft describes refresh failure of calls when connections already
exist
in section 6.7.
In short, we propose to make no changes to the document as a result of
WG
last call. We will notify the MPLS WG as described above.
Can this I-D now move on the ADs?
Thanks,
Adrian