Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt

[[e-mail]]

in order for the ccamp wg to have a clear understanding
a clarification is needed here, the code-point extension
document which had been submitted for ason purposes had 
been discussed during the yokohama meeting, the consensus
was to put it back and then first come with a requirement
document (i refer here to the yokohama meeting discussions)
which is a good idea in order for the ietf ccamp wg to have
a decoder ring concerning the ason application needs... and
then start to think about extensions...

... but as far as i understand it the needs from the itu-t 
were so urgent they couldn't wait about a ccamp community 
discussion on the relevance of these proposed extensions, 
and so went the decision (don't ask me who is behind this?) 
to push it as an individual submission in order to accelerate 
the process of receivng the code-points

... it is sometime good to remember how things happened, but
in any case, the conclusion is that within the "overlay class
of application" we have now clearly one solution when both
side (the edge and the core node) have a lower trust relationship 
(one can refer to it as public uni) and one solution when 
they have a higher trust relationship (one can refer it as 
private uni), each of them have different applicability scope.

ps: i should also mention that the user community needs for 
public switched connections using the oif public uni is 
afaik somehow low and doesn't in any case preclude the 
definition of another solution

thanks,
- dimitri.



"Lin, Zhi-Wei (Zhi)" wrote:
> 
> Hi all,
> 
> Actually the work been done in the ITU-T deals specifically with the overlay, at least the application that operators have identified as been important to them. These documents are planned to be consented at the Jan ITU-T meeting (G.7713.x series). ITU-T has communicated to the IETF regarding this work for some time now (I'm bad at remembering dates but you can probably trace back the emails or the liaison statements).
> 
> In addition, I have submitted two I-Ds, one on requirements and another on protocol extensions needed to support the overlay. It is my understanding that the protocol extensions document has passed through IESG review and sent off to the RFC editors already?
> 
> http://www.ietf.org/internet-drafts/draft-lin-ccamp-gmpls-ason-rqts-00.txt
> 
> http://www.ietf.org/internet-drafts/draft-lin-ccamp-gmpls-ason-rsvpte-04.txt
> 
> You can see the status of the ...rsvpte-04 document from the IESG status tracker
> https://datatracker.ietf.org/public/pidtracker.cgi
> 
> Zhi
> 
> -----Original Message-----
> From: Ashok Narayanan [mailto:[e-mail]]
> Sent: Tuesday, December 03, 2002 3:30 PM
> To: Kireeti Kompella
> Cc: [e-mail]
> Subject: Re: WG Consensus Call: draft-swallow-gmpls-overlay-00.txt
> 
> I would vote that this should be considered in some guise or other in
> the WG. It answers a specific set of questions in a certain way - "how
> can I do GMPLS-style optical signaling without exposing so much peering
> information". AFAIK there aren't CCAMP WG documents that deal with this
> issue in a specific manner.
> 
> -Ashok
> 
> On Tue, 2002-12-03 at 14:39, Kireeti Kompella wrote:
> > Hi,
> >
> > This is a call for consensus to make the above document a CCAMP WG
> > document.  This call will end Dec 17, 2002.
> >
> > Please indicate your opinion by replying to this email.
> >
> > Thanks,
> > Kireeti.
> >
> >

-- 
Papadimitriou Dimitri 
E-mail : [e-mail] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [e-mail]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: [phone] - Home: [phone]