Subject: FW: re: Last Call: <draft-ietf-ccamp-rfc5787bis-05.txt>

From: "Ong, Lyndon" <[email-masked]>
Date: Fri, 17 Aug 2012 19:58:19 -0400

(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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of The IESG

Sent: Friday, July 20, 2012 11:19 AM

To: IETF-Announce

Cc: [email-masked]<mailto:[email-masked]>

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 [email-masked]<mailto:[email-masked]> mailing lists by 2012-08-17. Exceptionally, comments may be sent to [email-masked]<mailto:[email-masked]> 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
[email-masked]<mailto:[email-masked]> | 3500 Carling Ave. | Ottawa CANADA K2H 8E9
Direct +1.613.670.3211

---

From: Acee Lindem <[email-masked]>
Date: Tue, 21 Aug 2012 17:23:17 -0400

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:

> 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:
> 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."
>  
> 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.
>  
> 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 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. “
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of The IESG
> Cc: [email-masked]
> 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 [email-masked] mailing lists by 2012-08-17. Exceptionally, comments may be sent to [email-masked] 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
>  
> [email-masked] | 3500 Carling Ave. | Ottawa CANADA K2H 8E9
> Direct +1.613.670.3211
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 22 Aug 2012 18:01:49 +0100

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:[email-masked]] 
Sent: 22 August 2012 17:35
To: Acee Lindem; Ong, Lyndon
Cc: [email-masked]; [email-masked]; 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:[email-masked]] 
Sent: 21 August, 2012 17:23
To: Ong, Lyndon
Cc: [email-masked]; Shew, Stephen;
[email-masked]; 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:

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: [email-masked] [mailto:[email-masked]] On
Behalf Of The IESG
Sent: Friday, July 20, 2012 11:19 AM
To: IETF-Announce
Cc: [email-masked]
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 [email-masked]
mailing lists by 2012-08-17. Exceptionally, comments may be sent to
[email-masked] 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

 

 

Stephen Shew | Director, Standards
[email-masked] <mailto:[email-masked]>  | 3500 Carling Ave. | Ottawa CANADA K2H
8E9
Direct +1.613.670.3211

---

From: Lou Berger <[email-masked]>
Date: Wed, 22 Aug 2012 13:11:19 -0400

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:[email-masked]]
> *Sent:* 22 August 2012 17:35
> *To:* Acee Lindem; Ong, Lyndon
> *Cc:* [email-masked]; [email-masked];
> Andrew G. (Andy) Malis
> *Subject:* RE: Last Call: <draft-ietf-ccamp-rfc5787bis-05.txt>
> 
>  
> 
> 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:[email-masked]]
> *Sent:* 21 August, 2012 17:23
> *To:* Ong, Lyndon
> *Cc:* [email-masked]; Shew, Stephen;
> *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 
> 
> 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:
> 
> 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.
> 
>  
> 
> 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 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
> 
>  
> 
> From: [email-masked]
> <mailto:[email-masked]> [mailto:[email-masked]]
> On Behalf Of The IESG
> 
> Cc: [email-masked] <mailto:[email-masked]>
> 
> 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:
> 
> 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 [email-masked] <mailto:[email-masked]> mailing lists by 2012-08-17.
> Exceptionally, comments may be sent to [email-masked]
> <mailto:[email-masked]> 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
> 
>  
> 
> *Stephen Shew* | Director, Standards
> [email-masked] <mailto:[email-masked]>  | 3500 Carling Ave. | Ottawa
> CANADA K2H 8E9
> Direct +1.613.670.3211
> 
>  
> 
>  
>

---

From: "Shew, Stephen" <[email-masked]>
Date: Wed, 22 Aug 2012 12:34:39 -0400

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:[email-masked]] 
Sent: 21 August, 2012 17:23
To: Ong, Lyndon
Cc: [email-masked]; Shew, Stephen; [email-masked]; Andrew G. (Andy) Malis
Subject: Re: Last Call: <draft-ietf-ccamp-rfc5787bis-05.txt> 

Hi Stephen, Lyndon, 

Thanks,

Acee 

Stephen Shew

-----Original Message-----

To: IETF-Announce

Cc: [email-masked]

 

Abstract

   routing in an ASON.

 

 

Stephen Shew | Director, Standards
[email-masked] <mailto:[email-masked]>  | 3500 Carling Ave. | Ottawa CANADA K2H 8E9
Direct +1.613.670.3211