Re: [CCAMP] draft-ietf-ccamp-rfc5787bis

Adrian,

Thanks! The authors are reviewing your comments now. We'll let you
know if we have any questions or concerns.

Cheers,
Andy

On Fri, Nov 25, 2011 at 11:43 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
> 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
>
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp