Re: Last Call: <draft-ietf-ccamp-rfc5787bis-05.txt>

[Lou Berger <[e-mail]>]

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:[e-mail]]
> *Sent:* 22 August 2012 17:35
> *To:* Acee Lindem; Ong, Lyndon
> *Cc:* [e-mail]; [e-mail];
> 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:[e-mail]]
> *Sent:* 21 August, 2012 17:23
> *To:* Ong, Lyndon
> *Cc:* [e-mail]; Shew, Stephen;
> [e-mail]; 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: [e-mail]
> <mailto:[e-mail]> [mailto:[e-mail]]
> On Behalf Of The IESG
> 
> Sent: Friday, July 20, 2012 11:19 AM
> 
> To: IETF-Announce
> 
> Cc: [e-mail] <mailto:[e-mail]>
> 
> 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 [e-mail] <mailto:[e-mail]> mailing lists by 2012-08-17.
> Exceptionally, comments may be sent to [e-mail]
> <mailto:[e-mail]> 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
> [e-mail] <mailto:[e-mail]>  | 3500 Carling Ave. | Ottawa
> CANADA K2H 8E9
> Direct +1.613.670.3211
> 
>  
> 
>  
>