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

dan, thanks for taking this into account, the only remaining
point i have is as follows, i would replace the word "modified"
by "extended" in the following sentence "MPLS signaling
protocols with traffic engineering extensions, such as RSVP-TE,
can be appropriately modified and used for signaling lightpath
requests." - these terms have different semantic and are
important in the context of this sentence -

thanks,
- dimitri.

Daniel O. Awduche wrote:
> 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