ietf
[Top] [All Lists]

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

2012-08-21 16:24:05
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] On Behalf Of The IESG
Sent: Friday, July 20, 2012 11:19 AM
To: IETF-Announce
Cc: 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 mailing lists by 2012-08-17. Exceptionally, comments 
may be sent to 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 | 3500 Carling Ave. | Ottawa CANADA K2H 8E9
Direct +1.613.670.3211
 

Attachment: smime.p7s
Description: S/MIME cryptographic signature