< draft-malis-ccamp-rfc5787bis-02.txt		draft-malis-ccamp-rfc5787bis-03.txt >
	INTERNET-DRAFT A. Malis, ed.		INTERNET-DRAFT A. Malis, ed.
	Intended Status: Proposed Standard Verizon Communications		Intended Status: Proposed Standard Verizon Communications
	Expires: September 15, 2011 A. Lindem, ed.		Expires: October 13, 2011 A. Lindem, ed.
	Ericsson		Ericsson
	March 14, 2011		April 11, 2011
	Updates to ASON Routing for OSPFv2 Protocols (RFC 5787bis)		Updates to ASON Routing for OSPFv2 Protocols (RFC 5787bis)
	draft-malis-ccamp-rfc5787bis-02.txt		draft-malis-ccamp-rfc5787bis-03.txt
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	skipping to change at page 3, line 9 ¶		skipping to change at page 3, line 9 ¶
	7.2.2 Inter-RA Export Upward/Downward Sub-TLV Processing . 13		7.2.2 Inter-RA Export Upward/Downward Sub-TLV Processing . 13
	8. OSPFv2 Scalability . . . . . . . . . . . . . . . . . . . . . 13		8. OSPFv2 Scalability . . . . . . . . . . . . . . . . . . . . . 13
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 14		9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
	10.1. Sub-TLVs of the Link TLV . . . . . . . . . . . . . . . 14		10.1. Sub-TLVs of the Link TLV . . . . . . . . . . . . . . . 14
	10.2. Sub-TLVs of the Node Attribute TLV . . . . . . . . . . 15		10.2. Sub-TLVs of the Node Attribute TLV . . . . . . . . . . 15
	10.3. Sub-TLVs of the Router Address TLV . . . . . . . . . . 15		10.3. Sub-TLVs of the Router Address TLV . . . . . . . . . . 15
	11. Management Considerations . . . . . . . . . . . . . . . . . 16		11. Management Considerations . . . . . . . . . . . . . . . . . 16
	11.1. Routing Area (RA) Isolation . . . . . . . . . . . . . . 16		11.1. Routing Area (RA) Isolation . . . . . . . . . . . . . . 16
	11.2 Routing Area (RA) Topology/Configuration Changes . . . . 16		11.2 Routing Area (RA) Topology/Configuration Changes . . . . 16
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		12. Comparison to Requirements in RFC 4258 . . . . . . . . . . . 16
	12.1. Normative References . . . . . . . . . . . . . . . . . 17		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
	12.2. Informative References . . . . . . . . . . . . . . . . 17		13.1. Normative References . . . . . . . . . . . . . . . . . 22
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18		13.2. Informative References . . . . . . . . . . . . . . . . 23
	Appendix A. ASON Terminology . . . . . . . . . . . . . . . . . . 19		14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
	Appendix B. ASON Routing Terminology . . . . . . . . . . . . . . 20		Appendix A. ASON Terminology . . . . . . . . . . . . . . . . . . 25
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21		Appendix B. ASON Routing Terminology . . . . . . . . . . . . . . 26
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
	1. Introduction		1. Introduction
	The Generalized Multiprotocol Label Switching (GMPLS) [RFC3945]		The Generalized Multiprotocol Label Switching (GMPLS) [RFC3945]
	protocol suite is designed to provide a control plane for a range of		protocol suite is designed to provide a control plane for a range of
	network technologies including optical networks such as time division		network technologies including optical networks such as time division
	multiplexing (TDM) networks including SONET/SDH and Optical Transport		multiplexing (TDM) networks including SONET/SDH and Optical Transport
	Networks (OTNs), and lambda switching optical networks.		Networks (OTNs), and lambda switching optical networks.
	The ITU-T defines the architecture of the Automatically Switched		The ITU-T defines the architecture of the Automatically Switched
	skipping to change at page 17, line 5 ¶		skipping to change at page 16, line 46 ¶
	architectural evolution. OSPF [RFC2328] includes support for the		architectural evolution. OSPF [RFC2328] includes support for the
	dynamic introduction or removal of ASON reachability information		dynamic introduction or removal of ASON reachability information
	through the flooding and purging of OSPF opaque LSAs [RFC5250]. Also,		through the flooding and purging of OSPF opaque LSAs [RFC5250]. Also,
	when an RA is partitioned or an RC fails, stale LSAs SHOULD NOT be		when an RA is partitioned or an RC fails, stale LSAs SHOULD NOT be
	used unless the advertising RC is reachable. The configuration of		used unless the advertising RC is reachable. The configuration of
	OSPF RAs and the policies governing the redistribution of ASON		OSPF RAs and the policies governing the redistribution of ASON
	reachability information between RAs are implementation issues		reachability information between RAs are implementation issues
	outside of the OSPF routing protocol and beyond the scope of this		outside of the OSPF routing protocol and beyond the scope of this
	document.		document.
	12. References		12. Comparison to Requirements in RFC 4258
	12.1. Normative References		The following table shows how this draft complies with the
			requirements in [RFC4258]. The first column contains a requirements
			number (1-30) and the relevant section in RFC 4258. The second column
			describes the requirement, the third column discusses the compliance
			to that requirement, and the fourth column lists the relevant section
			in draft, and/or another RFC that already satisfies the requirement.
			+----------+---------------------------+---------------+-------------+
			| RFC 4258 | RFC 4258 Requirement | Compliance | Reference |
			| Section | | | |
			| (Req. | | | |
			| Number) | | | |
			+----------+---------------------------+---------------+-------------+
			| 3.0 (1) | The failure of an RC, or | Implied by | Not an |
			| | the failure of | separation of |attribute of |
			| |communications between RCs,| transport and | routing |
			| |and the subsequent recovery|control plane. | protocol. |
			| |from the failure condition | | |
			| | MUST NOT disrupt call in | | |
			| | progress. | | |
			+----------+---------------------------+---------------+-------------+
			| 3.1 (2) |Multiple Hierarchical Level| Yes | Sections 2 |
			| | of ASON Routing Areas | | and 3 |
			| | (RAs). | | |
			+----------+---------------------------+---------------+-------------+
			| 3.1 (3) | Prior to establishing | Yes when RA |Section 11.1 |
			| | communications, RCs MUST | maps to OSPF | |
			| |verify that they are bound | Area ID. | |
			| | to the same parent RA. | | |
			+----------+---------------------------+---------------+-------------+
			| 3.1 (4) | The RC ID MUST be unique | Yes |RFC 2328 and |
			| | within its containing RA. | | Section 3. |
			+----------+---------------------------+---------------+-------------+
			| 3.1 (5) |Each RA within a carrier's |Yes - although | Sections 2, |
			| | network SHALL be uniquely | uniqueness is | 3, and 11.1 |
			| |identifiable. RA IDs MAY be|the operator's | |
			| |associated with a transport|responsibility.| |
			| | plane name space, whereas | | |
			| |RC IDs are associated with | | |
			| |a control plane name space.| | |
			+----------+---------------------------+---------------+-------------+
			| 3.2 (6) | Hierarchical Routing | Yes | Section 7 |
			| | Information Dissemination | | |
			+----------+---------------------------+---------------+-------------+
			| 3.2 (7) | Routing Information | Yes | Section 7.1 |
			| |exchanged between levels N | | |
			| | and N+1 via separate | | |
			| | instances and | | |
			| | import/export. | | |
			+----------+---------------------------+---------------+-------------+
			+----------+---------------------------+---------------+-------------+
			| 3.2 (8) | Routing Information | No - Not | |
			| |exchanged between levels N | described. | |
			| | and N+1 via external link | | |
			| | (inter-RA links). | | |
			+----------+---------------------------+---------------+-------------+
			| 3.2 (9) | Routing information | Yes | Sections 4, |
			| | exchange MUST include | |6, 6.1, 6.2, |
			| | reachability information | | and 8 |
			| | and MAY include, upon | | |
			| | policy decision, node and | | |
			| | link topology. | | |
			+----------+---------------------------+---------------+-------------+
			| 3.2 (10) | There SHOULD NOT be any |Yes - separate | Sections 2 |
			| | dependencies on the | instances. | and 3 |
			| |different routing protocols| | |
			| | used within an RA or in | | |
			| | different RAs. | | |
			+----------+---------------------------+---------------+-------------+
			| 3.2 (11) |The routing protocol SHALL | Yes | Section 7.2 |
			| | differentiate the routing | | |
			| |information originated at a| | |
			| |given-level RA from derived| | |
			| | routing information | | |
			| | (received from external | | |
			| | RAs), even when this | | |
			| |information is forwarded by| | |
			| | another RC at the same | | |
			| | level. | | |
			+----------+---------------------------+---------------+-------------+
			| 3.2 (12) | The routing protocol MUST | Yes | Section 7.2 |
			| | provide a mechanism to | | |
			| | prevent information | | |
			| |propagated from a Level N+1| | |
			| | RA's RC into the Level N | | |
			| | RA's RC from being | | |
			| | re-introduced into the | | |
			| | Level N+1 RA's RC. | | |
			+----------+---------------------------+---------------+-------------+
			| 3.2 (13) | The routing protocol MUST | Yes | Section 7.2 |
			| | provide a mechanism to | | |
			| | prevent information | | |
			| |propagated from a Level N-1| | |
			| | RA's RC into the Level N | | |
			| | RA's RC from being | | |
			| | re-introduced into the | | |
			| | Level N-1 RA's RC. | | |
			+----------+---------------------------+---------------+-------------+
			+----------+---------------------------+---------------+-------------+
			| 3.2 (14) | Instance of a Level N | Yes | Sections 2, |
			| | routing function and an | | 3, and 7 |
			| | instance of a Level N+1 | | |
			| | routing function in the | | |
			| | same system. | | |
			+----------+---------------------------+---------------+-------------+
			| 3.2 (15) | The Level N routing | Not described | N/A |
			| | function is on a separate | but possible. | |
			| | system the Level N+1 | | |
			| | routing function. | | |
			+----------+---------------------------+---------------+-------------+
			| 3.3 (16) |The RC MUST support static | Yes - | Sections 2 |
			| | (i.e., operator assisted) | automation |and 3. Config|
			| | and MAY support automated |requirement is | is product |
			| | configuration of the | ambiguous. | specific. |
			| |information describing its | | |
			| |relationship to its parent | | |
			| | and its child within the | | |
			| | hierarchical structure | | |
			| | (including RA ID and RC | | |
			| | ID). | | |
			+----------+---------------------------+---------------+-------------+
			| 3.3 (17) |The RC MUST support static |Yes - when OSPF|RFC 2328 and |
			| | (i.e., operator assisted) |area maps to RA|Section 11.1 |
			| | and MAY support automated | discovery is | |
			| | configuration of the | automatic. | |
			| |information describing its | | |
			| | associated adjacencies to | | |
			| | other RCs within an RA. | | |
			+----------+---------------------------+---------------+-------------+
			| 3.3 (18) |The routing protocol SHOULD| Yes | RFC 2328 |
			| |support all the types of RC| | |
			| | adjacencies described in | | |
			| |Section 9 of [G.7715]. The | | |
			| | latter includes congruent | | |
			| |topology (with distributed | | |
			| | RC) and hubbed topology | | |
			| |(e.g., note that the latter| | |
			| | does not automatically | | |
			| | imply a designated RC). | | |
			+----------+---------------------------+---------------+-------------+
			+----------+---------------------------+---------------+-------------+
			| 3.4 (19) |The routing protocol SHOULD| Yes |RFC 2328, RFC|
			| | be capable of supporting | | 5250, and |
			| |architectural evolution in | |Section 11.2.|
			| | terms of the number of | | |
			| |hierarchical levels of RAs,| | |
			| |as well as the aggregation | | |
			| | and segmentation of RAs. | | |
			+----------+---------------------------+---------------+-------------+
			|3.5.2 (20)|Advertisements MAY contain | | |
			| |the following common set of| | |
			| | information regardless of | | |
			| | whether they are link or | | |
			| | node related: | | |
			| | - RA ID of the RA to | Yes |Section 7.2.1|
			| |which the advertisement is | | |
			| | bounded | | |
			| | - RC ID of the entity | Yes | RFC 2328 |
			| | generating the | | |
			| | advertisement | | |
			| | - Information to | Yes |RFC 2328, RFC|
			| | uniquely identify | | 5250 |
			| | advertisements | | |
			| | - Information to | No - Must | |
			| | determine whether an |compare to old | |
			| | advertisement has been | | |
			| | updated | | |
			| | - Information to | Yes |Section 7.2.1|
			| | indicate when an | | |
			| | advertisement has been | | |
			| | derived from a different | | |
			| | level RA | | |
			+----------+---------------------------+---------------+-------------+
			|3.5.3 (21)|The Node Attributes Node ID|Yes - Prefixes | RFC 5786, |
			| | and Reachability must be | only for |Section 4 and|
			| | advertised. It MAY be | reachability | 6 |
			| | advertised as a set of | | |
			| |associated external (e.g., | | |
			| | User Network Interface | | |
			| | (UNI)) address/address | | |
			| | prefixes or a set of | | |
			| | associated SNPP link | | |
			| | IDs/SNPP ID prefixes, the | | |
			| |selection of which MUST be | | |
			| | consistent within the | | |
			| | applicable scope. | | |
			+----------+---------------------------+---------------+-------------+
			+----------+---------------------------+---------------+-------------+
			|3.5.4 (22)| The Link Attributes Local | Yes | Section 6.1 |
			| | SNPP link ID, Remote SNPP | | |
			| |link ID, and layer specific| | |
			| | characteristics must be | | |
			| | advertised. | | |
			+----------+---------------------------+---------------+-------------+
			|3.5.4 (23)| Link Signaling Attributes | Yes | Section 5, |
			| |other than Local Adaptation| | RFC 4652 - |
			| |(Signal Type, Link Weight, | |Section 5.3.1|
			| | Resource Class, Local | | |
			| | Connection Types, Link | | |
			| | Capacity, Link | | |
			| | Availability, Diversity | | |
			| | Support) | | |
			+----------+---------------------------+---------------+-------------+
			|3.5.4 (24)| Link Signaling Local | Yes | Section 5.1 |
			| | Adaptation | | |
			+----------+---------------------------+---------------+-------------+
			| 5 (25) | The routing adjacency | Yes |Section 2, 3,|
			| | topology (i.e., the | | and 6 |
			| |associated PC connectivity | | |
			| |topology) and the transport| | |
			| |network topology SHALL NOT | | |
			| |be assumed to be congruent.| | |
			+----------+---------------------------+---------------+-------------+
			| 5 (26) |The routing topology SHALL | Yes |RFC 2328, RFC|
			| | support multiple links | | 3630 |
			| | between nodes and RAs. | | |
			+----------+---------------------------+---------------+-------------+
			| 5 (27) |The routing protocol SHALL | Yes |RFC 2328, RFC|
			| | converge such that the | | 5250 |
			| | distributed RDBs become | | |
			| |synchronized after a period| | |
			| | of time. | | |
			+----------+---------------------------+---------------+-------------+
			| 5 (28) |Self-consistent information|Yes - However, | Section 7.1 |
			| | at the receiving level | this is not a | |
			| | resulting from any | routing | |
			| | transformation (filter, | protocol | |
			| | summarize, etc.) and | function. | |
			| | forwarding of information | | |
			| | from one RC to RC(s) at | | |
			| | different levels when | | |
			| |multiple RCs are bound to a| | |
			| | single RA. | | |
			+----------+---------------------------+---------------+-------------+
			+----------+---------------------------+---------------+-------------+
			| 5 (29) | In order to support |Partial - OSPF |RFC 2328 and |
			| | operator-assisted changes | supports the | RFC 5250 |
			| | in the containment | purging of | |
			| | relationships of RAs, the | stale | |
			| | routing protocol SHALL |advertisements | |
			| |support evolution in terms |and origination| |
			| | of the number of | of new. The | |
			| |hierarchical levels of RAs.|non-disruptive | |
			| | For example: support of | behavior is | |
			| | non-disruptive operations |implementation | |
			| |such as adding and removing| specific. | |
			| | RAs at the top/bottom of | | |
			| | the hierarchy, adding or | | |
			| | removing a hierarchical | | |
			| |level of RAs in or from the| | |
			| |middle of the hierarchy, as| | |
			| | well as aggregation and | | |
			| | segmentation of RAs. | | |
			+----------+---------------------------+---------------+-------------+
			| 5 (30) | A collection of links and |Yes - Within an| Sections 4 |
			| |nodes such as a subnetwork | RA it must be | and 6 |
			| | or RA MUST be able to | consistent. | |
			| | represent itself to the | | |
			| | wider network as a single | | |
			| | logical entity with only | | |
			| |its external links visible | | |
			| | to the topology database. | | |
			+----------+---------------------------+---------------+-------------+
			13. References
			13.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.		[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
	[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic		[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic
	Engineering (TE) Extensions to OSPF Version 2", RFC		Engineering (TE) Extensions to OSPF Version 2", RFC
	3630, September 2003.		3630, September 2003.
	skipping to change at page 17, line 36 ¶		skipping to change at page 23, line 17 ¶
	in Support of Generalized Multi-Protocol Label Switching		in Support of Generalized Multi-Protocol Label Switching
	(GMPLS)", RFC 4203, October 2005.		(GMPLS)", RFC 4203, October 2005.
	[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The		[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
	OSPF Opaque LSA Option", RFC 5250, July 2008.		OSPF Opaque LSA Option", RFC 5250, July 2008.
	[RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's		[RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's
	Local Addresses in OSPF TE Extensions", RFC 5786, March		Local Addresses in OSPF TE Extensions", RFC 5786, March
	2010.		2010.
	12.2. Informative References		13.2. Informative References
	[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with		[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with
	Digital Signatures", RFC 2154, June 1997.		Digital Signatures", RFC 2154, June 1997.
	[RFC4258] Brungard, D., Ed., "Requirements for Generalized Multi-		[RFC4258] Brungard, D., Ed., "Requirements for Generalized Multi-
	Protocol Label Switching (GMPLS) Routing for the		Protocol Label Switching (GMPLS) Routing for the
	Automatically Switched Optical Network (ASON)", RFC		Automatically Switched Optical Network (ASON)", RFC
	4258, November 2005.		4258, November 2005.
	[RFC4652] Papadimitriou, D., Ed., Ong, L., Sadler, J., Shew, S.,		[RFC4652] Papadimitriou, D., Ed., Ong, L., Sadler, J., Shew, S.,
	skipping to change at page 18, line 24 ¶		skipping to change at page 24, line 9 ¶
	Architecture and Requirements for Link State Protocols",		Architecture and Requirements for Link State Protocols",
	November 2003.		November 2003.
	[G.805] ITU-T Rec. G.805, "Generic functional architecture of		[G.805] ITU-T Rec. G.805, "Generic functional architecture of
	transport networks)", March 2000.		transport networks)", March 2000.
	[G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the		[G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the
	Automatically Switched Optical Network (ASON)," 2006		Automatically Switched Optical Network (ASON)," 2006
	(and Amendments 1 and 2).		(and Amendments 1 and 2).
	13. Acknowledgements		14. Acknowledgements
	The editors would like to thank Dimitri Papadimitriou for editing RFC		The editors would like to thank Dimitri Papadimitriou for editing RFC
	5787, from which this document is derived, and Lyndon Ong and Remi		5787, from which this document is derived, and Lyndon Ong, Remi
	Theillaud for their useful comments and suggestions.		Theillaud, Stephen Shew, Jonathan Sadler, Deborah Brungard, and Lou
			Berger for their useful comments and suggestions.
	Appendix A. ASON Terminology		Appendix A. ASON Terminology
	This document makes use of the following terms:		This document makes use of the following terms:
	Administrative domain: (See Recommendation [G.805].) For the		Administrative domain: (See Recommendation [G.805].) For the
	purposes of [G7715.1], an administrative domain represents the		purposes of [G7715.1], an administrative domain represents the
	extent of resources that belong to a single player such as a		extent of resources that belong to a single player such as a
	network operator, a service provider, or an end-user.		network operator, a service provider, or an end-user.
	Administrative domains of different players do not overlap amongst		Administrative domains of different players do not overlap amongst
End of changes. 9 change blocks.
	16 lines changed or deleted		284 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/