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

["Adrian Farrel" <adrian@olddog.co.uk>]

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