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