Re: Consensus to progress documents
Dimitri.Papadimitriou@alcatel.be Thu, 27 March 2003 23:37 UTC
Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 27 Mar 2003 15:41:21 -0800
Message-ID: <3E838B23.96C50CE3@alcatel.be>
Date: Fri, 28 Mar 2003 00:37:07 +0100
From: Dimitri.Papadimitriou@alcatel.be
Organization: optical network architecture (nta - antwerpen)
MIME-Version: 1.0
To: Kireeti Kompella <kireeti@juniper.net>, ccamp@ops.ietf.org
Subject: Re: Consensus to progress documents
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
1. (*) - 2. Y - 3. (**) - 4. Y note 1 (*): i've heard different voices during the meeting and i'd like first to clarify them :useful but encoding issues - where are these encoding issues ? and compared to what ? work first on an architecture document and then come up with a solution ? which architecture ? and from which perspective ?) anyway i think this document addresses perfectly one of the comments made during on applicability of discovery (see below) note 2 (**): on 3. some sentences needs to be clarified before imho moving forward (they follow some of the remarks made by john last friday): "LMP was developed with a IP framework in mind. However many transport elements do not support IP natively and as a result the concepts of LMP need to be adapted to the transport world." -> see gmpls-arch "LMP is defined in the context of GMPLS, but is specified independently of the GMPLS protocol suite [...] Consequently, LMP can be used in other contexts with non-GMPLS protocols." "One fundamental difference between LMP and G.8080 discovery frame work is the absence of the explicit separation between transport and control plane names." [...] "the TCP ID in G.7714.1 is a transport layer ID that may or may not use any of those format." -> this is why the data plane "name" space is part of the <TRACE> object, this separation is currently delivered by lmp sonet-sdh (and has been extended to other technologies such as oth), when separation between data and control plane name space is provided using for the former a value space other than IPv4/IPv6/Unnum, the Trace Correlation mechanism does the job => this relates to the comment we received "discovery as defined by itu is a data plane application" therefore bi-directional trace correlation mechanism proposed in the bootstrap i-d makes perfectly the job here - this means that if the bootstrap doesn't fly beyond the last meeting a dedicated i-d describing this method would be the way to go - thanks, - dimitri. --- Kireeti Kompella wrote: > > Hi, > > As decided in the CCAMP 56 meeting, we are taking the following to > the list for consensus to make WG documents. Please indicate your > response for each (Y=make it a CCAMP WG doc; N=not; -=don't care): > > 1. draft-lang-ccamp-lmp-bootstrap-03.txt > > 2. draft-mannie-ccamp-gmpls-sonet-sdh-{ospf,isis} > > 3. draft-aboulmagd-ccamp-transport-lmp-00.txt > > 4. draft-bonica-tunproto-04.txt > > Thanks, > Kireeti. -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491
- Re: Consensus to progress documents Dimitri.Papadimitriou
- Consensus to progress documents Kireeti Kompella