[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 Ben,
Thanks for providing the additional details on your previous questions. I think this now gives us something to answer and we will come back to you in a couple of days. 

Adrian
----- Original Message ----- From: "Mack-Crane, T. Benjamin" <Ben.Mack-Crane@tellabs.com> To: "Adrian Farrel" <adrian@olddog.co.uk>; "Brungard, Deborah A, ALABS" <dbrungard@att.com> 
Cc: <ccamp@ops.ietf.org>
Sent: Friday, July 14, 2006 5:42 PM
Subject: RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt 


Hi Adrian,

There were also these comments which have not been fully addressed
afaik:


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


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


I would be interested to know how to correctly understand the draft.
That is, what addressing other than IPv4/6 is supported, and how
multiple address spaces are supported.

Regards,
Ben



-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On

Behalf

Of Adrian Farrel
Sent: Wednesday, July 12, 2006 2: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


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