Response to OIF Communication dated 11th August 2004

["Adrian Farrel" <adrian@olddog.co.uk>]

To: Steve Joiner, OIF Steve Joiner OIF, Technical Committee Chair
cc: Jim Jones, John McDonough
     Alex Zinin, Bill Fenner
From: Adrian Farrel and Kireeti Kompella, IETF CCAMP Working Group co-chairs

Response to OIF Communication dated 11th August 2004

Dear Steve,
Thank you for your communication to the IETF CCAMP Working Group. It is good to have
continued dialog.

Your communication described the OIF Interoperability held at Supercomm 2004 and included
the text "This demo included the ASON compliant OIF UNI and ENNI Implementation
Agreements."

This statement caused some discussion on the CCAMP WG mailing list with respect to the
"ASON compliance" of the OIF implementation agreements (OIF UNI and E-NNI). We would
welcome some clarification of this point.

Your description of the interoperability testing certainly sounds impressive. It includes
reference to "ENNI routing - link state inter-domain routing". In view of the current
joint routing solution activity between the IETF, ITU-T and OIF, it would be helpful to
expand on the OIF's definition of "domain" in order to:
1) understand the scope of the this testing item
2) ensure that all three bodies have a shared view of a domain.

You helpfully list some of the operational observations made during the testing. A couple
of these are worthy of some additional comments. You say...

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

It is worth noting that the same functionality is already available in GMPLS.
GMPLS-OVERLAY (http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-04.txt)
can be applied with the SENDER_TEMPLATE's Tunnel Sender Address field set (by the ingress
node) to the address of one of its numbered TE links and the 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 made between the corresponding
interfaces. This technique can then be combined with the procedures described in sections
5.1.1 and 5.1.2 of RFC 3473 (explicit label control).

Note that explicit label control for egress cases has been clarified in a specific draft
(http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-egress-control-02.txt) that is
currently going through IETF last call.

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

For your information, draft-ietf-ccamp-gmpls-sonet-sdh-08.txt has completed the IETF
process, but is held in the RFC Editor queue waiting for a referenced draft to be
completed. The 08 revision can be considered as stable.

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

Section 2 ("Implications on Graceful Restart") of
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-12.txt
describes procedures that are suitable for handling this situation and we would recommend
that they are applied.

We would also recommended that you apply the RSVP-TE restart procedures detailed in RFC
3473 Section 9 upon loss of signaling adjacency.

Your note also goes on to request specific guidance from CCAMP on a couple of issues.

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

Section 6 of RFC 3471 and Section 5 of RFC 3473 describe techniques that can be used to
splice LSP segments together. This might be used, for example, to splice an SC to a PC at
the egress segment when creating an SPC.

The same technique can be used to splice the new SC state (replacing the old PC state) to
the existing SC state.

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

RFC 3477 contains an unfortunate redefinition of the term Router ID.
In attempt to clarify this, RFC 3477 explicitly states:
   In the context of this document the term "Router ID" means a stable
   IP address of an LSR that is always reachable if there is any
   connectivity to the LSR.
Thus all uses of "Router ID" in RFC 3477 refer to this definition and specifically to the
usage of Router ID made in the document for signaling unnumbered links in RSVP-TE. In
fact, except where qualified as the "Traffic Engineering Router ID as defined in
[ISIS-TE]" the phrase "Router ID" could be equally expressed in this RFC as "LSR's Router
ID" as carried in the LSP_TUNNEL_INTERFACE_ID Object described in section 3.1.

Thus, the Router ID referred to in this document is most certainly not the OSPF Router ID.
In fact, this is why the RFC suggests that the (LSR's) Router ID should be set to the
"Router Address as defined in [OSPF-TE]". Certainly this RFC does not (and could not) vary
the definition of the OSPF Router ID that you quote from RFC 2328.

We believe that this clarification preserves the independence between the OSPF Router ID
and the IP addresses used on an LSR. This is, as you state a key feature of MPLS and GMPLS
systems.

Note that the footnote from RFC2328 that you cite 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 (see section 5 of RFC 2328).

Note further that in the event that the OSPF Router ID is borrowed from the local IP
addressing space and set equal to one of the local reachable IP addresses (such as a
loopback address) renumbering of the local interfaces does NOT require that OSPF Router ID
is revoked. The same OSPF Router ID can persist since it does not matter that it no longer
matches any local IP address.

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

As mentioned above, renumbering a TE link, either numbered or unnumbered, does not require
that the OSPF Router ID be changed regardless of what it was originally set equal to. 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.

This form of proxy advertisement of reachability can be achieved using the techniques
described in http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-01.txt.

The OIF assignment of "client addresses" can be made and these can be advertised from the
network (edges) as reachable addresses. This is just an application of this OSPF WG
document (not 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.

Thank you for this input. It has been passed to the ASON RSDT for their consideration.


As a final comment, can we point out that GMPLS as defined by the GMPLS Architecture
(http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-architecture-07.txt) and the
Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description
(RFC3471) and realised for RSVP-TE in RFC3473 supports the full spectrum of switching
types including PSC, L2SC, TDM, LSC and FSC. Can you confirm whether the OIF IAs currently
support anything other than TDM and whether there are plans to extend the tests and demos
to support and verify other switching capabilities before the IAs are fully ratified?

Sincerely,
Adrian Farrel and Kireeti Kompella.