Subject: Communication from the OIF

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 28 Aug 2004 12:51:34 +0100

All,

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, [email-masked], IETF, CCAMP Working Group Chair
Mr. Kireeti Kompella, [email-masked], IETF, CCAMP Working Group Chair
Mr. Alex Zinin, [email-masked], IETF, Routing Area Director
Mr. Bill Fenner, [email-masked], 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.
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
?? 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.
?? 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.
?? 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.
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.
?? 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.
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.
. 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.
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.
Sincerely yours,
Steve Joiner
OIF, Technical Committee Chair
cc: Jim Jones, John McDonough

---

From: "Ong, Lyndon" <[email-masked]>
Date: Mon, 30 Aug 2004 11:09:48 -0700

Hi Adrian, Folks,

Just wanted to note that the OIF is very interested in reestablishing
relationships with the IETF and CCAMP.  This topic came up at the last
OIF meeting and a number of the participants expressed support and
urged that this be done soon.  There is already a regular slot in
the OIF agenda for reporting on new developments in the IETF that 
may be of interest.  I have also asked the OIF Secretariat to look
into mechanisms that would allow OIF draft documents to be accessible
to IETF members, if a liaison is sent asking for their review.

This particular liaison was sent following interoperability testing
done at OIF member labs prior to and leading up to the 2004
Supercomm show.  OIF would be very interested in comments on the
testing results and hope that the results will be helpful to IETF.

Cheers,

Lyndon Ong
(currently IETF liaison representative in the OIF)

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Saturday, August 28, 2004 4:52 AM
To: [email-masked]
Subject: Communication from the OIF

All,

Adrian

====
August 11, 2004

---

From: [email-masked]
Date: Mon, 30 Aug 2004 20:31:36 +0200

hi adrian, all, see in-line

> 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, [email-masked], IETF,
> CCAMP Working Group Chair Mr. Kireeti Kompella, [email-masked],
> IETF, CCAMP Working Group Chair Mr. Alex Zinin, [email-masked], IETF,
> Routing Area Director Mr. Bill Fenner, [email-masked], 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:
> ?? 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 ?

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

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

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

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

---

From: John Drake <[email-masked]>
Date: Tue, 31 Aug 2004 08:21:48 -0700

Dimitri,

Excellent note.  You saved me a lot of typing.

John

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Monday, August 30, 2004 11:32 AM
> To: Adrian Farrel
> Cc: [email-masked]
> Subject: Re: Communication from the OIF
> 
>

---

From: John Drake <[email-masked]>
Date: Tue, 31 Aug 2004 12:19:58 -0700

Snipped

> From: dimitri papadimitriou [mailto:[email-masked]]
> Sent: Tuesday, August 31, 2004 11:08 AM
> To: Ong, Lyndon; John Drake
> Cc: [email-masked]; Adrian Farrel; [email-masked]
> hi lyndon, john, all,
> > Looks like you two would be great candidates for writing
> > the liaison reply!
> 
> ok - we (if john agrees) will collect input and suggest a first response
> to the list
> 
[John Drake] 

Fine with me

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 31 Aug 2004 13:40:11 -0700

Hi Dimitri,

More on the testing and the E-NNI:

-- the testing used the OIF Intra-Carrier E-NNI implementation agreement
(http://www.oiforum.com/public/documents/OIF-E-NNI-Sig-01.0-rev1.pdf) 
RSVP signaling, but this is closely aligned with G.7713.2, there
are no additional protocol elements incorporated beyond G.7713.2.  The
testing also involved, as you mention, the OIF UNI 1.0 rel2 agreement
(http://www.oiforum.com/public/documents/OIF-UNI-01.0-R2-RSVP.pdf) at
the UNI.

-- there is a description of control domain in the E-NNI Introduction section,
reading
"A control domain is an architectural construct that provides for encapsulation and
information hiding, and the characteristics of the control domain are the same as
those of its constituent set of distributed architectural components."
It is similar to the description in G.8080 Amendment 1 for ASON.

-- thanks for the clarification on the GMPLS-OSPF reference, missed it the
first time around.  Is the gist of your suggestion that the link should be
advertised with 0 reservable capacity in the case identified in the liaison?

-- if this use of draft-ietf-ospf-te-node-addr-01.txt is acceptable, it
might be a way forward on the reachability concern.  We could discuss this
further in the routing solutions design team.

Cheers,

Lyndon

-----Original Message-----
From: dimitri papadimitriou [mailto:[email-masked]]
Sent: Tuesday, August 31, 2004 11:08 AM
To: Ong, Lyndon; 'John Drake'
Cc: [email-masked]; Adrian Farrel; [email-masked]
Subject: Re: Communication from the OIF

hi lyndon, john, all,

> Some responses to Dimitri's questions:

thanks - see below for some additional input/question/comments:

> -- the architecture was intended to be consistent with ASON and the
> testing was focused on E-NNI and UNI interfaces, the signaling protocol
> at the E-NNI used G.7713.2 procedures (e.g., multiple RSVP sessions)

to get a closure on this the demo included the OIF UNI IA (?) and the 
ITU-T G.7713.2 E-NNI being (meaning that the OIF E-NNI IA was not tested 
?) so, if this assumption is correct there are two major implications no 
call functionality was part of the demo (seems to be confirmed by the 
below response) and all OIF E-NNI IA specifics that are not part of 
G.7713.2 were also not demo'ed - would you please confirm/clarify ?

> -- switched connections were set up across E-NNI boundaries
> 
> -- I'll check on the exact definition of domain, where would you find 
> the best definition in the IETF context?

just to clarify the question was referring to the OIF definition of 
"domain" in order to understand the scope of the "OIF E-NNI routing - 
link state inter-domain routing" demo item

now, a good pointer for a domain definition in the "IETF context" is 
probably the one provided in:

<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-00.txt>

"[...] a domain is considered to be any collection of network elements 
within a common sphere of address management or path computational 
responsibility. Examples of such domains include IGP areas and 
Autonomous Systems. However, domains of computational responsibility may 
also exist as sub-domains of areas or ASs. Wholly or partially 
overlapping domains are not within the scope of this document."

> -- both set up and tear down of connections was tested
> 
> -- the issue mentioned with SUKLM was not a comment against the current
> IETF drafts, just a note that some implementors had not kept up with 
> the changes in the drafts from a year or two back to merge SONET and SDH

as mentioned, the v08.txt document is in the RFC Editor queue (to be 
clarified in the response)

> -- Dimitri, you mention a Section 2 (Graceful Restart) of GMPLS-OSPF
> but I can't find this in draft-ccamp-ospf-gmpls-extensions-12.txt, can
> you clarify the reference?

i meant "Section 2. Implications on Graceful Restart" of
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-12.txt>

> -- you also mention draft-ietf-ospf-te-node-addr-01.txt as a possible
> method of advertising reachability to a non-OSPF LER, but the draft 
> appears to be designed for a router to advertise its own local addresses,
> can this be used to advertise reachable addresses as well?

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 i-d (not even an extension) as the pool of "client addresses" is 
in fact owned by the network (edges)

> Lyndon
> From: John Drake [mailto:[email-masked]]
> Sent: Tuesday, August 31, 2004 8:22 AM
> To: [email-masked]; Adrian Farrel
> Cc: [email-masked]
> Subject: RE: Communication from the OIF
> 
> 
> Dimitri,
> 
> .