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

[Lou Berger <[e-mail]>]

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

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

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

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

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

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

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