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