-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Monday, August 30, 2004 11:32 AM
To: Adrian Farrel
Cc: ccamp@ops.ietf.org
Subject: Re: Communication from the OIF
hi adrian, all, see in-line
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.
if i well understand the above statement, is this implicitly meaning that
OIF developments are architecturally compliant with ASON (G.8080) but not
(necessarily) compliant with the G.7713.2 specification ? as OIF maintains
its own 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.
were SCs requests also tested across/traversing OIF E-NNI IA based
interfaces ?
?? SC to SPC calls - a UNI client with a call to an SPC client (and
vice-versa)
?? ENNI routing - link state inter-domain routing
it would be of interest to have the OIF definition of "domain" in order to
understand the relationship of the above test with the current IETF CCAMP
efforts and related
?? Call using OC-3c and VC-4 links for an STS-3c equivalent
connection. This used the common signal type of 6.
as an aside question were both setup and teardown requests tested in the
above interoperability tests ?
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.
use of GMPLS-OVERLAY with a SENDER_TEMPLATE set by the ingress node to
the address of one of its numbered TE links and a SESSION_OBJECT set by
the ingress node to the address of one of the egress' numbered TE links
such that the connection is only be made between the corr. interfaces,
in combination with procedure described in section 5.1.1 and 5.1.2 of
RFC 3473 (explicit label control) provides for the same functionality
?? 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.
this document is in the RFC Editor and hangs on a cyclic reference to
the GMPLS architecture document
?? 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.
why operation described in section 2 (Section 2. Implications on Graceful
Restart) of GMPLS-OSPF is not applied in this case ?
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.
use of the splicing operation with the already established SPC (using the
method described in section 6 of RFC 3471 and section 5 of RFC 3473)
should
deliver the expected functionality
?? 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.
there are two statements in the above:
1. is the RFC 3477 Router_ID (or not) the OSPF Router_ID ?
-> looking at the resp. definitions, the former is an address
("typically implemented as a "loopback address") and the latter is
a 32 bit number that may make use of local IP address values
2. is RFC 3477 recommended behavior: RFC 3477 Router_ID <- (OSPF-TE)
Router_Address/(IS-IS) TE Router_ID
so in both cases (as determined by 1.) what precludes rule 2 to be applied
in OIF IAs ? i should point out that above mentioned footnote does only
points out that "a network may have an IP address which is identical (when
considered as a 32-bit number) to some router's Router ID." it does not
say
that the router_ID can not borrow its 32 bit number value from local IP
addressing space (section 5 of RFC 2328) - it is thus important to avoid
(in any case) the inferrence that RFC 3477 mandates that the OSPF
Router_ID
to be both syntaxically and semantically an "IP address"
it is also unclear why OIF renumbering IAs require change of any Router_ID
in addition to the renumbering of the local/remote interface_id (for
unnumbered link) ? if this is the case - why so ?
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.
see above
. 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.
there is somehow an ambuiguity in this question, using the following
<draft-ietf-ospf-te-node-addr-01.txt> one could proxify this
reachability, but i don't see how the ingress LSR (client ?) could make
use of this information since ingress and egress LSR are simply nodes
not participating on the OSPF instance ?
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.)
-> i'll pass the above information to the ASON RSDT
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