RE: ASON reqts

[John Drake <jdrake@calient.net>]

We've been through all of this before many times.  Because the call, even in
complete separation mode, is established using Path/Resv, intermediate nodes
that don't understand what is going on will instantiate state and allocate
resources as if a connection is being established.

> -----Original Message-----
> From: Jonathan Sadler [mailto:jonathan.sadler@tellabs.com]
> Sent: Tuesday, May 13, 2003 4:59 PM
> To: John Drake
> Cc: 'Stephen Trowbridge'; 'Wijnen, Bert (Bert)'; Kireeti Kompella;
> ccamp@ops.ietf.org
> Subject: Re: ASON reqts
> 
> 
> John -
> 
> What does section 9.2 of RFC 3474 accomplish then?  (For 
> those unaware, Sect.
> 9.2 is titled "Complete Separation of Call and Connection")
> 
> Jonathan Sadler
> 
> John Drake wrote:
> 
> > I think that the problem is that RFC 3474, in addition to 
> its technical
> > issues, doesn't address all of the ASON requirements.  For 
> example, it does
> > not address full call/connection separation.  So we're 
> following the post
> > 3474 procees of documenting the ASON requirements relevant to GMPLS
> > signalling in order to have a common understanding of what 
> problem is to be
> > solved.
> >
> > > -----Original Message-----
> > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
> > > Sent: Monday, May 12, 2003 2:27 PM
> > > To: John Drake
> > > Cc: 'Wijnen, Bert (Bert)'; Kireeti Kompella; ccamp@ops.ietf.org
> > > Subject: Re: ASON reqts
> > >
> > >
> > > Bert & John,
> > > I think this document has nothing to do with the issue Bert
> > > mentioned. This was a protocol issue, not a requirements issue.
> > > A decision was made to leave the message out of 3474 with the
> > > belief that:
> > > - The protocol works without it; and
> > > - The presence of the message violates the protocol.
> > > The appropriate next step here would be a liaison back to ITU-T
> > > explaining what was done and why, and if the ITU-T agrees with
> > > the reasoning, they can align their protocol document (in this
> > > case, G.7713.2).
> > >
> > > Back to Bert's original questions:
> > > > > > > - is there or do we see any conflict?
> > > - As Zhi said, this is not (yet) fully aligned with ITU-T 
> requirements
> > >   and should not be advanced to a WG document until it is.
> > > However, before
> > >   we do, I think we need to understand why this is necessary
> > > - see below.
> > >
> > > > > > > - are we duplicating some work?
> > > - Almost certainly. If we take the kind of alignment with ITU-T
> > >   requirements that Zhi mentions as a "gate" for progressing
> > > this, then
> > >   what is in this document that is different from G.8080 and
> > > G.7713 and
> > >   why do we need this in place of a normative reference?
> > >
> > > > > > > - what is the purpose of this draft?
> > > Excellent question.
> > > > > > >   - is it after the fact documenting of requirements?
> > > If it is, why bother? Also, we already have the requirements
> > > (developed
> > > before the protocol) in G.8080 and G.7713.
> > >
> > > > > > >   - is it getting ITU-T documented requirements 
> in RFC form?
> > > This could be a reasonable goal, if this document is to be an info
> > > track requirements document characterizing G.8080 and G.7713 for
> > > IETF folks in the same way that RFC 3474 does for G.7713.2 and
> > > RFC 3475 does for G.7713.3. But it is hard to understand 
> why producing
> > > an IETF translation of the ITU-T question would be very 
> high priority
> > > when we already have an IETF translation of the answer, but
> > > fundamentally
> > > there would be no problem if this were the objective.
> > >
> > > > > > >   - is it extending ITU-T documented requirements?
> > > I don't think so. If it is, I hope we start with a liaison rather
> > > than trying to extend ITU-T requirements without talking to
> > > ITU-T first.
> > >
> > > > > > >   - is it contrdicting them?
> > > This is my biggest worry. I don't think we should start 
> the process
> > > over again and open the door that we come up with yet another
> > > protocol solution to address the same requirements. Vendors are
> > > already building to G.7713.2, G.7713.3 (and by extension, to
> > > RFC 3473+3474 and RFC 3472+3475). We most definitely should NOT
> > > start a new work item with an objective to develop a new protocol
> > > solution to the same problem.
> > >
> > > > > > >   - is it meant to be used as communication to ITU?
> > > I haven't seen this proposed, but I think that if the goal is
> > > to capture ITU-T requirements in RFC form, it would be a good
> > > idea to ask ITU-T whether the proposed document accurately
> > > captures their requirements.
> > >
> > > /Steve
> > >
> > >
> > > John Drake wrote:
> > > >
> > > > Bert,
> > > >
> > > > I think so.
> > > >
> > > > Thanks,
> > > >
> > > > John
> > > >
> > > > > -----Original Message-----
> > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> > > > > Sent: Monday, May 12, 2003 1:27 PM
> > > > > To: John Drake; Kireeti Kompella; ccamp@ops.ietf.org
> > > > > Subject: RE: ASON reqts
> > > > >
> > > > >
> > > > > I know that some people had issues with the way that ITU-T
> > > > > had defined the RSVP-TE extensions for ASON. In fact there
> > > > > was/is a claim that it is broken. So we removed the offending
> > > > > text from the RFC3474.
> > > > >
> > > > > The next thing we were going to do (as far as I understood it)
> > > > > is to document why we (or some of us in IETF) think that the
> > > > > ITU-T solution is broken, potentially with suggested fixes.
> > > > > That we would send to ITU-T SG15.
> > > > >
> > > > > Is this the first step of that process?
> > > > >
> > > > > Thanks,
> > > > > Bert
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: John Drake [mailto:jdrake@calient.net]
> > > > > > Sent: maandag 12 mei 2003 22:24
> > > > > > To: 'Wijnen, Bert (Bert)'; Kireeti Kompella; 
> ccamp@ops.ietf.org
> > > > > > Subject: RE: ASON reqts
> > > > > >
> > > > > >
> > > > > > Bert,
> > > > > >
> > > > > > I thought that the post 3474/3475 process started with a
> > > > > requirements
> > > > > > document.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > John
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> > > > > > > Sent: Monday, May 12, 2003 1:14 PM
> > > > > > > To: Kireeti Kompella; ccamp@ops.ietf.org
> > > > > > > Subject: RE: ASON reqts
> > > > > > >
> > > > > > >
> > > > > > > So if we look at RFCs 3474/3475 and the ITU-T documents
> > > > > > > that those 2 RFCs point to, then I wonder:
> > > > > > > - is there or do we see any conflict?
> > > > > > > - are we duplicating some work?
> > > > > > > - what is the purpose of this draft?
> > > > > > >   - is it after the fact documenting of requirements?
> > > > > > >   - is it getting ITU-T documented requirements 
> in RFC form?
> > > > > > >   - is it extending ITU-T documented requirements?
> > > > > > >   - is it contrdicting them?
> > > > > > >   - is it meant to be used as communication to ITU?
> > > > > > >
> > > > > > > Just wondering what is happening here.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Bert
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Kireeti Kompella [mailto:kireeti@juniper.net]
> > > > > > > > Sent: maandag 12 mei 2003 17:25
> > > > > > > > To: ccamp@ops.ietf.org
> > > > > > > > Subject: Re: ASON reqts
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi All,
> > > > > > > >
> > > > > > > > On Fri, 2 May 2003, Kireeti Kompella wrote:
> > > > > > > >
> > > > > > > > > To take things one at a time, it would be 
> very useful to
> > > > > > > > read and comment
> > > > > > > > > on the ASON reqts draft, as this was deemed 
> tremendously
> > > > > > > > important, and
> > > > > > > > > a rich source of misunderstanding and cross-talk; and
> > > > > > > > coming to a common
> > > > > > > > > understanding over this should help get the 
> IETF and the
> > > > > > > ITU working
> > > > > > > > > together.
> > > > > > > >
> > > > > > > > I haven't seen many comments, so the assumption is
> > > > > either that no
> > > > > > > > one cares, or that folks have read it and have 
> no issues.
> > > > > > > >
> > > > > > > > I'd like to get a reading on whether this doc is
> > > ready to be a
> > > > > > > > CCAMP WG document.  Please respond (preferably publicly)
> > > > > > > with one of:
> > > > > > > >  - "I have read this document and it is ready 
> to be a CCAMP
> > > > > > > WG doc" OR
> > > > > > > >  - "I have read this document, and it isn't 
> ready to be a
> > > > > > > CCAMP doc".
> > > > > > > >
> > > > > > > > Note that if there aren't enough responses, the default
> > > > > > > assumption is
> > > > > > > > that the document is either not of interest or not
> > > ready, and in
> > > > > > > > either case will not become a CCAMP WG doc.  Note too
> > > > > > that this doc
> > > > > > > > is an attempt to bridge some gaps between the IETF and
> > > > > the ITU-T,
> > > > > > > > and as such is fairly important.  It would be
> > > useful to give an
> > > > > > > > update on its status at the interim T1X1 
> meeting in June.
> > > > > > > >
> > > > > > > > Please get your responses in by COB Friday May 16th.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Kireeti.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> 
> ============================================================
> 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
> ============================================================
>