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