[CCAMP] draft-ietf-ccamp-rfc5787bis

["Adrian Farrel" <[e-mail]>]

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 document 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 associated 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 protocol 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 sentence 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 inherit acknowledgements from the obsoleted RFC where
there is a lot of shared text.

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

---

Appendix A Management domain

Text format problem