response to the OIF communication

[dimitri papadimitriou <dpapadimitriou@psg.com>]

folks, as discussed earlier on this list, find in attachment a 
compilation of the answers to be sent in response to the OIF communication:

---

<common header>

<common intro>

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.

R: The above statement raised some discussion on the CCAMP WG mailing
list with respect to the "ASON compliance" of the OIF implementation
agreements (OIF UNI and E-NNI). So, any clarification to the meaning of
"ASON compliance" would be more than appreciated.

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

R: It would be of interest to have the accurate OIF definition of
"domain" in order to understand:
1) the scope of the "OIF E-NNI routing - link state inter-domain
   routing" demo item
2) and 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.

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.

R: application of GMPLS-OVERLAY(*) method with a SENDER_TEMPLATE's
Tunnel Sender Address field set (by the ingress node) to the address of
one of its numbered TE links and a SESSION_OBJECT's Tunnel End-point
Address field 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 corresponding interfaces, in combination with the procedures
described in section 5.1.1 and 5.1.2 of RFC 3473 (explicit label
control) provides for the same functionality

(*) see:
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-04.txt>

- 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.

R: SUKLM interpretation and encoding is detailed in the v08.txt of this
document that hangs in the RFC Editor queue due to 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.

R: why the method described in Section 2 (entitled Implications on
Graceful Restart) of the following document is not applied in this case. 
For more details, we refer you to:

<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-12.txt> 


Note: it is also recommended to apply the RSVP-TE restart procedure 
(detailed in RFC 3473 Section 9) upon loss of signaling adjacency

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.

R: use of the splicing operation with the already established SPC (using
the method described in Ssection 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.

R: there are two statements in the above:

1. "is the RFC 3477 Router_ID (or not) the OSPF Router_ID ?"
   so, looking at the respective 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 ?

Note: it should be also pointed 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.

R: as mentioned above, renumbering a TE link, either numbered or 
unnumbered, does not require that the router ID be changed. The 
identifier for a numbered TE link is globally unique, and renumbering 
would require the assignment of another globally unique identifier. The 
identifier for an unnumbered TE link is nodally unique, and renumbering 
would require the assignment of another nodally unique identifier.

- 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.

R: using the following OSPF WG doc <draft-ietf-ospf-te-node-addr-01.txt> 
one can proxify this reachability information.

The method described in this document can be used to advertise reachable 
addresses as OIF devised assignment of "client addresses" from the 
network (edges). So, one can assume these local addresses can follow the 
same procedure defined in the above referenced document. This is just an 
application of this OSPF WG document (not even an extension) as the pool 
of "client addresses" is in fact owned by the network (edges).

  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.

R: The above information will be sent to the ASON RSDT for their
consideration

We would like also to point out that GMPLS per GMPLS-ARCH and RFC 3471
supports not only TDM but also PSC, L2SC, LSC and FSC switching type
whereas OIF IAs currently only supports TDM switching.

  Sincerely yours, Steve Joiner OIF, Technical Committee Chair cc: Jim
  Jones, John McDonough

<common footer>

-----