Re: Communication from the OIF

[Dimitri.Papadimitriou@alcatel.be]

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