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

[email protected] Sun, 10 Aug 2003 12:27:26 +0200
Newsgroups gmane.ietf.ipo
Message-ID <[email protected]>
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