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

["Papadimitriou, Dimitri (Dimitri)" <[e-mail]>]

Lou,

> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: Wednesday, September 05, 2012 19:15
> To: Papadimitriou, Dimitri (Dimitri)
> Cc: [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04
>
> Dimitri (BTW sorry about the dropping the t in my last message)
>
>       See below.
>
> On 9/5/2012 12:08 PM, Papadimitriou, Dimitri (Dimitri) wrote:
> > Hi Lou,
> >
> >> -----Original Message-----
> >> From: Lou Berger [mailto:[e-mail]]
> >> Sent: Wednesday, September 05, 2012 14:36
> >> To: Papadimitriou, Dimitri (Dimitri)
> >> Cc: [e-mail];
> >> [e-mail]; [e-mail]
> >> Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04
> >>
> >> Hi Dimiri,
> >>       Responses in line...
> >>
> >> On 9/5/2012 3:43 AM, Papadimitriou, Dimitri (Dimitri) wrote:>  Lou,
> >>>
> >>> see below,
> >>>
> >>>> -----Original Message-----
> >>>> From: [e-mail]
> >>>> [mailto:[e-mail]] On Behalf Of Lou Berger
> >>>> Sent: Tuesday, September 04, 2012 23:54
> >>>> To: Papadimitriou, Dimitri (Dimitri)
> >>>> Cc: [e-mail];
> >>>> [e-mail]; [e-mail]
> >>>> Subject: Re: [RTG-DIR] FW: Review of
> draft-ietf-ccamp-assoc-ext-04
> >>>>
> >>>> Dimitri,
> >>>>       See below.
> >>>>
> >>>> On 9/4/2012 4:52 PM, Papadimitriou, Dimitri (Dimitri) wrote:
> >>>>> Hi Lou,
> >>>>>
> >>>>> See inline:
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Lou Berger [mailto:[e-mail]]
> >>>>>> Sent: Tuesday, September 04, 2012 17:25
> >>>>>> To: [e-mail]; Papadimitriou, Dimitri (Dimitri)
> >>>>>> Cc: [e-mail];
> >> [e-mail]
> >>>>>> Subject: Re: [RTG-DIR] FW: Review of
> >> draft-ietf-ccamp-assoc-ext-04
> >>>>>>
> >>>>>> Adrian,
> >>>>>>       Much Thanks. (BTW is there a reason not to include the
> >>>>>> WG in this, or
> >>>>>> such, discussions?)
> >>>>>>
> >>>>>> Dimitri,
> >>>>>>       Please see below for inline responses.
> >>>>>>
> >>>>>> On 8/31/2012 1:02 PM, Adrian Farrel wrote:
> >>>>>>> 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; [e-mail];
> >> [e-mail];
> >>>>>>>> [e-mail]
> >>>>>>>> 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 ?
> >>>>>>
> >>>>>> Yes. This is stated in the header, abstract and section 3.
> >>>>>
> >>>>> I thought to include this in the introduction since other
> >>>> updated RFC are indicated.
> >>>>>
> >>>>
> >>>> Agreed.  Text has been added.
> >>>
> >>> OK.
> >>>
> >>>>>>>> - 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.
> >>>>>>
> >>>>>> I'm not sure how these two statements (the document text
> >>>> and your last
> >>>>>> sentence) are mutually inconsistent.  I see no text change
> >>>>>> based on this comment.
> >>>>>
> >>>>> I meant: "In order to document the more general usage of
> >>>> the ASSOCIATION object, ..."
> >>>>>
> >>>>
> >>>> While I don't mind the change in this part of the sentience,
> >>>> the result
> >>>> is a bit odd "In order to document the more general usage of the
> >>>> ASSOCIATION object, this document ..." So will leave as is.
> >>>
> >>> "In order to document the more general usage of the ASSOCIATION
> >> object, this specification ..."
> >>
> >> I think we're in the noise here...
> >>
> >>>>>>>> - 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.
> >>>>>>>>
> >>>>>>
> >>>>>> I see no text change requested based on this comment.
> >>>>>
> >>>>> I meant: "Cross-LSP association based on Path state is
> defined in
> >>>>> [RFC4872]; here we document cross-session association..."
> >>>>
> >>>> I'll change two instances of "Cross-session association"
> >> to "Cross-LSP
> >>>> association".
> >>>
> >>> OK.
> >>>
> >>>>>>>> - 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 ?
> >>>>>>
> >>>>>> I see no difference between the current text (object
> >>>> equivalence) and
> >>>>>> object information element equivalence.  I don't believe
> >>>>>> there's a case
> >>>>>> where you can have one without the other.  Please
> >> correct me if you
> >>>>>> think I'm mistaken.
> >>>>>
> >>>>> If the association ID are defined such that:
> >>>>>
> >>>>> - the Association ID of Session 1 or LSP 1 points to the
> >>>> Session ID or LSP ID of LSP 2
> >>>>>
> >>>>> - the Association ID of Session 2 or LSP 2 points to the
> >>>> Session ID or LSP ID of LSP 1
> >>>>
> >>>> Association based on matching Association ID to Session ID
> >> is not part
> >>>> of this draft.
> >>>
> >>> if the session ID isn't used - which is possible -
> >> documenting the ID
> >>> setting to ensure unicity (per association) is to be
> documented the
> >>> definition only states concerning value setting
> >>>
> >>> "A value assigned by the the node that originated the association.
> >>>       When combined with the other fields carried in the
> >> object, this
> >>>       value uniquely identifies an association."
> >>
> >> Actually, the document provides additional guidance in the
> procedures
> >> section:
> >>
> >>     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.  The Association Source field MUST be
> >>     set to a unique address assigned to the node originating the
> >>     association.
> >
> > The initial statement should be part of the definition in the form
> >
> > "The Association ID value space is unique per ?" I write
> "?" because is it per node, per RSVP process, per Association source ?


what about the above one concerning the unicity ?


> > The processing should in my opinion state (or equivalent):
> >
> > "The Association ID field MUST be set to a unique value
> that uniquely
> >  identifies the association between sessions that are
> associated within
> >  the context of the Association Source field."
>
> I frankly don't see any difference in the wording.


"uniquely identify the sessions to be associated"

vs

"uniquely identify the association"

is clearly different.


> >>>>> Other elements aren't necessarily identical.
> >>>>
> >>>> They must be identical in the context of this draft and
> >> the absence of
> >>>> type-specific processing rules.
> >>>>
> >>>>> The setting of the association source is application type
> >> specific.
> >>>>
> >>>> Even if true, I don't see how this impacts the text of the draft.
> >>>
> >>> Because a full match (incl.association source) wouldn't apply
> >>> anymore. I think the point goes to the question does extension
> >>> include association between sessions that uses two
> different source
> >>> addresses that can be two interface address ?
> >>
> >> sure. As documented, there is no mention of other fields
> to check as
> >> part of association identification.
> >
> > I don't get it. If the matching operation implies that all fields
> > shall be identical including the association source how do you
> > proceed ?
>
> Simple.  If the objects are identical, there's an association
> identified.  If not, there's no association.


This is not the question. If the association are set per source interface how this mechanism shall be used ? The point I am raising here is this precluded by design and it is a common case which likely to happen with the examples you have highlighted in the introduction.


> >>>>> Another case (if I am correctly understanding the related
> >> text), is
> >>>>> related to the MPLS-TP section. The association object of two
> >>>>> non-associated session can have the value fields in the
> >>>>> ext.association object.
> >>>>
> >>>> This is a true statement, but unless the contents of the
> >> whole object
> >>>> are identical, there's no association.
> >>>
> >>> In GMPLS you will have association source setting being
> >> identical for
> >>> many tunnels/LSPs (many controllers will set their local
> IP address
> >>> as source) while actually these LSPs aren't. I don't
> think there is
> >>> any indication that prevents this to happen ?
> >>
> >> Correct and this is intentional. All that is required for
> >> association is
> >> a simple match of objects.  If two nodes use the same
> source address
> >> without coordinating IDs there may be collisions, but there's
> >> no way to
> >> know if this is intentional or an error when processing
> the path/resv
> >> messages.
> >
> > OK. As such this corroborates my initial remark where the
> association
> > object was actually the most suited place to put this information.
>
> Great.  (I think.)


I meant was *not* (sorry for the confusion).


> >>>>>>>> - 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 "
> >>>>>>
> >>>>>> Section 3.1.2 applies to "Non-GMPLS and Non-Recovery Usage"
> >>>>>
> >>>>> Yes and section 3.1.2 indicates "These procedures
> >>>>>    apply equally to GMPLS LSPs, MPLS LSPs and non-LSP
> >>>> session state."
> >>>>>
> >>>>> don't you think this induces confusion ?
> >>>>
> >>>> Perhaps, but this is why the 3.1 states:
> >>>>   This section does not modify processing required to support
> >>>> [RFC4872]
> >>>>   and [RFC4873].  I'll repeat the sentence at the start of 3.1.2.
> >>>
> >>> This being said the Code point for RFC 4873 isn't changed
> but points
> >>> to this document. Any reason since there is no processing change ?
> >>
> >> I assume you're referring to the Resource Sharing type.  This
> >> is updated as the same type is now usable for non-recovery LSPs.
> >
> > OK.
> >
> >>>>>> so it does not impact to RFC 4873 and 4872
> >>>> implementations.  As stated
> >>>>>> in the draft and quoted by you:
> >>>>>>
> >>>>>>> This section
> >>>>>>> does not
> >>>>>>>> modify processing required to support [RFC4872] and
> >>>>>> [RFC4873], and which is
> >>>>>>>> reviewed in Section 3 of [RFC6689]. "
> >>>>>
> >>>>> The point I am raising is that Section 3.1 reads as there no
> >>>>> "additions" whereas once reaching Section 3.1.2 one
> >> understands that
> >>>>> the statement no modifications meant actually extensions.
> >>>>>
> >>>>> Section 3.1 states "This section does not modify processing
> >>>> required to
> >>>>>    support [RFC4872] and [RFC4873], and which is reviewed
> >>>> in Section 3
> >>>>>    of [RFC6689]. "
> >>>>>
> >>>>> Section 3.1.2 states " These procedures
> >>>>>    apply equally to GMPLS LSPs, MPLS LSPs and non-LSP
> >>>> session state."
> >>>>>
> >>>>> Hence,
> >>>>>
> >>>>> Section 3.1.2 should be rephrased as
> >>>>>
> >>>>>    "This section is based on the processing rules described
> >>>> in [RFC4872]
> >>>>>    and [RFC4873], and which is reviewed in [RFC6689].
> >>>> These procedures
> >>>>>    apply equally to GMPLS LSPs, MPLS LSPs and non-LSP
> >>>> session state."
> >>>>>
> >>>>> Section 3.1.2 should be rephrased as
> >>>>>
> >>>>>    "This section generalizes the processing rules described
> >>>> in [RFC4872]
> >>>>>    and [RFC4873], and which is reviewed in [RFC6689], for
> >>>> application
> >>>>>    to MPLS LSPs and non-LSP session state. For GMPLS
> LSP rules are
> >>>>>    extended for applications not related to the recovery
> >>>> and resource
> >>>>>    sharing."
> >>>>
> >>>> I've revised the text to read:
> >>>>
> >>>>     This section is based on, and extends, the processing rules
> >>>>     described in [RFC4872] and [RFC4873], and which is
> reviewed in
> >>>>     [RFC6689].  This section applies equally to GMPLS
> >> LSPs, MPLS LSPs
> >>>>     and non-LSP session state.  Note, as previously stated, this
> >>>>     section does not modify processing required to support
> >> [RFC4872]
> >>>>     and [RFC4873].
> >>>
> >>> OK.
> >>>
> >>>>>> 2) I also think "not compatible" is an overstatement, but
> >>>> I guess that
> >>>>>> it isn't really a critical point to discuss as the
> >> referenced text
> >>>>>> doesn't relate to [RFC4872] and [RFC4873].
> >>>>>
> >>>>> The proposed phrasing would resolve it.
> >>>>>
> >>>>>>>> and in RFC 4873/Section 3.2 "The
> >>>>>>>> ASSOCIATION object is used to associate different LSPs
> >>>>>> with each other."
> >>>>>>
> >>>>>> I see no text change requested based on this comment.
> >>>>>
> >>>>> Ditto.
> >>>>>
> >>>>>>>> - 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.
> >>>>>>
> >>>>>> I really have no idea what this comment means.  There is no
> >>>>>> indirection stated or implied by the text.
> >>>>>
> >>>>> It is the result of what the text implies and it is specifically
> >>>>> related to the "Association ID". Implicitly the
> document mandates
> >>>>> than this identifier can't take any value of existing fields
> >>>>> identifying tunnels/LSPs.
> >>>>
> >>>> Not at all.  As long as the IDs as consistently set across
> >> association
> >>>> objects, an association will be made.  Furthermore, type specific
> >>>> processing can be defined that allows implicit mapping
> such as you
> >>>> defined in 4872.
> >>>
> >>> The first item to check is the Association Type to distinguish
> >>> between matching processes. The statement "In the absence of
> >>> Association Type-specific rules for identifying
> association,.." was
> >>> probably intended to state (to remove the confusion of
> the statement
> >>> "identifying assocation"):
> >>>
> >>> "If the ASSOCIATION type does not refer to Association
> Type-specific
> >>> rules for the processing of the ASSOCIATION object (in
> >> which case the
> >>> Association Type-specific rules SHALL be applied), ..."
> >>
> >> IMO this should be left to the definition of the Association
> >> Type-specific rules, i.e., is beyond the scope of this document.
> >
> > OK.
> >
> >>>>>>  It means test for simple equivalence,
> >>>>>> i.e., (ASSOCIATION object of A) = (ASSOCIATION object of
> >>>> B) and that's
> >>>>>> it. There's no (session) ID referencing.  Can you restate
> >>>>>> your concern?
> >>>>>
> >>>>> My concern is this an equivalence between objects not an
> >>>> assocation of sessions.
> >>>>>
> >>>>
> >>>> Per this document, equivalence between objects identifies an
> >>>> assocation
> >>>> of sessions.  This document does not generalize the session ID to
> >>>> association ID matching that was part of 4872.
> >>>
> >>> The above text would clarify the point.
> >>
> >> The following has been added to the second to last paragraph
> >> of Section 1.
> >>
> >>     When using the procedures defined below, association
> is identified
> >>     based on simple ASSOCIATION object matching.  Some of the other
> >>     matching mechanisms defined in RFC 4872, e.g.,
> matching based on
> >>     Session IDs, are not generalized.
> >
> > I would write:
> >
> >       When using the procedures defined in this document,
> association is identified
> >       based on ASSOCIATION object matching.  Some of the other
> >       matching mechanisms defined in RFC 4872, e.g.,
> matching based on
> >       Session IDs, are not generalized in this document. Association
> >       type-specific processing is outside the scope of this
> document.
> >
>
> understood, I'll modify the paragraph. (subject to style differences.)
>
> >>>>>>>> - 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 ?
> >>>>>>
> >>>>>> Can you clarify this question?
> >>>>>
> >>>>> Let me put first in context. Generalization includes Rcv driven
> >>>>> associations but only additions are documented.
> >>>>>
> >>>>>> Are you asking:
> >>>>>> - how a Path sender can prevent a receiver initiated
> >>>> association? (it
> >>>>>> can't)
> >>>>>>
> >>>>>> - how a Resv sender removes an association? (it just removes
> >>>>>> the object, no different from a path message)
> >>>>>
> >>>>> The corresponding processing is to be documented.
> Because one can
> >>>>> also demote an association by having each LSP/session
> pointing to
> >>>>> itself while keeping the object in the Path/Resv message.
> >>>>
> >>>> This sounds like the implicit matching rules in 4872.
> >> Such session ID
> >>>> to association ID matching is not part of this document.
> >>>
> >>> I hear you but as the ASSOCIATION ID value setting
> doesn't state it
> >>> can't be done, you can get the same result.
> >>
> >> Sure, and this would be perfectly fine way for an implementation to
> >> select its IDs for certain possible applications, but this
> is a local
> >> implementation choice in the general case, or
> type-specific processing
> >> which is outside the scope of this document.
> >
> > OK.
> >
> >>> You could even assume that changing ID to an unused but
> value would
> >>> lead to the same result (as matching wouldn't give a
> positive result
> >>> the ASSOCIATION would also be removed since it can't be found
> >>> anymore).
> >>
> >>
> >>>
> >>>>>> - something else?
> >>>>>>
> >>>>>>>> - Section 3.1.2 and 3.2.2 no error processing is being
> >> documented
> >>>>>>
> >>>>>> I think this is a fair point.  The only case I think that
> >>>>>> can/should be
> >>>>>> addressed is unknown types.  (As is usual, per
> RFC2205, errors in
> >>>>>> formats to not trigger any specific message response.)
> >>>>>> Sections 3.1 and
> >>>>>> 3.2 only discuss identification of associations, so I
> >>>> propose adding a
> >>>>>> section 3.3.2. How about something like:
> >>>>>>
> >>>>>>   3.3.2. Unknown Association Types
> >>>>>>
> >>>>>>   A node that receives an ASSOCIATION object with an unknown
> >>>>>>   ASSOCIATION type MUST forward all received
> ASSOCIATION objects
> >>>>>>   as defined above.  The node MAY also identify
> associations per
> >>>>>>   the defined processing, e.g., to make this information
> >> available
> >>>>>>   via a management interface.
> >>>>>
> >>>>> OK. Wouldn't you document PathErr/ResvErr and Notify ?
> >>>>
> >>>> IMO Not for an unknown type.
> >>>
> >>> I don't understand the answer.
> >>
> >> I don't think unknown type should result in a PathErr/ResvErr at a
> >> transit/egress/ingress node.
> >
> > The question why do you use "unknown" type and not
> >
> > Error Code = 01: "Admission Control Failure" (see [RFC2205])
> >
> >    o "Admission Control Failure/Session Admission Failure" (6)
>
> Because I don't think lack of support of a type should result in an
> error in the general case. (for example would you generate an error on
> transit nodes for associations that are only relevant to
> end-points, or vice versa?)


How would you then allow that session to cross the network ? Thus it depends on policy on what operator wants to apply at ingress (not up to the protocol to decide/enforce a policy).


> >>>>>>>> whereas mis-
> >>>>>>>> match in association should be considered as a generic error.
> >>>>>>
> >>>>>> This isn't a detectable error case as it is impossible for
> >>>> a node to
> >>>>>> know if two association objects are intentionally or
> >>>> unintentionally
> >>>>>> different.
> >>>>>
> >>>>> Earlier, in the text it is mentioned that processing
> >>>> implies checking
> >>>>> all Path/Resv state. We have to understand that putting
> in place a
> >>>>> generic processing (outside a specific ASSOCIATION Type) renders
> >>>>
> >>>> I think this sentence got truncated...
> >>>
> >>> ... safeguard rule advisable.
> >>>
> >>>>>>>> - Section 3.3 states "Since the admission control function
> >>>>>> is outside the
> >>>>>>> scope of
> >>>>>>>> RSVP,..." are you sure ?
> >>>>>>
> >>>>>> Yes.  Per RFC2205:
> >>>>>
> >>>>> Yes I know the figuere whose terms mixes functions, protocol
> >>>>> processes, etc. but this goes beyond the review of this
> >> document ;-)
> >>>>
> > [snip figure]
> >>>>>>    an RSVP QoS request is passed to two local
> >>>>>>    decision modules, "admission control" and "policy control".
> >>>>>>
> >>>>>>>> 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.
> >>>>>>
> >>>>>> I think this is the same as what is stated.
> >>>>>
> >>>>> What you mean is: the inner-working or implementation
> of admission
> >>>>> control for QoS requests is outside scope of RFC 2205.
> >>>>>
> >>>>>> we can add "implementation specifics ", i.e., " Since the
> >>>>>> implementation
> >>>>>> specifics of the admission control function is outside the
> >>>>>> scope " if it helps.
> >>>>>
> >>>>> Yes it does because the term "outside scope" has different
> >>>> meanings depending on context.
> >>>>>
> >>>>
> >>>> done.
> >>>>
> >>>>>>>> - 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
> >>>>>>
> >>>>>> How about we clarify: "*As described above,* the
> >>>>>> combination of the Association Source and the Association ID
> >>>>>> uniquely identifies the association."
> >>>>>
> >>>>> It would be better to state
> >>>>>
> >>>>> "[RFC4872] defines the IPv4 ASSOCIATION object and the IPv6
> >>>>> ASSOCIATION object in the context of a given session.
> 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.
> >> This doesn't
> >>>>> prevent that Association Types MAY further specify the
> context for
> >>>>> which this association is defined."
> >>>>
> >>>> It now reads:
> >>>>
> >>>>     [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.  As
> >>>>     described above, the contents of the object uniquely
> identifies
> >>>>     an association.  Because the Association ID field is a 16-bit
> >>>>     field, an association source can allocate up to
> 65536 different
> >>>>     associations and no more.
> >>>
> >>> OK
> >>>
> >>>>>>> (and actually the same for RFC 4873 which relies on MBB
> >> as defined
> >>>>>>> in
> >>>>>>>> RFC 3209)
> >>>>>>
> >>>>>> I don't believe this statement is correct, but again this
> >>>> is really a
> >>>>>> discussion beyond this draft.
> >>>>>
> >>>>> The statement here above is also to applicable to RFC 4873.
> >>>>>
> >>>>>>>> - 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.
> >>>>>>> ?
> >>>>>>
> >>>>>> As I read it, it enables practical third party (e.g.,
> >>>>>> management entity)
> >>>>>> creation and management of association IDs.  But, I'll
> >> defer to my
> >>>>>> coauthors on this.
> >>>>>
> >>>>> OK. Please let me know the result(s) of the discussion.
> >>>>>
> >>>>>>>> - 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 ?
> >>>>>>
> >>>>>> It's the solution the WG agreed to.  Other options are of
> >>>>>> course possible.
> >>>>>
> >>>>> My comment is specific because it triggers the question
> >> on how many
> >>>>> objects will we end up in spreading identification
> information (it
> >>>>> would be interesting to document the why this was felt the most
> >>>>> suited object as it is not a natural choice); more general
> >>>> comment is
> >>>>> what defines the "acceptable" use/extension of association.
> >>>>
> >>>> I think the last comment is a reasonable discussion to
> >> have.  Not sure
> >>>> it belongs in, or gates the discussion.
> >>>
> >>> The LSP attributes RFC included this info for instance. This has
> >>> prevented lots of problems in use of the object because
> the content
> >>> of most objects could have been added to the LSP
> attribute RFC (cf.
> >>> Sect.8 "8.  Summary of Attribute Bit Allocation" and Sect.10
> >>> "Guidance for Key Application Scenarios").
> >>
> >> Do you have some suggestions/text in mind?
> >
> > I will propose a Section for this. Can be done as part of
> this e-mail.


Can you put a placeholder in the document. Putting the full text would make this thread unreadable.


> >>>>>>>> - 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.
> >>>>>>
> >>>>>> I'm not seeing the issue.  Can you perhaps propose some text?
> >>>>>
> >>>>> Here is the proposed text
> >>>>>
> >>>>> "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 the fields
> >>>>>  as determined by the ASSOCIATION Type of the ASSOCIATION
> >>>>>  object. This applies equally to ASSOCIATION objects and
> >>>>>  Extended ASSOCIATION objects."
> >>>>
> >>>> Here's the revised text.
> >>>>     Identification of association is not modified by this
> >> section.  It
> >>>>     is important to note that Section 4 defines association
> >>>>     identification based on ASSOCIATION object matching,
> >> and that such
> >>>>     matching, in the absence of type-specific comparison
> rules, is
> >>>>     based on the comparison of all fields in an
> ASSOCIATION object.
> >>>>     This applies equally to ASSOCIATION objects and Extended
> >>>>     ASSOCIATION objects.
> >>>
> >>> I would write (look at the text just above where you state "As
> >>> defined, these objects each contain an Association Source
> >> field and a
> >>> 16-bit Association ID field.  As described above, the
> >> contents of the
> >>> object uniquely identifies an association." ... there is a need to
> >>> distinguish between identifying the ASSOCIATION object vs matching
> >>> ASSOCIATION objects).
> >>
> >> sure. But you need to be sure you're noting the difference
> between the
> >> word "association" and the thing "ASSOCIATION object".
> >
> > I am.
> >
> >>> This would
> >>>
> >>> "The procedure to perform ASSOCIATION object matching as
> defined in
> >>> Section 4 is not modified by this section. It is important to note
> >>> that Section 4 defines ASSOCIATION object matching if the
> >> ASSOCIATION
> >>> type does not refer to Association Type-specific rules for the
> >>> processing of the ASSOCIATION object (in which case the
> Association
> >>> Type-specific rules SHALL be applied); otherwise,
> ASSOCIATION object
> >>> matching applies by comparing all fields in an ASSOCIATION object.
> >>> This procedure applies equally to ASSOCIATION objects and Extended
> >>> ASSOCIATION objects."
> >>
> >> one more time, revised text now reads:
> >>     The procedures related to association identification are not
> >>     modified by this section.  It is important to note
> that Section 4
> >>     defines the identification of associations based on ASSOCIATION
> >>     object matching and that such matching, in the absence of
> >>     type-specific comparison rules, is based on the
> comparison of all
> >>     fields in an ASSOCIATION object.  This applies equally to
> >>     ASSOCIATION objects and Extended ASSOCIATION objects.
> >
> > I would state "in the absence of type-specific comparison rules (for
> > the Type value of the object being processed), is based on the
> > comparison of all fields in an ASSOCIATION object."
> >
> > because absence of rules is a generic statement.
>
> Again, I don't see the difference in meaning -- I think we're in the
> domain of style here.


The problem with your statement is: there is no (absence) type-specific rule then apply full matching

Mine it is either the one or the other.


> >>>>>>>> - Section 4.2: shouldn't "error processing" being
> documented ?
> >>>>>>
> >>>>>> Here too, I think the only error processing is as
> >> discussed above.
> >>>>>> Shout if you think otherwise.
> >>>>>>
> >>>>>>>> Example include
> >>>>>>>> admission control where receiving node rejects the
> >>>>>> incoming Path msg if the
> >>>>>>>> originating Global_ID/Ext.ASSOCIATION object isn't included,
> >>>>>>
> >>>>>> Interesting, but this is a type specific error.  To me this
> >>>>>> sounds like
> >>>>>> a new admission control error that should be defined as
> >> part of the
> >>>>>> type-specific definition.
> >>>>>
> >>>>> Admission control failures are part of the error codes
> >>>> defined in RFC 2205.
> >>>>
> >>>> exactly!
> >>>>
> >>>>>>>> unauthorized
> >>>>>>>> Global ID ?
> >>>>>>
> >>>>>> Again interesting, but this is a new policy (and policy
> >> error) that
> >>>>>> wasn't proposed or discussed in the WG.  I think this
> >>>> would be a fine
> >>>>>> addition, but is beyond the current document discussion. It
> >>>>>> could always be added if proposed.
> >>>>>
> >>>>> I defer this point to the AD.
> >>>>
> >>>> WFM.
> >>>>
> >>>>>
> >>>>>>>> etc. but also mismatches between Association source
> and Global
> >>>>>>>> Association source ?
> >>>>>>
> >>>>>> How would such a thing be detected, by checking BGP state?
> >>>> I guess we
> >>>>>> could add a new error code, but again I think we're going
> >>>> beyond the
> >>>>>> intent of the document/WG.
> >>>>>
> >>>>> Same here.
> >>>>>
> >>>>>>>> - 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 ?
> >>>>>>
> >>>>>> I'll drop the note.  This is better aligned with the field
> >>>> definition
> >>>>>> which has been updated based on comments of other reviewers.
> >>>>>>
> >>>>>> The current definition is:
> >>>>>>
> >>>>>>     This field contains a value that is a unique global
> >>>> identifier or
> >>>>>>     the special value zero (0).  When non-zero and not
> >>>> overridden by
> >>>>>>     local policy, the Global_ID as defined in [RFC6370]
> >>>> SHALL be used.
> >>>>>>     The special value of zero indicates that no global
> >>>> identifier is
> >>>>>>     present. Use of the special value of zero SHOULD be
> >> limited to
> >>>>>>     entities contained within a single operator.
> >>>>>
> >>>>> OK
> >>>>>
> >>>>>>>> - 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.
> >>>>>>
> >>>>>> Why is there any additional risk than what " was
> >>>> previously defined in
> >>>>>> [RFC4872] and [RFC4873]."? (as is already stated in the draft.)
> >>>>>
> >>>>> I try to prevent that any further use/documents would state "no
> >>>>> additional risk compared to RFC 4872 and RFC 4873" or
> >> equivalent but
> >>>>> the application is running for voice calls over the
> >>>> Internet which is
> >>>>> a totally different application than G/MPLS Recovery/Resource
> >>>>> Sharing.
> >>>>
> >>>> Fair enough, but what additional issues do you foresee
> >> that should be
> >>>> covered?
> >>>
> >>> Nodes associating sessions, etc. should have the mean to
> verify the
> >> initiator of the association.
> >>
> >> This is true for every object in RSVP!  I have no
> objection to object
> >> signing, ala SIDR, but this is well beyond the scope of
> this document
> >> and certainly isn't introduced in this document.
> >
> > We have to bring this point the Security directorate and
> ask them for
> > guidance (there could be a short term and a long term approach). I
> > understand the corresponding generic mechanism to perform such
> > verification isn't to be documented here but it has to be mentioned.
> > We loose track of all these security holes... hackers don't.
>
> RSVP's chain of trust is called out in RFC5920, which is reference by
> this draft.  I certainly have no issue with a general discussion on
> RSVP's chain of trust model, but the scope of this conversation is
> beyond (and should be scoped) to this draft.


Can you point which section of that RFC you are referring to that would help the reader.

I am asking because I didn't find any that speaks about ASSOCIATION object.


> Thanks,
> Lou
>
> >
> > OK for the rest. We are nearly done.
> >
> > Thanks,
> > -dimitri.
> >>>>>>>> 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)
> >>>>>>
> >>>>>> I'll add:
> >>>>>>   The expanded usage applies equally to GMPLS LSPs
> >> [RFC3473], MPLS
> >>>>>>   LSPs [RFC3209] and non-LSP RSVP sessions [RFC2205],
> [RFC2207],
> >>>>>>   [RFC3175] and [RFC4860].
> >>>>>
> >>>>> OK.
> >>>>>
> >>>>>>>> - Introduction: s/different ports/different destination
> >>>> (dst) ports
> >>>>>>>>
> >>>>>>
> >>>>>> sure.
> >>>>>>
> >>>>>>>> - Section 2 would better refer to a "Generalization"
> >>>> rather than a
> >>>>>>> "modification"
> >>>>>>>>
> >>>>>>
> >>>>>> I'd be okay with this, but I think modification makes is less
> >>>>>> likely to be misinterpreted so will leave as is.
> >>>>>
> >>>>> The term modification implies a change in existing
> >> processing (even
> >>>>> if the intention is different) and actually as the
> >> applicability is
> >>>>> now possible to RSVP and MPLS-TE.
> >>>>
> >>>> This isn't a major point for me, so will change it. (In
> 5 places.)
> >>>
> >>> OK (actually the doc. generalizes the use of the object
> whereas 4873
> >> for inst documents type-specific/specialized use of the object)
> >>>
> >>>>>>>> - 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.
> >>>>>>
> >>>>>> Why can't it review?  This is what the abstract of RFC6689
> >>>>>> says it does.
> >>>>>
> >>>>> It was overstated in RFC 6689.
> >>>>
> >>>> This document doesn't change 6689.
> >>>
> >>> OK.
> >>>
> >>>>>>>> - 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.
> >>>>>>
> >>>>>> Fair enough.
> >>>>>>
> >>>>>> Thank you for the review!
> >>>>>
> >>>>> OK.
> >>>>>
> >>>>> Thanks,
> >>>>> -d.
> >>>>
> >>>> Thanks,
> >>>> Lou
> >>>
> >>> Thanks,
> >>> -d.
> >>
> >> Thanks again.
> >>
> >> Lou
> >>
> >> PS I'll submit a revised version of the draft at some
> point today to
> >> document all changes to date.
> >>
> >>
> >
> >
> >
> >
>