Re: AD-review of draft-ietf-ipo-carrier-requirements
[email protected] Thu, 07 Aug 2003 23:14:00 +0200
| Newsgroups | gmane.ietf.ipo |
|---|---|
| Message-ID | <[email protected]> |
alex, all,
if this i-d is progressed then real significant improvement on the
content (and its consolidation) is to be expected here (and this
without saying from an *ietf perspective*)
imho as it stands now it does not help the developer community to
understand the real functional/operational needs of the user
community by reproducing pieces found here and there in other
organization's repositories (it really mixes several dimensions
altogether from modeling until system design aspects thus not
serving any particular purpose - this is probably due to the
several shifts this i-d has pass through since the london'01
meeting)
in any case the following are my major concerns on this i-d:
(1) Section 1.3
" This document is intended to be protocol-neutral, but the specific goals
include providing the requirements to guide the control protocol development and
enhancement within IETF in terms of reuse of IP-centric control protocols in the
optical transport network."
=> the above sentence is unclear, i think the first part of the
sentence means "requirements on functions to be delivered for
controlling optical networks are intentionally provided
independently of their actual protocol implementation" or
something like this since strictly speaking it is impossible
to be simultaneously protocol neutral and IP-centric in my view.
(2) Section 1.3
"The Optical Internetworking Forum (OIF) carrier group has developed a
comprehensive set of control plane requirements for both UNI and NNI
[oif-carrier, oif-nnireq] and they have been used as the base line
input to this document."
=> OIF being an implementation agreement body it is really questionable
if these requirements weren't oriented to specific implementation
issues and thus opposed to the above statement (on implementation
neutrality)
(3) Section 1.3
"This document provides further detailed requirements based on the
ASTN/ASON framework."
=> ASTN is a meta-model, a model that includes using the itu terminology
any connection oriented packet switching and circuit switching
technology, this document should focus on ASON (focusing on optical
switching technologies) since afaik the focus is on "IPO" here
(4) Section 4.1
"The separation of control, management and transport function is
required and it shall accommodate both logical and physical level
separation."
=> clarification would be appreciated on what "logical level separation"
means for "transport function"
(5) Section 4.2
"The call control shall be provided at an ingress port or gateway port
to the network such as UNI and E-NNI [see Section 6 for definition]."
=> some operators ask us to deliver this capability at the intra-domain
level also, and the relationship with the port is unclear (here,
clarifications would be more than appreciated)
(6) 6.2. Control Domains and Interfaces
"A generic carrier network reference model describes a multi-carrier
network environment. Each individual carrier network can be further
partitioned into sub-networks or administrative domains based on
administrative, technological or architectural reasons."
=> the second sentence should clarify the relationship between
partitioning into subnetworks and administrative domain
"The demarcation between domains can be either logical or physical and
consists of a set of reference points identifiable in the optical
network."
=> the demarcation is logical by definition since discussing here
control plane aspects (i.e. these reference points aren't related
to the transport plane capabilities but to the control plane)
"Figure.1" => it should be mentioned that illustrates one possible
usage of these demarcation points and does not constitute a reference
model a control domain does not have necessarily a one-to-one mapping
with a given subnetwork (example dom B with a single sub-network)
"An example of fully trusted interface is an I-NNI between two optical
network elements in a single control domain."
=> a confusing example to be rephrased as "between two single
control components (or simply controllers) ..."
(7) Section 6.3.1
"It may be the result of using hierarchical layering, different
technologies across access, metro and long haul (as discussed below),
or a result of business mergers and acquisitions or incremental optical
network technology deployment by the carrier using different vendors or
technologies."
=> hierarchical layer stands then at the transport plane level,
this should be clarified here (and as such expectations from the
control plane perspective aren't clear)
(8) Section 7.2
"All the bearer interfaces implemented in the ONE shall be supported by
the control plane and associated signaling protocols."
=> there is a mismatch here, ONE should be replaced by control plane
component
"- Passive Optical Network (PON) based on ATM (APON) and Ethernet
(EPON)"
=> not sure that in the scope of ASON (first time i heard about
E/A/PON in the ASON context)
(9) Section 7.3
"- The UNI shall support initial registration and updates of the client
with the network via the control plane."
=> the word "registration" deserve some clarification here
(9) Section 8.1
"For the signaled, either direct or indirect signaling methods can be used
depending upon if the UNI proxy is utilized on the client side.
The detailed discussion on the UNI signaling methods is in [oif-uni]."
=> being an implementation specific agreement, i don't understand
the above reference wrt to the scope of this document (being
stated as "implementation neutral")
(10) Section 8.4.1
"- Transport Network Assigned (TNA) address: This is a routable address
in the optical transport network and is assigned by the network."
=> TNA's has been defined at the OIF as an "enveloppe" to carry IPv4/
IPv6 and NSAP's - from this perspective nothing is provided to assess
the need of such capability - (some claims that TNA's are names that
are associated to TE Link numbered/unnumbered Id's & in such a case
this address space is not a routable address space on the other side
some are currently working on re-defining TNA's as TE Link addresses)
but more importantly there is no evidence at all that there is any
operational need for having an IP-based control plane that is
capable to process NSAP's -> thus seriously questioning the reason
for the introduction of this concept (in particular from an ietf
perpective)
(11) Section 8.4.2.
"The directory service is essential for the implementation of overlay model."
=> seems like an assertion, overlay models can be implemented without
any directory service (clarification on the directory service req's
is more than appreciated)
(12) Section 9.2
"The UNI control channel and proxy signaling defined in the OIF UNI 1.0
[oif-uni] shall be supported."
=> same remark as above concerning a reference to an implementation
specific agreement
(13) Section 9.3
"Data plane shall monitor and detect the failure (LOL, LOS, etc.) and
quality degradation (high BER, etc.) of the signals and be able to
provide signal-failure and signal-degrade alarms to the control plane
accordingly to trigger proper mitigation actions in the control plane."
=> provide references since strictly speaking outside of the scope of
both ASON control plane and also IPO WG requirements
(14) Section 10.1
"Address resolution exchange over UNI is needed if an addressing
directory service is not available."
=> this is quite confusing here "address resolution" between what
and what ?
(15) Section 10.2
"- The inter-domain signaling protocol shall be agnostic to the intra-
domain signaling protocol for all the domains within the network."
=> the term agnostic should be clarified here (if this meant to say
intra-domain signalling can be proprietary then better explain
exactly that "interworking function between standard and proprietary
protocols running at the intra-domain level shall be stictly
confined at this level i.e. without impacting the standard inter-
domain signalling protocol behaviour")
(16) Section 10.3
"All three mechanisms (Hop-by-hop routing, explicit / source-based
routing and hierarchical routing) must be supported."
=> does routing mean signalling here (hop-by-hop, source-based) ?
and what hierarchical routing means in that context ?
"- The exchange of the following types of information shall be
supported by inter-domain routing protocols:
- Inter-domain topology
- Per-domain topology abstraction"
=> would be of interest to have a bit more information on what
is expected with "inter-domain topology" concerning the second
point is there any relevant reference that may help in defining
"per-domain topology abstraction" - also it has been mentioned
in Section 10.1 "Topology information shall not be exchanged across
inter-carrier E-NNI and UNI." would it be possible to achieve
consistance among these requirements ?
"The routing protocol shall be able to support different levels of
protection/restoration and other resiliency requirements. These are
discussed in Section 11."
=> independently of the content of the Section 11 the first sentence
is quite confusing what does "routing protocol protection/restoration"
really means ? and what's expected ?
(17) Section 10.4
"- Path selection algorithms shall provide carriers the ability to
support a wide range of services and multiple levels of service
classes. Parameters such as service type, transparency, bandwidth,
latency, bit error rate, etc. may be relevant."
=> what latency means in the scope of "path selection" algorithms
"Constraint-based routing in the optical network in significantly
complex Compared to the IP network. There are many optical layer
constraints to consider such as wavelength, diversity, optical layer
impairments, etc. A detailed discussion on the routing constraints at
the optical layer is in [ietf-olr]."
=> this said "optical layer impairments" such as described in [IETF-OLR]
is not currently in the scope of the ITU ASON work
(18) Section 10.5.1
"- Physical media adjacency that detects and verifies the physical
layer network connectivity between two connected network element
ports."
=> wise to clarify here what is expected from the control plane
perspective here
(19) Section 11.2
"The control plane failure shall only impact the capability to
provision new services."
=> services meaning connections ?
"Recovery from control plane failures shall result in complete recovery
and re-synchronization of the network."
=> why recovery should impact the *whole* network is this
requirement not in contradiction with robustness ?
"There shall not be a single point of failure in the control plane
systems design."
=> this is an implementation specific requirement (since "system
design" is mentioned here)
"Partial or total failure of the control plane shall not affect the
existing established connections. It should only lose the capability
to accept the new connection requests."
=> the second sentence is confusing in case of total failure of the
control plane none of the control plane function will be accessible
so not sure this is the only capability that will be lost
(20) Section 12.1.1
"For enhancing integrity and confidentiality of data, it may be helpful to
support scrambling of data at layer 2 or encryption of data at a higher layer."
=> is this really something that should be controlled by the ASON
control plane ?
-----
John Drake wrote:
> Alex,
>
> I read this draft several months ago and I would agree with your
> characterization of it. As such, it doesn't seem to serve any particular
> purpose.
>
> Thanks,
>
> John
>
>
>>-----Original Message-----
>>From: Alex Zinin [mailto:[email protected]]
>>Sent: Friday, July 25, 2003 2:06 PM
>>To: [email protected]
>>Subject: [IP-Optical] AD-review of draft-ietf-ipo-carrier-requirements
>>
>>
>>Folks-
>>
>> After reading the document, I was left with the feeling that it is
>> not clear to me whether the document is simply a recompilation of the
>> material found in other organizations (such as OIF and ITU), or
>> something unique for the IETF. I asked several individual reviewers
>> to read the document and give me their opinions. All of them
>> mentioned similar concerns and indicated that the document should not
>> go forward.
>>
>> Before I can take the document to the IESG, I need to make sure it
>> represents wide consensus within the SUB-IP community and the WG in
>> particular. With this in mind, I would like to ask the WG chairs to
>> initiate another 2-week WG Last Call. I would also like the WG
>> participants to express their opinion on the document, and
>> specifically their support of the document going forward, and the
>> reasons why (if at all) they believe the document would be useful
>> with its current contents. Please make sure you've read the latest
>> version of the draft.
>>
>> Regards
>>
>>--
>>Alex Zinin
>>IETF SUB-IP Area co-Director
>>
>>_______________________________________________
>>IP-Optical mailing list
>>[email protected]
>>http://lists.bell-labs.com/mailman/listinfo/ip-optical
>>
>
> _______________________________________________
> IP-Optical mailing list
> [email protected]
> http://lists.bell-labs.com/mailman/listinfo/ip-optical
--
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