[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Communication from the OIF
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: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-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)
> 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
>>
>
>
>
> .
>