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@xxxxxxxxx] > *Sent:* 22 August 2012 17:35 > *To:* Acee Lindem; Ong, Lyndon > *Cc:* ietf@xxxxxxxx; draft-ietf-ccamp-rfc5787bis.all@xxxxxxxxxxxxxx; > 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.lindem@xxxxxxxxxxxx] > *Sent:* 21 August, 2012 17:23 > *To:* Ong, Lyndon > *Cc:* ietf@xxxxxxxx; Shew, Stephen; > draft-ietf-ccamp-rfc5787bis.all@xxxxxxxxxxxxxx; 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@xxxxxxxx > <mailto:ietf-announce-bounces@xxxxxxxx> [mailto:ietf-announce-bounces@xxxxxxxx] > On Behalf Of The IESG > > Sent: Friday, July 20, 2012 11:19 AM > > To: IETF-Announce > > Cc: ccamp@xxxxxxxx <mailto:ccamp@xxxxxxxx> > > 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@xxxxxxxx <mailto:ietf@xxxxxxxx> mailing lists by 2012-08-17. > Exceptionally, comments may be sent to iesg@xxxxxxxx > <mailto:iesg@xxxxxxxx> 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@xxxxxxxxx <mailto:jdoe@xxxxxxxxx> | 3500 Carling Ave. | Ottawa > CANADA K2H 8E9 > Direct +1.613.670.3211 > > > > >