RE: concerns on draft-ietf-ipo-framework-04.txt

Dimitri,

I was away and missed your email. However, it was 
brought to my attention recently. 

Please note the last call for this document closed several 
months ago... Nevertheless, we are responding to your 
comments as a courtesy and because it helps to clarify 
some issues. However, there is no intention to open further 
discussions on this document. 

- The terms "adaptation" and "adapt" were used consistently 
  according to standard English dictionary definitions, 
  i.e., "to make fit or suitable by changing or adjusting." 
  
- The sentences referencing the OIF UNI have been removed. 
  They do not add to the substance or continuity of the 
  document. 

1. In Section 5.1.2, we have modified the sentence concerning
   the overlay model as follows: "In the overlay model, a 
   separate instance of the control plane (especially the 
   routing and signaling protocols) would have to be 
   deployed in the optical domain, independent of what 
   exists in the IP domain." 

2. In Section 5.3.1, we have removed references to the 
   OIF UNI and modified the affected sentence(s) as follows: 
   "MPLS signaling protocols with traffic engineering 
   extensions, such as RSVP-TE, can be appropriately 
   modified and used for signaling lightpath requests. 
   These protocols can be adapted for client/server 
   signaling in the case of the domain services model, 
   and for end-to-end integrated signaling in the case 
   of the unified services model."

An updated version of the document incorporating these 
modifications and addressing prior IESG comments will be 
issued shortly.

Cheers,
/Dan

-----Original Message-----
From: [email protected]
[mailto:[email protected]] 
Sent: Sunday, August 10, 2003 6:27 AM
To: [email protected]
Cc: Bala Rajagopalan; [email protected]
Subject: concerns on draft-ietf-ipo-framework-04.txt


all,

there is imho a paradox in this i-d, it states:

"The first is the adaptation and reuse of IP control plane
  protocols within the optical network control plane, irrespective of
  the types of digital clients that utilize the optical network. "

note: the term "adaptation" must be followed by a statement that clearly
mentions what it means here - imho it should reflect backward
compatibility with proposed standard rfc's -

and then it says: "Using a common signaling framework (based on GMPLS)
from the beginning facilitates this type of evolution. For the domain
services model, implementation agreement based on GMPLS UNI signaling is
being developed in the Optical Interworking Forum (OIF) [5, 6]. This
agreement is aimed at near term deployment and this could be the
precursor to a future peer model architecture."

thus without wanting to make any promotion ;-) it makes the apology of
the non-GMPLS signaling compliant (ie RFC 3471/2/3) OIF (point-to- point
signaling interface) implementation agreement which can not (by
definition) be a peer model architecture precursor as defined in the
scope of the IETF - it also refers to "near term deployment" taking
mid'01 as baseline here what do we have to assume that the OIF UNI lost
momentum ?

but the most surprising is to come "In this evolution, the signaling
capability and semantics at the IP-optical boundary would become more
sophisticated, but the basic structure of signaling would remain. This
would allow incremental developments as the interconnection model
becomes more sophisticated, rather than complete re-development of
signaling capabilities."

something impossible since the OIF basic "structure of signaling" is not
GMPLS compliant from the beginning it will give rise to the complete
redevelopment of the (currently available) signaling capabilities when
moving to more sophisticated interconnection models ... or does the
conditional mode used here wasn't related to the "evolution" but just in
case it would remain at its first stage ?

thus, i think this i-d doesn't help anymore in detailing the current or
any potential evolutionary path since starting from the OIF UNI
developments. In particular by mentioning the latter it puts them under
real questioning since this framework does not rationalize for any GMPLS
RFC bias as currently promoted by OIF, as also reproduced in the
following sections:

1. section 5.1.2 is confusing, separating control plane instances does
not mandate the definition of brand new protocols as currently inferred
by this paragraph

2. nothing in this document justifies the following as stated in the
section 5.3.1 "In the case of the domain services model, these protocols
can be adapted for UNI signaling as well [5, 6]." in particular (see
5.3.2) "While RSVP-TE and LDP can be adapted for UNI signaling, the full
functionality of these protocols will not be used. For example, UNI
signaling does not require the specification of explicit routes. On the
other hand, based on the service attributes, new objects need to be
signaled using these protocols as described in [5, 6]." all these
assertions are closely related to the OIF UNI developments but no
rationale are given in order to mandatorily do so.

hence, would it be possible to reconsider the scope of this document by
withdrawing any implicit reference to oif uni developments which are
imho outside of the scope of a framework since clearly addressing
implementation specific aspects (btw, overlay model does not imply oif
uni only the reverse statement is true, the oif uni is only a very
particular implementation of the overlay control plane inter- connection
model using a non-gmpls compliant p2p signaling interface)

thanks,
-- 
Papadimitriou Dimitri
E-mail : [email protected]
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email protected]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491