[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ASON reqts
> -----Original Message-----
> From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
> Sent: Monday, May 12, 2003 3:23 PM
> To: John Drake
> Cc: 'Wijnen, Bert (Bert)'; Kireeti Kompella; ccamp@ops.ietf.org
> Subject: Re: ASON reqts
>
>
> John,
> Ahhhh....
> This sounds like a whole new can of worms. The goal therefore does
> seem to be to develop yet another protocol solution, and I think
> we need to be VERY careful before taking this kind of step.
>
> Your assertion now seems to be that RFC 3473+3474 does NOT meet the
> ASON requirements.
JD: Actually that was my position all along.
> If this is the case:
> - Does G.7713.2 meet the requirements, and we missed something in
> the translation to RFC 3474? If so, then we need to supercede
> RFC 3474 with a better translation, not start over.
JD: Excellent, glad you're on board
>
> - Do you think that even G.7713.2 does not meet the requirements?
> If you believe this to be the case, it seems like the obvious
> first step would be to inform ITU-T - after all, this is where
> the ASON requirements came from and it makes no sense to start
> a new protocol without fixing (and aligning) G.7713.2.
>
> If we made a mistake, lets fix it, but lets NOT start proliferating
> ASON extensions take 2; ASON extensions take 3; ...
>
> Regards,
> Steve
>
> 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.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
>