RE: Communication from the OIF

["Ong, Lyndon" <LyOng@Ciena.com>]

Hi Adrian, Folks,

Just wanted to note that the OIF is very interested in reestablishing
relationships with the IETF and CCAMP.  This topic came up at the last
OIF meeting and a number of the participants expressed support and
urged that this be done soon.  There is already a regular slot in
the OIF agenda for reporting on new developments in the IETF that 
may be of interest.  I have also asked the OIF Secretariat to look
into mechanisms that would allow OIF draft documents to be accessible
to IETF members, if a liaison is sent asking for their review.

This particular liaison was sent following interoperability testing
done at OIF member labs prior to and leading up to the 2004
Supercomm show.  OIF would be very interested in comments on the
testing results and hope that the results will be helpful to IETF.

Cheers,

Lyndon Ong
(currently IETF liaison representative in the OIF)

-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Saturday, August 28, 2004 4:52 AM
To: ccamp@ops.ietf.org
Subject: Communication from the OIF


All,

We have received a communication from the OIF. This is pasted as ASCII text below.

You can see the PDF version at http://www.olddog.co.uk/incoming.htm

There are several direct questions and issues raised in the communication and we should
respond. Volunteers to draft text are eagerly sort.

Adrian

====
August 11, 2004
Mr. Adrian Farrel, adrian@olddog.co.uk, IETF, CCAMP Working Group Chair
Mr. Kireeti Kompella, kireeti@juniper.net, IETF, CCAMP Working Group Chair
Mr. Alex Zinin, zinin@psg.com, IETF, Routing Area Director
Mr. Bill Fenner, fenner@research.att.com, IETF, Routing Area Director
Re: Results from OIF World Interoperability Demo
Dear Adrian, Kireeti, Alex and Bill,
Thank you for your recent communication of June 27, 2004. We appreciate the ongoing
dialogue and
information provided.
As previously communicated, the OIF successfully held its World Interoperability Demo at
Supercomm
2004 (see http://www.oiforum.com/public/pressroom/Demo04-June9.pdf and
http://www.oiforum.com/public/pressroom/OIF-Post-Demo-FINAL.pdf). This demo included the
ASON compliant OIF UNI and ENNI Implementation Agreements.
Due to the number of implementations involved (15 vendors, 7 carriers) we were able to
learn much
from the demo. The OIF would like to share some of these control plane results and solicit
guidance
from CCAMP on some issues. Successful interoperability tests included:
?? Switched Connections (SCs)- UNI clients calling other UNI clients
?? Soft Permanent Connections (SPCs) - network management driven calls including those
that
traversed ENNIs.
?? SC to SPC calls - a UNI client with a call to an SPC client (and vice-versa)
?? ENNI routing - link state inter-domain routing
?? Call using OC-3c and VC-4 links for an STS-3c equivalent connection. This used the
common
signal type of 6.
Some things we learned were:
?? In addition to the Srefresh message, it was helpful to periodically send the full
refresh message
as it helped the topology display system track calls. (This is consistent with an option
described
in RFC 2961 section 5.5.)
?? For SPCs, we determined that it was helpful to use a TNA as the context for the SPC
egress label
because for the interdomain case, the name of the egress network element would not
necessarily
be known.
?? Interpretation of the encoding for SUKLM. There was some inconsistency in the
interpretation
of the S bit setting which we think arose from use of earlier text on SONET/SDH encoding
types.
Implementers should be encouraged to adhere to draft-ietf-ccamp-gmpls-sonet-sdh-08.txt.
?? Loss of a signaling adjacency effectively makes a data-plane link unavailable. Since
the network
does not support crankback (yet), there is no way to recover from this situation. It is
suggested
that a link attribute be added to state whether the link capacity being advertised is
available for
new connection admission.
Issues that we seek guidance from CCAMP are:
?? There was a new capability proposed in which a client that has an SPC becomes UNI
capable
and the operator wants to create SC state for the client so that it can teardown the call
(as
opposed to the management system). Any thoughts on how this might be done would be
appreciated.
?? There is confusion if a Router ID must be the same value as a reachable IPv4 address on
an LSR.
RFC 2328 defines Router ID as:
"A 32-bit number assigned to each router running the OSPF protocol."
It is further clarified in footnote 9 that a Router ID is not an IP address. It
specifically states:
"The address space of IP networks and the address space of OSPF Router IDs may
overlap."
RFC 3477 defines Router ID as:
". a stable IP address of an LSR that is always reachable if there is any connectivity to
the LSR."
It goes on to state:
"If one is using the OSPF or ISIS as the IGP in support of traffic engineering, then it is
RECOMMENDED for the Router ID to be set to the "Router Address" as defined in
[OSPF-TE], or "Traffic Engineering Router ID" as defined in [ISIS-TE]."
Unfortunately, it is not clear if the usage of Router ID here is referencing the OSPF
Router ID or
the Router ID as defined by RFC 3477. Clarification is requested.
Maintaining the independence between OSPF's Router ID, and the IP addresses used on a LSR
is
a powerful and necessary capability as it allows for the renumbering of links without
causing the
revocation of the OSPF Router ID being used by an LSR and the resulting flushing and
regeneration of all locally originated LSAs describing attached broadcast networks and
links.
Requiring the Router ID to be a reachable IP address on the LSR results in an unnecessary
behavior that causes significant churn in the LSDB, and potential disruption of TE-route
calculation, when renumbering is done.
. MPLS-TE does not allow for nodes that are not participating in OSPF to be advertised.
When an MPLS-TE LER relies on another node, such as a path computation server, to perform
route calculation on its behalf, it is unnecessary for the LER to participate in OSPF.
However,
since the LER is not participating in OSPF, it has no way to advertise where it appears in
the
network. Consequently, ingress LERs will not be able to calculate routes to this egress
LSR. A
mechanism to advertise reachability of non-OSPF participating LERs needs to be developed.
We also recommend the following item be considered by the ASON routing solutions design
team:
. The ASON routing architecture allows for the abstraction of information when
hierarchical
routing is utilized. This abstraction is handled by a transformation function that exists
between
the Child Area and the Parent Area. The amount of transformation of routing information
performed can be described as a continuum with the following extremes:
. Let all link and node information through with no changes
. Abstract all link and node information provided by the Child Area into a single node.
(This was successfully tested in the recent demo.)
Other approaches exist on this continuum, but may be complex to define. Consequently, we
believe these approaches may be best left as vendor specific approaches.
Sincerely yours,
Steve Joiner
OIF, Technical Committee Chair
cc: Jim Jones, John McDonough