Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols
draft-ietf-ccamp-rfc5787bis-06

[Ballot comment]
This is a well written document.

Since the security of this mechanism is fundamentally associated with the security of OSPF, an informational reference to draft-ietf-karp-ospf-analysis would seem useful to the reader.

[Ballot comment]
- 6.1 says the router IDs SHOULD NOT be zero but I don't
get when it'd be ok for zero to be used (just asking as
its always good to say when going against a SHOULD NOT
is fine).

- I wondered if the combination of exporting routing
information up, down and sideways, and dealing with
not-quite overlapping ASON and OSPF hierarchical
concepts might increase the probability of error here to
the point where this draft ought say something about
that. I don't know the answer, just asking.

- Is the definition of looping in 7.2 appropriate? Why
are only ASON-specific loops considered? Why not
consider anything that causes a routing loop,
regardless?

- 7.2.1, 2nd last para, should that "must" be a "MUST"
in "The RA ID value must be a unique identifier for the
RA within the ASON routing domain."

- I was surprised not to see the string "ASON" in any of
the TLV names defined here.

- Section 9, 2nd para: How can message authentication
improve security against passive attacks? Seems plain
wrong. Adding crypto for integrity/authenticaiton is
purely to prevent/detect active attacks. My suggestion
is to do s/secure against passive attacks and//

- Section 9, 3rd para: Signatures do not by themselves
provide stronger security than MACs. That all depends on
key management and specific algorithms. I'd argue to
just delete that paragraph.

[Ballot discuss]
This is a well written document.

Since the security of this mechanism is fundamentally associated with the security of OSPF, an informational reference to draft-ietf-karp-ospf-analysis would seem useful to the reader.

[Ballot discuss]

- I'm confused by the mixture of the wg moving this from
experimental to standards track, but also there being no
public statements related to implementations, as the
writeup states. Does that all add up to RFC 5787 having
just been a thought experiment? When I finally got to
appendix C, it says there is implementation and interop
testing which confused me even more;-)

[Ballot comment]

- 6.1 says the router IDs SHOULD NOT be zero but I don't
get when it'd be ok for zero to be used (just asking as
its always good to say when going against a SHOULD NOT
is fine).

- I wondered if the combination of exporting routing
information up, down and sideways, and dealing with
not-quite overlapping ASON and OSPF hierarchical
concepts might increase the probability of error here to
the point where this draft ought say something about
that. I don't know the answer, just asking.

- Is the definition of looping in 7.2 appropriate? Why
are only ASON-specific loops considered? Why not
consider anything that causes a routing loop,
regardless?

- 7.2.1, 2nd last para, should that "must" be a "MUST"
in "The RA ID value must be a unique identifier for the
RA within the ASON routing domain."

- I was surprised not to see the string "ASON" in any of
the TLV names defined here.

- Section 9, 2nd para: How can message authentication
improve security against passive attacks? Seems plain
wrong. Adding crypto for integrity/authenticaiton is
purely to prevent/detect active attacks. My suggestion
is to do s/secure against passive attacks and//

- Section 9, 3rd para: Signatures do not by themselves
provide stronger security than MACs. That all depends on
key management and specific algorithms. I'd argue to
just delete that paragraph.

IANA has reviewed draft-ietf-ccamp-rfc5787bis-05 and has the following comments:

IANA understands that, upon approval of this document, there are
three actions which IANA must complete.

First, in the Types for sub-TLVs of TE Link TLV (Value 2) subregistry of the
Open Shortest Path First (OSPF) Traffic Engineering TLVs registry located at:

http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlvs.xml

three new sub-TLVs of the TE Link TLV will be registered as follows:

Value: [ tbd ]
Sub-TLV: Local and Remote TE Router ID sub-TLV
Reference: [ RFC-to-be ]

Value: [ tbd ]
Sub-TLV: Inter-RA Export Upward sub-TLV
Reference: [ RFC-to-be ]

Value: [ tbd ]
Sub-TLV: Inter-RA Export Downward sub-TLV
Reference: [ RFC-to-be ]

Second in the Types for sub-TLVs of TE Node Attribute TLV (Value 5) subregistry
of the Open Shortest Path First (OSPF) Traffic Engineering TLVs registry
located at:

http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlvs.xml

three new sub-TLVs of the Node Attribute TLV will be registered as follows:

Value: 5
Sub-TLV: Local TE Router ID sub-TLV
Reference: [ RFC-to-be ]

Value: [ tbd ]
Sub-TLV: Inter-RA Export Upward sub-TLV
Reference: [ RFC-to-be ]

Value: [ tbd ]
Sub-TLV: Inter-RA Export Downward sub-TLV
Reference: [ RFC-to-be ]

Third a new subregistry will be created in the Open Shortest Path First (OSPF)
Traffic Engineering TLVs registry located at:

http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlvs.xml

The new registry will be called "Types for sub-TLVs of Router Address TLV
(Value 1)"

The registration policy for this new registry is as follows:

Types in the range 0-32767 are to be assigned via Standards Action.

Types in the range 32768-32777 are for experimental use; these will not be
registered with IANA, and MUST NOT be mentioned by RFCs.

Types in the range 32778-65535 are not to be assigned at this time. Before any
assignments can be made in this range, there MUST be a Standards Track RFC that
specifies IANA Considerations that covers the range being assigned.

There are two initial registrations in this subregistry, as follows:

Value: [ tbd ]
Sub-TLV: Inter-RA Export Upward sub-TLV
Reference: [ RFC-to-be ]

Value: [ tbd ]
Sub-TLV: Inter-RA Export Downward sub-TLV
Reference: [ RFC-to-be ]

IANA understands that these are the only actions required upon approval
of this document.

Note: The actions requested in this document will not be completed until
the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (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'
  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@ietf.org mailing lists by 2012-08-17. Exceptionally, comments may be
sent to iesg@ietf.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.

State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
Hi,

I have done my usual AD review prior to putting the draft forward for
IETF last call and IESG review. I have a number of questions and issues
that I would like you to address in a new revision. Some of these things
are questions that can be handled either by discussion or by making
changes to the draft. Other issues are more substantive and will need
updates  to the document.

I have move the draft into Revised I-D needed, and will wait for the
new revision.

Thanks,

Adrian

---

If I understand correctly, the intention of this doument is to entirely
replace (i.e. obsolete) RFC 5787. That's OK, but you need to do several
things:

1. State in the document header
Obsoletes: 5787 (if approved)

2. Remove "Updates to" and "(RFC 5787bis)" from the document title

3. Add a statement to the Abstract (usually the last sentence) to say
"This document obsoletes RFC 5787"

4. Add a final paragraph to summarise why this document obsoletes
  RFC 5787 and to mention the change to standards track.

5. Include a section called "Changes from RFC 5787"

---

Section 2

  RAs are hierarchically contained: a higher-level (parent) RA contains
  lower-level (child) RAs that in turn MAY also contain RAs, etc.

Why MAY not may?
Why "etc." ?

---

Please expand acronyms on first use. For example SCN.

---

Section 3

  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 transport plane name space.  The TE Router ID
  should not be confused with the OSPF Router ID which uniquely
  identifies an OSPF router within an OSPF routing domain [RFC2328] and
  is in a name space for control plane components.

  Note: The Router Address top-level TLV definition, processing, and
  usage are unchanged from [RFC3630].  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.

Note that RFC 3630 does not define a "TE Router Address TLV" You seem to
recognize this in the second paragraph.

You seem to acknowledge that the Router Address TLV contains a stable
OSPF TE node IP address that is always reachable when there is IP
connectivity to the associtated OSPF TE node. As far as I can tell, this
means that the address comes from the SCN space not from the transport
name space as you have claimed.
                                                                   
It may be that you need or desire some overlap of spaces, but you have           
not made any statement to that effect.

In fact I am surprised that you say that there is a 1:1 correspondence
between a transport node and an OSPF TE node. This sounds like an
implementation detail unless an OSPF TE node is a logical concept. If it
is, it would be really  useful to explain it.

It does not help that you have not defined "OSPF TE node" and you freely
mix that term with the term "OSPF router". It should be clear to you
that there are OSPF protocol speakers and there are transport nodes on
behalf of which the protool speakers distribute information.

Please have another attempt at this section making clear what the OSPF
entities are and how they map to actual things. You obviously did not
like the content of Section 5.1 of RFC 5787, but you seem to have thrown
out the baby with the bathwater.

Furthermore, in Section 6 you have

  Hence, a single OSPF router (i.e., the PC) MUST be able to advertise
  on behalf of multiple transport layer nodes. The OSPF routers are
  identified by OSPF Router ID and the transport nodes are identified
  by TE Router ID.                                                             

which is very good, but appear to contradict

  In the context of OSPF Traffic Engineering (TE), an ASON transport
  node corresponds to a unique OSPF TE node.

Probably you intend to say that an ASON transport node is represented by
a single OSPF TE node and that an OSPF TE node may represent more than
one ASON transport node. You haven't actually excluded that in what you
write, but it is not very clear.

---

Section 4

  Reachability in ASON refers to the set of endpoints reachable in the
  transport plane by a node or the reachable endpoints of a level N.
                           
Can you please rewrite this for clarity. "Reachability" cannot refer to
a set of anything per se; it is a quality. The definition also seems               
circular since you do not define what reachable means.

---

Section 4

"(ASON SNPP name space)"

What is this? You have already told us that ASON has just three name
spaces and this was not one of them.

What is SNPP?

---

Section 4

You say:

  The data plane node is
  identified in the control plane by its TE Router ID, as discussed in
  section 6.

This contradicts what you say in Section 3 where the TE Router ID is an
IP reachable address and so is an SCN identifier not a control plane
identifier.

---

Section 4

  As a consequence, it MUST
  be possible for the router to originate more than one TE LSA
  containing the Node Attribute TLV when used for ASON reachability
  advertisement.

  Hence, the Node Attribute TLV [RFC5786] advertisement rules must be
  relaxed for ASON. A Node Attribute TLV MAY appear in more than one TE
  LSA originated by the RC when the RC is advertising reachability
  information for a different transport node identified by the Local TE
  Router Sub-TLV (refer to section 6.1).

This looks like you are updating RFC 5786.

You will need to make this explicit and to assure me that the OSPF
working group has signed off on this change.
                                                             
Since you are making the relaxation specific to ASON (or are you making
it general?) you will need to explain how a node receiving a second TE
LSA containing a node attribute TLV will know that it is an ASON
advertisement.

---

Section 5.2

  GMPLS routing defines an Interface Switching Capability Descriptor
  (ISCD) that provides, among other things, the available
  (maximum/minimum) bandwidth per priority available for Label Switched
  Path (LSPs).

- Too many instances of "available"
- The ISCD doesn't provide the bandwidth, only the information about the
  bandwidth

---

Section 6

  For ASON routing, the control plane component routing adjacency
  topology (i.e., the associated Protocol Controller (PC) connectivity)
  and the transport topology are NOT assumed to be congruent [RFC4258].

Lower case "not" please.

---

Section 6

  The Router Address TLV [RFC3630] is used to advertise the TE Router
  ID associated with the advertising Routing Controller. TE Router IDs
  for additional transport nodes are advertised through specification
  of the Local TE Router Identifier in the Local and Remote TE Router
  TE sub-TLV and the Local TE Router Identifier sub-TLV described in
  the sections below. These Local TE Router Identifiers are typically
  used as the local endpoints for TE Label Switched Paths (LSPs)
  terminating on the associated transport node.

I found this a bit odd. Previously you have said that a TE Router ID is
associated with a transport node that it identifies. Now you seem to be
saying that a TE Router ID is associated with an RC, and implying that
an RC is a transport node (since you say "for additional transport
nodes").

---

Section 6

  It MAY be feasible for multiple OSPF Routers to advertise TE
  information for the same transport node. However, this is not
  considered a required use case and is not discussed further.

The use of "MAY" is in the wrong scope. How about...

  The use of multiple OSPF Routers to advertise TE information for the
  same transport node is not considered a required use case and is not
  discussed further in this document.

---

Section 6.1

  An OSPF router advertising on behalf of multiple transport nodes will
  require additional information to distinguish the link endpoints               
  amongst the subsumed transport nodes. In order to unambiguously
  specify the transport topology, the local and remote transport nodes
  MUST be identified by TE router ID.

"subsumed" seems a bit dramatic!
How about...

  When an OSPF Router advertises on behalf of multiple transport nodes,
  the link end points cannot be automatically assigned to a single
  transport node associated with the advertising router. In this case,
  the link advertisement also includes identifiers of the link end
  points.                                                 

---

Section 6.1

  The Type field of the Local and Remote TE Router ID sub-TLV is
  assigned the value 26 (see Section 10).

AFAICS, no early allocation was performed. Therefore, please replace
"26" with TBDx.

Similarly in

    0                  1                  2                  3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Type (26)          |          Length (8)          |

---

Section 6.1

  The value of the Local and Remote TE Router
  Identifier SHOULD NOT be set to 0.

This use of "SHOULD NOT" implies that a value of 0 MAY be used for some
reason. Please clarify.

---

Section 6.1

This section reminds me to ask what plans the WG has to support IPv6.

---

Section 6.1

  This sub-TLV MUST be included as a sub-TLV of the top-level Link TLV
  if the OSPF router is advertising on behalf of one or more transport
  nodes having TE Router IDs different from the TE Router ID advertised
  in the Router Address TLV.  Therefore, it MUST be included if the
  OSPF router is advertising on behalf of multiple transport nodes.

  Note: The Link ID sub-TLV identifies the other end of the link (i.e.,
  Router ID of the neighbor for point-to-point links) [RFC3630]. When
  the Local and Remote TE Router ID Sub-TLV is present, it MUST be used
  to identify local and remote transport node endpoints for the link
  and the Link-ID sub-TLV MUST be ignored. The Local and Remote ID sub-
  TLV, if specified, MUST only be specified once.

A lot of "MUST" without explaining what the process is if not.

A receiver getting no sub-TLV assumes what?
A router advertising on behalf of the transport node with the same TE
Router ID MAY / MUST NOT include sub-TLVs.
If there is more than one sub-TLV present the receiver should do what?
Does "Therefore, it MUST be included if the OSPF router is advertising
  on behalf of multiple transport nodes" imply the sub-TLV must be
  included even when the advertisement is for the transport node with
  the same TE Router ID?

---

Section 6.2

Per previous comments on IANA

Please change "5" to TBDy in...

  The Type field of the Local TE Router ID sub-TLV is assigned the
  value 5 (see Section 10).  The Length field takes the value 4.  The

...and...

    0                  1                  2                  3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          ...
  |            Type (5)          |          Length (4)          |

---

Section 6.2

  This sub-TLV MUST be included as a sub-TLV of the top-level Node
  Attribute TLV if the OSPF router is advertising on behalf of one or
  more transport nodes having TE Router IDs different from the TE
  Router ID advertised in the Router Address TLV.  Therefore, it MUST
  be included if the OSPF router is advertising on behalf of multiple
  transport nodes.

Similar questions as per 6.1.

What can a receiver assume if the sub-TLV is not present?
Does the final sentnece mean that the sub-TLV must be included even in
  the case where the advertisement is for the same TE Router ID?
Can the sender include the sub-TLV when it only advertises for a single
  transport node?
What if there is more than one sub-TLV present?

---

Section 7

  An ASON routing area (RA) represents a partition of the data plane,
  and its identifier is used within the control plane as the
  representation of this partition.  An RA may contain smaller RAs
  inter-connected by links.  ASON RA levels do not map directly to OSPF
  areas. Rather, hierarchical levels of RAs are represented by separate
  OSPF protocol instances.

It would be interesting to add a statement about the correspondence
between RAs and OSPF areas (per section 2).

---

Section 7

It isn't clear to me reading this section and the subsections whether
export happens at a single node that is present in both parent and child
RA, or whether there is an "export interface" between nodes. I would
assume that an implementation could place the export within a box, but
that there is no architectural constraint. That means that the export
function is an exposed function. If so, where is the protocol
definition?

---

Section 7.2.1

IANA stuff again

Please replace:
27 as TBDz1
28 as TBDz2

in...
  The type value 28 (see
  Section 10) will indicate that the associated routing information has
  been exported downward. The type value 27 (see Section 10) will
  indicate that the associated routing information has been exported
  upward.
and in...
  The Type field of the Inter-RA Export Upward and Inter-RA Export
  Downward sub-TLVs are respectively assigned the values 27 and 28 (see
  Section 10).

and...
    0                  1                  2                  3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Upward/Downward Type (27/28)  |          Length (4)          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

Section 7.2.2

  When exporting routing information upward in the ASON routing
  hierarchy, any information received from a level above, i.e., tagged
  with an Inter-RA Export Downward Sub-TLV, MUST NOT be exported
  upward. Since an RA at level N is contained by a single RA at level
  N+1, this is the only checking that is necessary and the associated
  RA ID is used solely for informational purposes.

Agreed.
And what should the receiver do if it receives such an export?

Ditto for

  In                                 
  order words, routing information MUST NOT be exported downward into
  the RA from which it was received.

---

Section 8

  The extensions described herein are only applicable to ASON routing
  domains and it is not expected that the attendant reachability (see         
  Section 4) and link information will ever be mixed with global or
  local IP routing information.

I am not quite sure what you mean by "mixed" or by "local IP routing
information". You may be saying that you expect (require?) that TE
information s exchanged in a separate instance of OSPF than is used
for exchanging SCN routing information.                     

If that is what you are hoping for, I expect you will be sadly
disappointed by the entire deployed GMPLS base. For a single RA it
makes complete sense to run just one instance of OSPF that exchanges
information about SCN IP reachability and also transport plane TE info.

It gets more complicated with a multi-RA system, and you need to address
that.

---

Section 8

You give some good advice, but you do it with nested 2119 language. I
don't know how to interpret "You SHOULD apply a MUST".

Additionally, since you say "SHOULD", you need to explain what the
associated MAY condition is.

---

Section 9

Here is an attack vector...

Suppose a small child RA is infiltrated. A very large (unmanageably
large) number of LSAs are exported to the parent. This may swamp the
parent making it impossible for it to function. Additionally, the
parent may export all the LSAs to another child (which being a child)
has less processing capabilities.

The implication is that the policy points at import/export need to be
capable of providing policing and maybe able to throttle import volume.

---

Section 10

As previously discussed, there was no early allocation.

Please delete

  This draft requests early allocation of IANA code points in
  accordance with [RFC4020]. [NOTE TO RFC Editor: this paragraph and
  the RFC 4020 reference can be removed during RFC editing].

---

Section 10.1

OLD
  - Local and Remote TE Router ID sub-TLV (26)
  - Inter-RA Export Upward sub-TLV (27)
  - Inter-RA Export Downward sub-TLV (28)
NEW
  - Local and Remote TE Router ID sub-TLV (TBDx)
  - Inter-RA Export Upward sub-TLV (TBDz1)
  - Inter-RA Export Downward sub-TLV (TBDz2)
END

---

Section 10.2

OLD
      - Local TE Router ID sub-TLV (5)
      - Inter-RA Export Upward sub-TLV (27)
      - Inter-RA Export Downward sub-TLV (28)
NEW
      - Local TE Router ID sub-TLV (TBDy)
      - Inter-RA Export Upward sub-TLV (TBDz1)
      - Inter-RA Export Downward sub-TLV (TBDz2)
END

---

Section 10.3

OLD
      - Inter-RA Export Upward sub-TLV (27)
      - Inter-RA Export Downward sub-TLV (28)
NEW
      - Inter-RA Export Upward sub-TLV (TBDz1)
      - Inter-RA Export Downward sub-TLV (TBDz2)
END

---

Section 12

  The following table shows how this draft complies with the

s/draft/document/

  to that requirement, and the fourth column lists the relevant section
  in draft, and/or another RFC that already satisfies the requirement.

s/in draft/in this document/

---

Section 12

  | 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.  |              |            |

But you only recommend that correspondence. So what happens to this
requirement if RA does not map to OSPF Area? Should you address this
case, or should you require the correspondence?

---

Section 12

  | 3.2 (8)  |    Routing Information    |  No - Not    |            |
  |          |exchanged between levels N |  described.  |            |
  |          | and N+1 via external link |              |            |
  |          |    (inter-RA links).    |              |            |

and

  | 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.    |              |            |

I think this ties to my question on section 7.
I think you should make clearer in the preamble that you are only
addressing the case where the level boundary occurs within an RC.
Since you are doing this work to address a need from the OIF where layer
boundaries have typically been exposed through an external protocol
interface, I am a little puzzled by your choice to limit your work.
Maybe a figure in an early section would show how RAs and RCs are
presented in the part of the problem you are solving.

---

Section 12

  | 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).            |              |            |

Does "automation requirement is ambiguous" mean "automation not
supported"?

---

Section 12

  |  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.    |              |            |

Surely this requirement demands a section explaining how the function is
achieved.

---

Section 14

It is usual to inherrit acknowledgements from the obsoleted RFC where
there is a ot of shared text.

You should also thank any external SDO that was consulted through a
liaison process.

---

Appendix A Management domain

Text format problem

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Deborah Brungard is the Document Shepherd.

She has reviewed the document and believes it is ready for
forwarding to the IESG for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

This document has been adequately reviewed. In addition, it was
Liaisoned with ITU-T. It was previously published with Experimental
Status, some minor updates have been incorporated.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No concerns.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No concerns or issues. No IPR found in the datatracker.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is very good consensus behind this document. It was moved to
Standards track based on significant interest expressed by the working group.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts
Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate
Checks are not enough; this check needs to be thorough. Has the
document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Split looks okay.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA section looks good.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Yes, no automated checks needed.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

The ITU-T has defined an architecture and requirements for
operating an Automatically Switched Optical Network (ASON). This
document defines extensions to the OSPFv2 Link State Routing Protocol
to meet the requirements for routing in an ASON.


Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

This document received much attention and discussion in its early
revisions. The document has been stable for quite some time, mainly needing
revisions as part of the publication process for Standards Track.

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

There have been no public statements related to implementations, though
significant interest was expressed when the working group was polled for
interest in moving to standards track.