RE: Communication from the OIF

["Brungard, Deborah A, ALABS" <dbrungard@att.com>]

Lyndon,

As you say, it is not for CCAMP to comment on OIF's definition of
"basis" in regards to ITU Recommendations. 

Your comment triggered another item which we should include - we still
have not received any response from OIF on CCAMP's previous liaison
(March) regarding OIF's intentions with their OSPF work. I suggest we
add the following:

-  request (again) clarification on the intention of their OSPF
development work/demo, and voice concern that CCAMP's proposed wording
to clarify as experimental was not in the OIF press releases.

And the following:
- repeat our previously liaisoned concerns to ITU (Dec, 2003) on G7713.2
defining GMPLS-redundant objects and mechanisms. As OIF's demo
identified issues with G7713.2 (SPC, lack of crankback support), CCAMP
requests OIF to work with ITU towards alignment of G7713.2 with GMPLS
standard mechanisms vs. further divergence.
- in the interests of future cooperation, encourage OIF to timely
communicate questions/concerns regarding IETF protocols, e.g. prior to
OIF protocol development/demos.

Regards,
Deborah

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Ong, Lyndon
Sent: Wednesday, September 01, 2004 12:46 PM
To: 'dpapadimitriou@psg.com'; 'dimitri.papadimitriou@alcatel.be'
Cc: 'John Drake'; Adrian Farrel; ccamp@ops.ietf.org
Subject: RE: Communication from the OIF

Hi Dimitri,

I'm glad that we seem to be moving in a productive direction.
This is probably not the right venue to discuss alignment
between the OIF and ITU, we can discuss further offline 
if you have concerns with some of the options chosen in the
OIF IA, and I can provide further input on any differences
within the routing solutions design team.  

I would note that the ITU itself was supportive of the interoperability
test and provided material for the OIF booth at the Supercomm show. 

Cheers,

Lyndon 

-----Original Message-----
From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com]
Sent: Wednesday, September 01, 2004 1:30 AM
To: Ong, Lyndon
Cc: 'dimitri.papadimitriou@alcatel.be'; 'John Drake'; Adrian Farrel;
ccamp@ops.ietf.org
Subject: Re: Communication from the OIF


hi lyndon,

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

thanks for the pointers, this said, and more specifically, it seems that

(after a first look on the "RSVP oriented part" of the above mentioned 
document) that it provides a specific ERO profile (section 11.3.2) that 
is not specifically addressed in G.7713.2, in particular,
- the mandatory usage of strict routes for multi-domain environments as
   mandated in the OIF E-NNI document (no support of L bit so how an ERO
   subobject sequence can be inserted ?)
- the mandatory identification of ERO subobjects from the upstream
   outgoing (and not the incoming downstream) perspective ?
- "Usage of subobjects of type 1, 2 and 32 defined in [RFC3209] in
   transport networks are not supported and are for further study."
(type
   1 and 2 are the numbered interface codepoints) but on the other side
   TNA (defined as Transport Network addresses) supports both IPv4 and
   IPv6 so is there not somehow a contradiction here ?

the same for section 11.3.5 (on RSVP_HOP object), additionally (in 
section 11.3.3) relationship between GENERALIZED_UNI object fields usage

for call identification purposes and CALL_ID object definition in 
G.7713.2 is unclear

so, it seems that these constitute potential discrepencancies that puts 
the above "close alignment" statement under questioning

> 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, but i start to wonder about the verbage here "similar" , 
"closely aligned" , "based on" , etc. i mean are these definitions 
(strictly) identical (or not) ? such information will help the WG in 
further aligning its GMPLS/ASON efforts as part of the present exchanges

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

with a TE metric set to 0xffffffff (to be complete) so need for specific
for additional flags of any sort if OIF IAs are seeking to avoid any LSP
establishment through the incriminated node(s)

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

agreed, this constitutes (at least) a good basis for initiating 
discussion on reachability

thanks,
- dimitri.

> Cheers,
> 
> Lyndon
> 
> -----Original Message-----
> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com]
> Sent: Tuesday, August 31, 2004 11:08 AM
> To: Ong, Lyndon; 'John Drake'
> Cc: Dimitri.Papadimitriou@alcatel.be; Adrian Farrel;
ccamp@ops.ietf.org
> Subject: Re: Communication from the OIF
> 
> 
> 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 
> 
>>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-frame
work-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-extensi
ons-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)
> 
> 
>>Cheers,
>>
>>Lyndon
>>
>>
>>
>>-----Original Message-----
>>From: John Drake [mailto:jdrake@calient.net]
>>Sent: Tuesday, August 31, 2004 8:22 AM
>>To: Dimitri.Papadimitriou@alcatel.be; Adrian Farrel
>>Cc: ccamp@ops.ietf.org
>>Subject: RE: Communication from the OIF
>>
>>
>>Dimitri,
>>
>>Excellent note.  You saved me a lot of typing.
>>
>>John
>>
>>
>>
>>>-----Original Message-----
>>>From: Dimitri.Papadimitriou@alcatel.be
>>>[mailto:Dimitri.Papadimitriou@alcatel.be]
>>>Sent: Monday, August 30, 2004 11:32 AM
>>>To: Adrian Farrel
>>>Cc: ccamp@ops.ietf.org
>>>Subject: Re: Communication from the OIF
>>>
>>>
>>>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
>>>
>>
>>
>>.
>>
> 
> 
> .
>