Subject: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 31 Aug 2012 18:02:36 +0100

Here is Dimitri's Routing Dir review. Many thanks for the review.

Lou, you can address this and the other comments and post a new revision.

Adrian

> -----Original Message-----
> From: Papadimitriou, Dimitri (Dimitri) [mailto:dimitri.papadimitriou@alcatel-
> lucent.com]
> Sent: 31 August 2012 13:23
> To: BRUNGARD, DEBORAH A; [email-masked]; [email-masked];
> [email-masked]
> Subject: Review of draft-ietf-ccamp-assoc-ext-04
> 
> Hi All,
> 
> Here below the review of this document.
> 
> Technical comments:
> 
> - Example 3: isn't this extension also not updating RFC 2205 ?
> 
> - The statement "In order to support the more general usage of the
> ASSOCIATION object," is actually not correct RFC 4872 doesn't prevent support
of
> other usage of the ASSOCIATION object. It has just documented its usage in the
> GMPLS recovery context.
> 
> - Section 3.1, "Cross-session association  based on Path state is defined in
> [RFC4872]." the latter defines cross-LSP association within the same session
(not
> cross-session association) but nothing prevents extending usage to cross-
> Session.
> 
> - Section 3.1.2 the statement "the definition SHOULD allow for association
based
> on identical ASSOCIATION objects" is not clear, does it that the information
> elements part of the object shall be identical ?
> 
> - Section 3.1.2 "The Association ID field MUST be set to a value that uniquely
> identifies the sessions to be associated within the context of the Association
> Source field."
>   this statement is not compatible with e.g. RFC 4873 and 4872 where
Association
> ID are set to LSP ID and not sessions while it is stated in 3.1 " This section
does not
> modify processing required to support [RFC4872] and [RFC4873], and which is
> reviewed in Section 3 of [RFC6689]. " and in RFC 4873/Section 3.2 "The
> ASSOCIATION object is used to associate different LSPs with each other."
> 
> - Section 3.1.2 "An association is deemed to exist when the same values are
> carried in all fields of the ASSOCIATION objects being compared." this
introduces
> an additional level of indirection. To associate A to B A can simply refer to
an
> identifier of B (and vice versa), A doesn't need to have an additional ID
(e.g. C)
> that is also associated to B. Generalization would consist here in introducing
an
> ext.association ID common to A, B, and C. In other terms, generalizing the
notion
> of association doesn't require the introduction of an additional level of
> indirection.
> 
> - Section 3.2.2 I understand triggers for Resv-initiated associations aren't
> documented but how to prevent a sender willing to demote receiver-driven
> associations ?
> 
> - Section 3.1.2 and 3.2.2 no error processing is being documented whereas mis-
> match in association should be considered as a generic error.
> 
> - Section 3.3 states "Since the admission control function is outside the
scope of
> RSVP,..." are you sure ? admission control is an intrinsic function associated
to RFC
> 2205 (there are errors documented for admission control failures). I think you
> mean that the inner working of the mechanisms used by nodes to determine if
> they have sufficient available resources to support incoming requests.
> 
> - Section 4. "[RFC4872] defines the IPv4 ASSOCIATION object and the IPv6
> ASSOCIATION object. As defined, these objects each contain an Association
> Source field and a 16-bit Association ID field. The combination of the
Association
> Source and the Association ID uniquely identifies the association." but in the
> context RFC 4872 this association is defined in the context of the same tunnel
> end-point (and actually the same for RFC 4873 which relies on MBB as defined
in
> RFC 3209)
> 
> - Section 4: How is the following use case "There are scenarios where this
number
> is insufficient. (For example where the association identification is best
known
> and identified by a fairly centralized entity, which therefore may be involved
in a
> large number of associations.)" related to those proposed in the introduction.
?
> 
> - Section 4: I don't question the requirement stated in "Per [RFC6370],
MPLS-TP
> LSPs can be identified based on an operator unique global identifier.  The
> [RFC6370] defined "global identifier", or Global_ID, is based on [RFC5003] and
> includes the operator's Autonomous System Number (ASN)." the question is why
> the information is best encoded as part of the ASSOCIATION object ? isn't this
an
> LSP ATTRIBUTE or a Session Name ?
> 
> - Section 4.2: states "It is important to note that Section 4 defines
association
> identification  based on ASSOCIATION object matching, and that such matching
is
> based on the comparison of all fields in a ASSOCIATION object (unless type-
> specific comparison rules are defined).  This applies equally to  ASSOCIATION
> objects and Extended ASSOCIATION objects." any association is based on a form
> of matching, point here is that the matching and the identification of the
initiation
> of the matching information are distinct information entities (difference
between
> WHO and WHAT). I suggest to make a clearer distinction and specify setting and
> processing accordingly.
> 
> - Section 4.2: shouldn't "error processing" being documented ? Example include
> admission control where receiving node rejects the incoming Path msg if the
> originating Global_ID/Ext.ASSOCIATION object isn't included, unauthorized
> Global ID ? etc. but also mismatches between Association source and Global
> Association source ?
> 
> - Section 4.1 and 4.2: the former states "The [RFC6370] defined global
identifier,
> or Global_ID, is based on [RFC5003] and includes the operator's Autonomous
> System Number (ASN)." while the latter "the use of the Global_ID is not
related
> to the use of the ASN in protocols such as BGP." which one applies ?
> 
> - Section 5 Documenting means to prevent/mitigate mis-association(s) and
> possible impact on security would be advisable. If this is felt to be
"application" or
> "type" specific a recommendation should be stated that the security mechanisms
> have to be documented as part of these documents.
> 
> 
> Editorials:
> 
> - Introduction: "This document expands the possible usage of the ASSOCIATION
> object to
>   non-GMPLS and non-recovery contexts." Suggested to state the actual the
> scope includes RSVP (instead of what it is not)
> 
> - Introduction: s/different ports/different destination (dst) ports
> 
> - Section 2 would better refer to a "Generalization" rather than a
"modification"
> 
> - Section 3 states "As defined by [RFC4872] and reviewed in [RFC6689],..." but
an
> information RFC doesn't review   at best "documents" certain usage. This
> statement is repeated at multiple places.
> 
> - Section 3 mentions "Object usage in both Path and Resv messages is
discussed.
> The usage applies equally to
>    GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209] and non-LSP RSVP sessions
> [RFC2205], [RFC2207], [RFC3175] and [RFC4860]." having such statement in the
> introduction would desirable.
> 
> 
> -----
> Homepage:
> <http://belllabs.be/people/dpapadimitriou/>
> <http://psg.com/~dpapadimitriou>