Subject: response to the OIF communication

From: dimitri papadimitriou <[email-masked]>
Date: Tue, 21 Sep 2004 09:32:59 +0200

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>

-----

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 23 Sep 2004 01:54:09 +0100

Thanks to Dimitri and John for driving this.

Below please find a proposed email to Steve Joiner, chair of the OIF technical committee.

Comment please. I would like to resolve this and send it on 30th September.

Thanks,
Adrian

==========

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

>    the name of the egress network element would not necessarily be

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.

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

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

>    management system). Any thoughts on how this might be done would be

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.

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

>    the LSDB, and potential disruption of TE-route calculation, when

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.

>    mechanism to advertise reachability of non-OSPF participating LERs

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

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

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.

---

From: dimitri papadimitriou <[email-masked]>
Date: Sat, 25 Sep 2004 11:44:17 +0200

hi adrian, i think the below is translating most (if not all) of what we 
can provide to address the oif tc communication,

thanks for the formatting and additional phrasing that complete this 
response

- dimitri.

ps: edit
< To: Steve Joiner, OIF Steve Joiner OIF, Technical Committee Chair
 > To: Steve Joiner OIF, Technical Committee Chair

---

Adrian Farrel wrote:

> .