RE: Communication from the OIF

["Ong, Lyndon" <LyOng@Ciena.com>]

Hi Guys,

Looks like you two would be great candidates for writing
the liaison reply!

Some responses to Dimitri's questions:

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

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

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

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

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

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
>