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

Dimitri,

OK. Will do. 

Cheers,
/Dan

-----Original Message-----
From: [email protected]
[mailto:[email protected]] 
Sent: Wednesday, September 03, 2003 6:24 PM
To: [email protected]
Cc: [email protected]; 'Bala Rajagopalan';
[email protected]
Subject: 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