|
Re: Last Call: <draft-ietf-ccamp-rfc5787bis-05.txt>
2012-08-22 12:11:54
Stephen,
To add to what Adrian said, the 1:1 mapping is only for node
identifiers, interface identifiers have no such restriction. I think
it's reasonable to add some informative text to the draft on this point
as it may help avoid such confusion in the future.
Lou
On 8/22/2012 1:01 PM, Adrian Farrel wrote:
Hi Stephen,
No, there is no requirement for the control plane topology to match the
data plane topology in GMPLS. There is simply a 1:1 mapping between
identifiers. We might note, however, that there is a virtual overlay in
the SCN such that protocol controllers that control devices that are
adjacent in the data plane can be made virtually adjacent in the control
plane.
Your final assumption is how an operator might manage their network. But
it is not a requirement since mappings can always be made at domain
boundaries.
Adrian
*From:* Shew, Stephen [mailto:sshew(_at_)ciena(_dot_)com]
*Sent:* 22 August 2012 17:35
*To:* Acee Lindem; Ong, Lyndon
*Cc:* ietf(_at_)ietf(_dot_)org;
draft-ietf-ccamp-rfc5787bis(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org;
Andrew G. (Andy) Malis
*Subject:* RE: Last Call: <draft-ietf-ccamp-rfc5787bis-05.txt>
Thanks for the reply. If I understand correctly, this means that the SCN
topology must match the transport topology when applying OSPF for ASON
routing. This is because the Local TE Router Identifier and the Remote
TE Router Identifier in the Local and Remote TE Router ID sub-TLV are
the same as the TE Router ID in the TE Router Address TLV. If this is
correct, then I think the draft should state the assumption that the SCN
topology and transport plane topology are aligned. It’s an important
assumption to state since management systems of SDH/OTN networks have
topologies of the transport network in non-IP address formats (esp. TL-1
TIDs) and these need to be mapped to TE Router IDs in the SCN space when
this draft is applied. I assume it implies that there should be a
single SCN or non-overlapping IP address spaces if there are multiple
SCNs, for a given transport topology otherwise the SCN topology
representing the transport topology could have duplicate identifier values.
Stephen
*From:* Acee Lindem [mailto:acee(_dot_)lindem(_at_)ericsson(_dot_)com]
*Sent:* 21 August, 2012 17:23
*To:* Ong, Lyndon
*Cc:* ietf(_at_)ietf(_dot_)org; Shew, Stephen;
draft-ietf-ccamp-rfc5787bis(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org; Andrew
G. (Andy) Malis
*Subject:* Re: Last Call: <draft-ietf-ccamp-rfc5787bis-05.txt>
Hi Stephen, Lyndon,
Andy and I have had discussions with the CCAMP chairs and AD. We have
come to the conclusion that we cannot merely change the name space for
the advertised TE Router ID since this would imply a change to the GMPL
model for setting up LSPs. In GMPL, the LSP endpoints are in the
Signaling Control Network (SCN) and this cannot be changed without a
distinct model for ASON LSP establishment complete with the
specification of the changes to path computation, RSVP path signaling,
and RSVP Explicit Route Object (ERO) handling. In essence, this change
would add a level of indirection from the SNPP to the SCN. In the
context of this draft, we are not going to deviate from the GMPLS LSP
model and, hence, will not incorporating the suggested changes.
Thanks,
Acee
On Aug 17, 2012, at 7:58 PM, Ong, Lyndon wrote:
(Submitted on behalf of Stephen Shew)
I would like to raise an issue with draft-ietf-ccamp-rfc5787bis-05.txt.
The issue does not affect the proposed sub-TLVs or their semantics, so
it would not affect an implementation. I believe some statements in the
document should be edited to avoid confusion over ASON terminology as
defined in ITU-T Recommendation G.8080, for which I am editor.
It concerns the definition of “ASON reachability” which changed during
the course of the document from being a transport plane address, the
SubNetwork Point Pool (SNPP) space, to the Signalling Control Network
(SCN) address space. I think the root of the issue is that the
visibility of the three address spaces described in ASON (G.8080) is not
always made clear when discussing using OSPF for ASON Routing. Section
3 of G.8080 states that:
There are three categories of identifiers used for ASON routing
(G7715.1): transport plane names, control plane identifiers for
components, and Signaling Communications Network (SCN) addresses.
In -03 of the document, the term SNPP was used. This is the SubNetwork
Point Pool space that describes the data plane and is defined in G.8080
Section 10. It names the subnetwork (and/or containing subnetworks) to
which Subnetwork Points (SNPs) are scoped. From G.8081: “The SNP is an
abstraction that represents an actual or potential underlying connection
point (CP) (or connection termination point (CTP)) or an actual or
potential termination connection point (TCP) or trail termination point
(TTP). Several SNPs (in different subnetwork partitions) may represent
the same TCP or CP."
In concrete terms, an SNPP would name an OTN switch, and an SNP would be
a label identifying an ODU0. For the topology of the transport plane,
SNPP and SNPP link names are used. Path computation is performed over
such a topology. If a path can be computed between two SNPPs, they are
reachable in ASON terms. For example, and ingress OTN switch for an ODU1
connection that terminates on an egress OTN switch.
The Signalling Control Network (SCN) is a separate network over which
control messages are sent. It has a topology independent of the
transport plane. Path computation on the SCN address space is used to
connect SCN address. SDH/OTN networks often have a separate IP network
as the SCN network and the topology of the SCN network does not have to
follow the topology of the transport network.
ASON Control Plane Component identifiers are the third name space and
identify routing and signalling instances. It is expected that they
form adjacencies over the SCN. The topology of the adjacencies is
independent of the SCN and transport plane topologies. “Reachability”
between two control plane components would be some sequence of
adjacencies. It is entirely possible to have two separate control
planes running over the same SCN network, or one control plane that uses
several SCNs. For example, imagine some OSPF instances whose
adjacencies were all targeted and each adjacency traversed a separate
private IP network. The OSPF instances would need to identified by a
common address space so that they are distinguished from each other, but
the TE interfaces could have overlapping IPv4 values because they would
be in different private IP network spaces.
What makes the discussion of “TE router ID” confusing is that as applied
to a transport network, every node gets a “TE router ID” and so it can
be used in the transport topology for path computation. In that sense
it is “reachable” in the dataplane. However, it is also (I think) an
address that is implicitly in the SCN space in some implementations and
so it takes on a dual meaning of “reachability” at the IP layer as in
the sentence from the I-D “This TLV specifies a stable OSPF TE node IP
address, i.e., the IP address is always reachable when there is IP
connectivity to the associated OSPF TE node.”. If a router were
instantiated without any routing protocols, as in one form of Software
Defined Networks (SDNs), an identifier would be needed for the node
itself so that path computation in a centralized controller could form
the router data plane topology.
Suggested changes to the draft are:
In section 3, third paragraph: "In the context of OSPF Traffic
Engineering (TE), an ASON transport node corresponds to a unique OSPF TE
node. An OSPF TE node is uniquely identified by the TE Router Address
TLV [RFC3630]. In this document, this TE Router Address is referred to
as the TE Router ID, which is in the ASON SCN name space." However,
G.8080 distinguishes between the transport node and its associated
control plane components, esp. the Routing Controller. It is the
control plane component that is accessed through the SCN rather than the
transport node itself.
I propose changing the statement to say: "In this document, this TE
Router Address is referred to as the TE Router ID, which is in the ASON
SNPP name space.”
Alternatively, we could just delete the sentence “In this document, this
TE Router Address is referred to as the TE Router ID, which is in the
ASON SNPP name space.”.
In section 4, first paragraph, reachability of endpoints in the
transport plane is described as follows:
"In ASON, reachability refers to the set of endpoints reachable in the
transport plane by an associated ASON transport node. Reachable
entities are identified in the ASON SCN name space." As discussed
above, only the control plane components are accessed through the SCN,
not the transport nodes themselves. Entities that are reachable in the
transport plane are identified through ASON SNPPs rather than ASON SCN
addresses. Therefore I suggest removing the second sentence completely
so that it reads simply "In ASON, reachability refers to the set of
endpoints reachable in the transport plane by an associated ASON
transport node. “
Finally, in section 6.2, first paragraph following the format diagram,
it is stated: "If it is not included in a Node Attribute TLV or a value
of 0 is specified for the Local TE Router Identifier, the Note Attribute
TLV will not be used for determining ASON SCN reachability."
Again, the text should be edited to make the distinction between
transport plane and SCN clearer, I suggest modifying the statement to
refer to "ASON reachability" rather than "ASON SCN reachability". The
statement would read as follows (also correcting the spelling of the TLV):
"If it is not included in a Node Attribute TLV or a value of 0 is
specified for the Local TE Router Identifier, the Node Attribute TLV
will not be used for determining ASON reachability."
Stephen Shew
-----Original Message-----
From: ietf-announce-bounces(_at_)ietf(_dot_)org
<mailto:ietf-announce-bounces(_at_)ietf(_dot_)org>
[mailto:ietf-announce-bounces(_at_)ietf(_dot_)org]
On Behalf Of The IESG
Sent: Friday, July 20, 2012 11:19 AM
To: IETF-Announce
Cc: ccamp(_at_)ietf(_dot_)org <mailto:ccamp(_at_)ietf(_dot_)org>
Subject: Last Call: <draft-ietf-ccamp-rfc5787bis-05.txt> (ASON Routing
for OSPFv2 Protocols) to Proposed Standard
The IESG has received a request from the Common Control and Measurement
Plane WG (ccamp) to consider the following document:
- 'ASON Routing for OSPFv2 Protocols'
<draft-ietf-ccamp-rfc5787bis-05.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to
the ietf(_at_)ietf(_dot_)org <mailto:ietf(_at_)ietf(_dot_)org> mailing lists
by 2012-08-17.
Exceptionally, comments may be sent to iesg(_at_)ietf(_dot_)org
<mailto:iesg(_at_)ietf(_dot_)org> instead. In either case, please retain the
beginning of the Subject line to allow automated sorting. This is a
four- week last call period because it spans the IETF-84 meeting.
Abstract
The ITU-T has defined an architecture and requirements for operating
an Automatically Switched Optical Network (ASON).
The Generalized Multiprotocol Label Switching (GMPLS) protocol suite
is designed to provide a control plane for a range of network
technologies including optical networks such as time division
multiplexing (TDM) networks including SONET/SDH and Optical Transport
Networks (OTNs), and lambda switching optical networks.
The requirements for GMPLS routing to satisfy the requirements of
ASON routing, and an evaluation of existing GMPLS routing protocols
are provided in other documents. This document defines extensions to
the OSPFv2 Link State Routing Protocol to meet the requirements for
routing in an ASON.
Note that this work is scoped to the requirements and evaluation
expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations
current when those documents were written. Future extensions of
revisions of this work may be necessary if the ITU-T Recommendations
are revised or if new requirements are introduced into a revision of
RFC 4258. This document obsoletes RFC 5787 and updates RFC 5786.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ccamp-rfc5787bis/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ccamp-rfc5787bis/ballot/
No IPR declarations have been submitted directly on this I-D.
*Stephen Shew* | Director, Standards
sshew(_at_)ciena(_dot_)com <mailto:jdoe(_at_)ciena(_dot_)com> | 3500 Carling
Ave. | Ottawa
CANADA K2H 8E9
Direct +1.613.670.3211
|
|