At the Prague CCAMP meeting, the authors were given a bit of homework
to do in order for draft-malis-ccamp-rfc5787bis to be able to become a
WG draft.

1. Add a table to the draft showing how it meets the requirements in
RFC 4258. This has been done in a new section 12 in revision -03 of
the draft.

2. Separately, show how it meets the requirements liaised from SG15 in
https://datatracker.ietf.org/liaison/424/ . This is shown in the
attached Microsoft Word table. Since this is the iETF, I've also
converted that table to text, and I've included it here. It's best to
read the table using a fixed-width font.

As the draft progresses, we intend the conformance tables to be
updated to match any changes in the draft.

Cheers,
Andy

-------------

+------+-----------------------------+---------------------------------+
|Number|   ITU-T Requirements Text   | 5787bis Draft or RFC Addressing |
|      |                             |           Requirement           |
+------+-----------------------------+---------------------------------+
|  1   |G.8080 (2000) Sec 6.2: Within|  Per-layer link attributes are  |
|      |     the context of this     | discussed in section 5.0 of RFC |
|      |Recommendation a routing area|            5787Bis.             |
|      |exists within a single layer |                                 |
|      |          network.           |                                 |
|      |                             |                                 |
|      | G.7715.1 (2004) Sec 9.5.1:  |   The RFC 3630 attributes TE    |
|      |       Layer Specific        |Metric, Administrative Group, and|
|      |       Characteristics       |  Link Type map respectively to  |
|      |        o Link Weight        |Link Weight, Resource Class, and |
|      |      o Resource Class       |        Local Connection         |
|      |   o Local Connection Type   |                                 |
+------+-----------------------------+---------------------------------+
|  2   | G.7715.1 (2004) Sec 5.2.1:  |This requirement is addressed in |
|      |  The routing architecture   |sections 2 and 3 of RFC 5787Bis. |
|      |    allows for support of    |                                 |
|      | multiple routing protocols. |                                 |
|      |     This is achieved by     |                                 |
|      |   instantiating different   |                                 |
|      | protocol controllers.  The  |                                 |
|      |architecture does not assume |                                 |
|      | a one-to-one correspondence |                                 |
|      |           between           |                                 |
|      |Routing Controller instances |                                 |
|      |   and Protocol Controller   |                                 |
|      |         instances.          |                                 |
+------+-----------------------------+---------------------------------+
|  3   |G.7715 (2002) Sec 5.3.1, Par |This requirement is addressed in |
|      |    4: In the context of     |   section 7.2 of RFC 5787Bis.   |
|      |interactions between Routing |                                 |
|      |  Controllers at different   |                                 |
|      | levels of the hierarchy, it |                                 |
|      |  is important to note that  |                                 |
|      |information received from the|                                 |
|      |   parent RC shall not be    |                                 |
|      |circulated back to the parent|                                 |
|      |             RC.             |                                 |
|      |                             |                                 |
|      |G.7715.1 (2004) Sec 8.1.1.4, |                                 |
|      | Par 1: In order to prevent  |                                 |
|      | such potential loops, there |                                 |
|      |  is a requirement for the   |                                 |
|      |     routing protocol to     |                                 |
|      |differentiate between routing|                                 |
|      |information generated within |                                 |
|      |the level of the receiving RC|                                 |
|      |and information that has been|                                 |
|      |received from higher or lower|                                 |
|      |  levels, even when this is  |                                 |
|      | forwarded by another RC at  |                                 |
|      |       the same level.       |                                 |
|      |G.7715.1 (2004) Sec 8.1.1.4, |                                 |
|      |   Par 1: [T]he link state   |                                 |
|      |routing protocol must include|                                 |
|      |     a method to prevent     |                                 |
|      |     re-introduction of      |                                 |
|      | information propagated into |                                 |
|      |the Level N RA from the Level|                                 |
|      | N+1 RA back into the Level  |                                 |
|      |   N+1 RA, and vice versa.   |                                 |
+------+-----------------------------+---------------------------------+
|  4   |G.7715 (2002) Sec 6.1, Bullet| Sections 2 and 3 in RFC 5787Bis |
|      |  1: Information exchanged   |discuss the relationship between |
|      | between routing controllers |      instances and routing      |
|      |    is subject to policy     | controllers. Section 7.1 in RFC |
|      | constraints imposed at the  |      5787Bis discusses the      |
|      |      reference points.      |      import/export rules.       |
+------+-----------------------------+---------------------------------+
|  5   |   G.7715 (2002) Sec 6.1,    | Sections 2 and 7 of RFC 5787Bis |
|      |Bullet2: A routing performer |  discuss the layering of OSPF   |
|      | operating in a routing area |  instances to support multiple  |
|      |should not be dependent upon | RAs. However, the use of other  |
|      |the routing protocol(s) that |protocols is not discussed. This |
|      | are being used in any other |         could be added.         |
|      |        routing area.        |                                 |
+------+-----------------------------+---------------------------------+
|  6   |G.7715 (2002) Sec 6.1, Bullet|See requirement 5 response above.|
|      | 3: The routing information  |                                 |
|      |  exchanged between routing  |                                 |
|      |     control domains is      |                                 |
|      | independent of intra-domain |                                 |
|      |      protocol choices.      |                                 |
+------+-----------------------------+---------------------------------+
|  7   |G.7715 (2002) Sec 6.1, Bullet|  Sections 2, 7, and 7.1 of RFC  |
|      | 4: The routing information  |   5787Bis address the use of    |
|      |  exchanged between routing  | multiple OSPF instances for RAs |
|      |     control domains is      |   or control domains when the   |
|      | independent of intra-domain |  instances co-reside. The case  |
|      |control distribution choices,|decentralized case could be added|
|      |     e.g., centralized,      |if required. In the decentralized|
|      |     fully-distributed.      | case, a separate OSPF instance  |
|      |                             |  and RA ID 0 could be used to   |
|      |                             |  exchange information between   |
|      |                             |levels and import/export policies|
|      |                             |    would be applied between     |
|      |                             |           instances.            |
+------+-----------------------------+---------------------------------+
|  8   |   G.7715 (2002) Sec 6.1,    |This is addressed in Section 6 of|
|      |    Bullet5: The routing     |          RFC 5787Bis.           |
|      |   adjacency topology and    |                                 |
|      | transport network topology  |                                 |
|      | shall not be assumed to be  |                                 |
|      |         congruent.          |                                 |
+------+-----------------------------+---------------------------------+
|  9   |G.7715 (2002) Sec 6.1, Bullet|Section 2 in RFC5787Bis discusses|
|      |6: Each routing area shall be| the mapping of OSPF Area IDs to |
|      |uniquely identifiable within |ASON RAs. RFC 2328 specifies the |
|      |     a carrier network.      |rules for the assignment of Area |
|      |                             |              IDs.               |
+------+-----------------------------+---------------------------------+
|  10  |G.7715 (2002) Sec 6.1, Bullet| Sections 2 and 6 of RFC 5787Bis |
|      | 7: The routing information  |    address this requirement.    |
|      | shall support an abstracted |                                 |
|      | view of individual domains. |                                 |
|      | The level of abstraction is |                                 |
|      | subject to operator policy. |                                 |
+------+-----------------------------+---------------------------------+
|  11  |uniquely identifiable within |Section 2 in RFC5787Bis discusses|
|      |     a carrier network.      | the mapping of OSPF Area IDs to |
|      |                             |ASON RAs. RFC 2328 specifies the |
|      |                             |rules for the assignment of Area |
|      |                             |              IDs.               |
+------+-----------------------------+---------------------------------+
|  12  |G.7715 (2002) Sec 6.2, Bullet|This is addressed in Section 2 of|
|      |1: The routing protocol shall|          RFC 5787Bis.           |
|      |  be capable of supporting   |                                 |
|      |multiple hierarchical levels.|                                 |
+------+-----------------------------+---------------------------------+
|  13  |G.7715 (2002) Sec 6.2, Bullet| This is addressed in Sections 7 |
|      |2: The routing protocol shall|     and 7.1 in RFC 5787Bis.     |
|      |support hierarchical routing |                                 |
|      |  information dissemination  |                                 |
|      |including summarized routing |                                 |
|      |        information.         |                                 |
+------+-----------------------------+---------------------------------+
|  14  |G.7715 (2002) Sec 6.2, Bullet| This is address in RFC 2328 for |
|      |3: The routing protocol shall|control plane interfaces and RFC |
|      |include support for multiple |    3630 for transport plane     |
|      |links between nodes and shall|interfaces. For transport links, |
|      |   allow for link and node   |   node diversity metrics were   |
|      |         diversity.          |introduced for GMPLS in RFC 4203 |
|      |                             |  with Shared Risk Link Groups   |
|      |                             |(SRLGs). No equivalent extension |
|      |                             |    exists at the node level.    |
+------+-----------------------------+---------------------------------+
|  15  |G.7715 (2002) Sec 6.2, Bullet|This is address in Section 11 of |
|      |4: The routing protocol shall|   RFC 5787Bis. Note that the    |
|      |  be capable of supporting   | provisioning of new and deleted |
|      | architectural evolution in  |  OSPF instances is outside the  |
|      |terms of number of levels of |        routing protocol.        |
|      |hierarchies, aggregation and |                                 |
|      |  segmentation of domains.   |                                 |
+------+-----------------------------+---------------------------------+
|  16  |G.7715 (2002) Sec 6.2, Bullet| OSPF scaling considerations are |
|      |5: The routing protocol shall|  discussed in Section 8 of RFC  |
|      | be scalable with respect to |            5787Bis.             |
|      | the number of links, nodes, |                                 |
|      |and routing area hierarchical|                                 |
|      |           levels.           |                                 |
+------+-----------------------------+---------------------------------+
|  17  | G.7715 (2002) Amd 1 (2007)  |   Since internal APIs are not   |
|      |   Sec 6.2, Bullet 6: The    |    specified for OSPF, this     |
|      |  routing protocol shall be  |  requirement is out of scope.   |
|      |    capable of supporting    |                                 |
|      |  flexible distributions of  |                                 |
|      |  ASON (G.8080) functional   |                                 |
|      |   components to different   |                                 |
|      | physical computing systems. |                                 |
+------+-----------------------------+---------------------------------+
|  18  | G.7715 (2002) Amd 1 (2007)  | This is addressed in Section 4  |
|      |   Sec 6.2, Bullet 7: The    |and 6 of RFC 5787Bis. The case of|
|      |  routing protocol shall be  |multiple OSPF routers (i.e., RCs)|
|      |    capable of supporting    |   advertising reachability or   |
|      | flexible cardinality (i.e., |topology information for the same|
|      |m:n) between ASON functional |transport node is not considered |
|      |components as well as between| a required use case and is not  |
|      | ASON functional components  |           addressed.            |
|      |   and G.805 sub-networks.   |                                 |
+------+-----------------------------+---------------------------------+
|  19  |G.7715 (2002) Sec 6.2, Bullet|This is a basic property of OSPF |
|      | 6: In response to a routing |reliable flooding as described in|
|      |event (e.g., topology update,|            RFC 2328.            |
|      |  reachability update) the   |                                 |
|      |  contents of the RDB shall  |                                 |
|      |converge and a proper damping|                                 |
|      |   mechanism for flapping    |                                 |
|      |    (chattering) shall be    |                                 |
|      |          provided.          |                                 |
+------+-----------------------------+---------------------------------+
|  20  |G.7715 (2002) Sec 6.2, Bullet|    OSPF has supports strong     |
|      |7: The routing protocol shall| authentication as described in  |
|      |support or may provide add-on| RFC 5709. Additionally security |
|      |features for supporting a set|measures including automated key |
|      |of operator-defined security |   management are under study.   |
|      | objectives where required.  |                                 |
+------+-----------------------------+---------------------------------+
|  21  |G.7715 (2002) Sec 6.3, Bullet| OSPF path selection base on the |
|      |   1: Path selection shall   |    SPF algorithm results in     |
|      | result in loop-free paths.  |  loop-free paths. However, the  |
|      |                             |ASON GMPLS LSP path selection is |
|      |                             |  outside the scope of the OSPF  |
|      |                             |            protocol.            |
+------+-----------------------------+---------------------------------+
|  22  |G.7715 (2002) Sec 6.3, Bullet|ASON GMPLS LSP path selection is |
|      |   2: Path selection shall   |  outside the scope of the OSPF  |
|      | support at least one of the |            protocol.            |
|      | routing paradigms described |                                 |
|      |      in G.8080; i.e.,       |                                 |
|      |  hierarchical, source, and  |                                 |
|      |        step-by-step.        |                                 |
+------+-----------------------------+---------------------------------+
|  23  |G.7715 (2002) Sec 6.3, Bullet|ASON GMPLS LSP path selection is |
|      | 3: Path selection shall be  |  outside the scope of the OSPF  |
|      | able to support a class of  |            protocol.            |
|      |   routing constraints as    |                                 |
|      |  described in Section 10.   |                                 |
|      |                             |                                 |
|      |    G.7715 (2002) Sec 10:    |While not within the scope of the|
|      |Examples of constraints are: | protocol, many of the following |
|      |         o diversity         |     constraints are already     |
|      |    o network performance    |standardized in RFC 3630 and RFC |
|      |         objectives          |  4203 or are proposed in other  |
|      |    o management policies    |          CCAMP drafts.          |
|      | o transport layer specific  |                                 |
|      |constraints (possibly a link |                                 |
|      |       weight metric)        |                                 |
+------+-----------------------------+---------------------------------+
|  24  | Section 10: There are three | This is addressed in sections 3 |
|      |  separate Transport names   |      and 4 of RFC 5787Bis.      |
|      |  spaces in the ASON naming  |                                 |
|      |          syntax :           |                                 |
|      |1. A Routing Area name space.|                                 |
|      | 2. A subnetwork name space. |                                 |
|      |3. A link context name space.|                                 |
|      |                             |                                 |
|      |  G.7715.1 (2004) Sec 7.1,   |                                 |
|      |  Bullet 3: There are three  |                                 |
|      |  categories of identifiers  |                                 |
|      |   used for ASON routing:    |                                 |
|      |   transport plane names,    |                                 |
|      |control plane identifiers for|                                 |
|      |     components, and SCN     |                                 |
|      |         addresses.          |                                 |
+------+-----------------------------+---------------------------------+
|  25  |  G.7715.1 (2004) Sec 7.2,   | This is addressed in Sections 6 |
|      |Par2: It should be noted that|    and 11.1 in RFC 5787Bis.     |
|      |    in order to maintain     |                                 |
|      | functional separation among |                                 |
|      | the different ASON routing  |                                 |
|      |components, identifier spaces|                                 |
|      | should be independent from  |                                 |
|      | each other, i.e., it should |                                 |
|      |be possible to change the SCN|                                 |
|      |     addresses used for      |                                 |
|      |communication between the PCs|                                 |
|      |without affecting the routing|                                 |
|      |  adjacency between peering  |                                 |
|      |    PCs. This separation,    |                                 |
|      | however, does not mean that |                                 |
|      | identical formats cannot be |                                 |
|      | used.  For example, an IPv4 |                                 |
|      |    address format may be    |                                 |
|      |used by multiple name spaces.|                                 |
+------+-----------------------------+---------------------------------+
|  26  |G.7715.1 (2004) Sec 8.1, Par |This requirement is addressed in |
|      | 2: Multiple RCs with an RA  |Section 7.1 of RFC 5787Bis. Note |
|      |   may transform and then    | that the import/export policies |
|      |forward information to RCs at|   between OSPF instances are    |
|      |different levels. However in |outside the scope of the routing |
|      |   this case the resulting   |            protocol.            |
|      |information at the receiving |                                 |
|      |        level must be        |                                 |
|      |self-consistent; this may be |                                 |
|      | achieved using a number of  |                                 |
|      |         mechanisms.         |                                 |
+------+-----------------------------+---------------------------------+
|  27  |G.7715.1 (2004) Sec 8.1, Par | This requirement is address in  |
|      | 5: An RP using a link state |Sections 7, 7.1, and 7. 2 or RFC |
|      |  protocol must support the  |            5787Bis.             |
|      | passing of reachability and |                                 |
|      | topology information to and |                                 |
|      |  from its adjacent levels.  |                                 |
|      |G.7715.1 (2004) Sec 8.1.1.2: |                                 |
|      |    Level N+1 to Level N     |                                 |
|      |  Reachability and Topology  |                                 |
|      |G.7715.1 (2004) Sec 8.1.1.3: |                                 |
|      |    Level N to Level N+1     |                                 |
|      |  Reachability and Topology  |                                 |
+------+-----------------------------+---------------------------------+
|  28  |G.7715.1 (2004) Sec 8.1.1.5: | Inter-level RC communication is |
|      |  Method for Interlevel RC   |         not addressed.          |
|      |        communication        |                                 |
+------+-----------------------------+---------------------------------+
|  29  |G.7715.1 (2004) Sec 8.4: The |OSPF supports many types of links|
|      | protocol should support all | and adjacencies as described in |
|      |  the types of adjacencies   |RFC 2328. The Traffic Engineering|
|      | described in G.7715/Y.1706, |(TE) link attributes as described|
|      |         section 9.          |  in RFC 3630 include the Link   |
|      |                             |              Type.              |
+------+-----------------------------+---------------------------------+
|  30  |G.7715.1 (2004) Sec 9.1: The | Given that the transport layer  |
|      |  routing protocol must be   |routing attributes are advertised|
|      | applicable to any transport | in opaque LSAs as described in  |
|      | network layer (e.g., G.805, |RFC 5250, OSPF is independent of |
|      |G.872) and the representation|the underlying transport network |
|      |of routing attributes should |layer. Given the extendibility of|
|      |     not preclude their      |OSPF TE as described in RFC 3630 |
|      |   applicability to other    | and RFC 4203, future transport  |
|      |  transport network levels,  |layers can be accommodated. OSPF |
|      |     existing or future.     |   TE extendibility is further   |
|      |                             |demonstrated by the existence of |
|      |                             | a large number of CCAMP drafts  |
|      |                             |   and RFCs extending OSPF TE.   |
+------+-----------------------------+---------------------------------+
|  31  |G.7715.1 (2004) Sec 9.3: All |The mapping of the RA ID to OSPF |
|      |  advertisements contain a   |Area ID is described in Section 2|
|      |common set of administrative |of RFC 5785Bis. The mapping of RC|
|      | information elements. These |ID to OSPF Router ID is described|
|      |        elements are:        |  in Section 3 of RFC 5787Bis.   |
|      |    o RA ID of which the     |    Unique identification and    |
|      |  advertisement is bounded.  | determining if an advertisement |
|      |    o RC ID of the entity    |has been updated is described in |
|      |generating the advertisement.|   RFC 5787Bis. Note that the    |
|      |  o Information to uniquely  |protocol requires the examination|
|      |  identify advertisements.   |  of the contents to determine   |
|      | o Information to determine  |   whether or not the LSA has    |
|      |whether an advertisement has |changed from the last origination|
|      |        been updated.        |    or if it is simply being     |
|      |  o Information to indicate  |  refreshed. Section 7.2 in RFC  |
|      |            when             |5787Bis addresses the requirement|
|      |an advertisement comes from a|to determine if an advertisement |
|      |      different level.       |  comes from a different level.  |
|      |                             | This is always the most recent  |
|      |                             |level from which it was exported.|
+------+-----------------------------+---------------------------------+
|  32  |  G.7715.1 (2004) Sec 9.4:   |This is addressed in Section 4 of|
|      |  Reachability Information:  |          RFC 5787Bis.           |
|      |  Reachability information   |                                 |
|      |    describes the set of     |                                 |
|      |endpoints that are reachable |                                 |
|      | by the associated node.  It |                                 |
|      |may be advertised either as a|                                 |
|      |set of UNI Transport Resource|                                 |
|      | addresses/address prefixes, |                                 |
|      | or a set of associated SNPP |                                 |
|      |  IDs/SNPP ID prefixes, the  |                                 |
|      | selection of which must be  |                                 |
|      |    consistent within the    |                                 |
|      |      applicable scope.      |                                 |
+------+-----------------------------+---------------------------------+


---------- Forwarded message ----------
From:  <Internet-Drafts@ietf.org>
Date: Mon, Apr 11, 2011 at 10:00 PM
Subject: I-D Action:draft-malis-ccamp-rfc5787bis-03.txt
To: i-d-announce@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.

       Title           : Updates to ASON Routing for OSPFv2 Protocols
(RFC 5787bis)
       Author(s)       : A. Malis, A. Lindem
       Filename        : draft-malis-ccamp-rfc5787bis-03.txt
       Pages           : 27
       Date            : 2011-04-11

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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-malis-ccamp-rfc5787bis-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/