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

From: Lou Berger <[email-masked]>
Date: Tue, 04 Sep 2012 11:24:48 -0400

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; [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 ?

Yes. This is stated in the header, abstract and section 3.
>>
>> - 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.

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

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

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

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

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

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

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

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

>>
>> - Section 3.3 states "Since the admission control function is outside the
> scope of
>> RSVP,..." are you sure ? 

Yes.  Per RFC2205:

              HOST                              ROUTER

 _____________________________       ____________________________
|  _______                    |     |                            |
| |       |   _______         |     |            _______         |
| |Appli- |  |       |        |RSVP |           |       |        |
| | cation|  | RSVP <---------------------------> RSVP  <---------->
| |       <-->       |        |     | _______   |       |        |
| |       |  |process|  _____ |     ||Routing|  |process|  _____ |
| |_._____|  |       -->Polcy||     ||       <-->       -->Polcy||
|   |        |__.__._| |Cntrl||     ||process|  |__.__._| |Cntrl||
|   |data       |  |   |_____||     ||__.____|     |  |   |_____||
|===|===========|==|==========|     |===|==========|==|==========|
|   |   --------|  |    _____ |     |   |  --------|  |    _____ |
|   |  |        |  ---->Admis||     |   |  |       |  ---->Admis||
|  _V__V_    ___V____  |Cntrl||     |  _V__V_    __V_____ |Cntrl||
| |      |  |        | |_____||     | |      |  |        ||_____||
| |Class-|  | Packet |        |     | |Class-|  | Packet |       |
| | ifier|==>Schedulr|================> ifier|==>Schedulr|===========>
| |______|  |________|        |data | |______|  |________|       |data
|                             |     |                            |
|_____________________________|     |____________________________|

                  Figure 1: RSVP in Hosts and Routers

   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.

we can add "implementation specifics ", i.e., " Since the implementation
specifics of the admission control function is outside the scope " if it
helps.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Lou

>>
>>
>> -----
>> Homepage:
>> <http://belllabs.be/people/dpapadimitriou/>
>> <http://psg.com/~dpapadimitriou>
> 
> 
> 
> 
>

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Tue, 4 Sep 2012 22:52:09 +0200

Hi Lou,

See inline:

> From: Lou Berger [mailto:[email-masked]]
> Sent: Tuesday, September 04, 2012 17:25
> To: [email-masked]; Papadimitriou, Dimitri (Dimitri)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [RTG-DIR] FW: Review of draft-ietf-ccamp-assoc-ext-04
>
> Adrian,

I thought to include this in the introduction since other updated RFC are indicated.

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

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

> where you can have one without the other.  Please correct me if you

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

Other elements aren't necessarily identical. The setting of the association source is application type specific.

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.

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

> so it does not impact to RFC 4873 and 4872 implementations.  As stated
> in the draft and quoted by you:
>
> > This section
> > does not

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

> doesn't relate to [RFC4872] and [RFC4873].

The proposed phrasing would resolve it.

> I see no text change requested based on this comment.

Ditto.

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

>  It means test for simple equivalence,

My concern is this an equivalence between objects not an assocation of sessions.

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

>   via a management interface.

OK. Wouldn't you document PathErr/ResvErr and Notify ?

> know if two association objects are intentionally or unintentionally

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

> >> - Section 3.3 states "Since the admission control function

Yes I know the figuere whose terms mixes functions, protocol processes, etc. but this goes beyond the review of this document ;-)

>               HOST                              ROUTER

What you mean is: the inner-working or implementation of admission control for QoS requests is outside scope of RFC 2205.

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

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

> discussion beyond this draft.

The statement here above is also to applicable to RFC 4873.

> creation and management of association IDs.  But, I'll defer to my

OK. Please let me know the result(s) of the discussion.

> It's the solution the WG agreed to.  Other options are of

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

> type-specific definition.

Admission control failures are part of the error codes defined in RFC 2205.

> addition, but is beyond the current document discussion. It
> could always be added if proposed.

I defer this point to the AD.

> intent of the document/WG.

Same here.

>     entities contained within a single operator.

OK

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

>   LSPs [RFC3209] and non-LSP RSVP sessions [RFC2205], [RFC2207],

OK.

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

> Why can't it review?  This is what the abstract of RFC6689

It was overstated in RFC 6689.

> Thank you for the review!

OK.

Thanks,
-d.

---

From: Lou Berger <[email-masked]>
Date: Tue, 04 Sep 2012 17:53:33 -0400

Dimitri,
	See below.

> I thought to include this in the introduction since other updated RFC are indicated.

Agreed.  Text has been added.

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

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

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

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

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

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

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

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

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

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

> Let me put first in context. Generalization includes Rcv driven
> associations but only additions are documented.
> 
>> Are you asking:
> 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.

> OK. Wouldn't you document PathErr/ResvErr and Notify ?

IMO Not for an unknown type.

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

> Yes I know the figuere whose terms mixes functions, protocol
> processes, etc. but this goes beyond the review of this document ;-)

> What you mean is: the inner-working or implementation of admission
> control for QoS requests is outside scope of RFC 2205.
> 

done.

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

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

>> that such matching

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.

> Admission control failures are part of the error codes defined in RFC 2205.

exactly!

> I defer this point to the AD.

WFM.

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

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

> It was overstated in RFC 6689.

This document doesn't change 6689.

Thanks,
Lou

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Wed, 5 Sep 2012 09:43:00 +0200

Lou,

see below,

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Lou Berger
> Sent: Tuesday, September 04, 2012 23:54
> To: Papadimitriou, Dimitri (Dimitri)
> Cc: [email-masked];
> [email-masked]; [email-masked]

OK.

> ASSOCIATION object, this document ..." So will leave as is.

"In order to document the more general usage of the ASSOCIATION object, this specification ..."

OK.

> Association based on matching Association ID to Session ID is not part

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

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

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

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

OK.

> processing can be defined that allows implicit mapping such as you

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

> association ID matching that was part of 4872.

The above text would clarify the point.

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

> IMO Not for an unknown type.

I don't understand the answer.

> I think this sentence got truncated...

... safeguard rule advisable.

OK

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

>     This applies equally to ASSOCIATION objects and Extended

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

> Fair enough, but what additional issues do you foresee that should be

Nodes associating sessions, etc. should have the mean to verify the initiator of the association.

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

OK.

Thanks,
-d.

---

From: Lou Berger <[email-masked]>
Date: Wed, 05 Sep 2012 08:36:24 -0400

Hi Dimiri,
	Responses in line...

On 9/5/2012 3:43 AM, Papadimitriou, Dimitri (Dimitri) wrote:>  Lou,
> "In order to document the more general usage of the ASSOCIATION
object, this specification ..."

I think we're in the noise here...

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

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.

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

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

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

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

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

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

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

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

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

> OK (actually the doc. generalizes the use of the object whereas 4873
for inst documents type-specific/specialized use of the object)
>>>> Thank you for the review!

Thanks again.

Lou

PS I'll submit a revised version of the draft at some point today to
document all changes to date.

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Wed, 5 Sep 2012 18:08:29 +0200

Hi Lou,

> Sent: Wednesday, September 05, 2012 14:36
> >>>> Cc: [email-masked];
> [email-masked]

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

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

> know if this is intentional or an error when processing the path/resv

OK. As such this corroborates my initial remark where the association object was actually the most suited place to put this information.

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

OK.

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

OK.

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

> >>> processes, etc. but this goes beyond the review of this
[snip figure]
> Do you have some suggestions/text in mind?

I will propose a Section for this. Can be done as part of this e-mail.

> word "association" and the thing "ASSOCIATION object".

I am.

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

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

OK for the rest. We are nearly done.

Thanks,
-dimitri.

---

From: Lou Berger <[email-masked]>
Date: Wed, 05 Sep 2012 13:15:24 -0400

Dimitri (BTW sorry about the dropping the t in my last message)

	See below.

>  the context of the Association Source field."

I frankly don't see any difference in the wording.

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

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

>       type-specific processing is outside the scope of this document.

understood, I'll modify the paragraph. (subject to style differences.)

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

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

Again, I don't see the difference in meaning -- I think we're in the
domain of style here.

> 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

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Wed, 5 Sep 2012 22:50:50 +0200

Lou,

> Sent: Wednesday, September 05, 2012 19:15
> > "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 ?

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

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

> > object was actually the most suited place to put this information.

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

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

> > I will propose a Section for this. Can be done as part of

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

> Again, I don't see the difference in meaning -- I think we're in the

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.

> >>> Nodes associating sessions, etc. should have the mean to
> verify the

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.

---

From: Lou Berger <[email-masked]>
Date: Wed, 05 Sep 2012 17:31:23 -0400

See below.

> what about the above one concerning the unicity ?

unique as scoped by the Association Source field. As stated:

      When combined with the other fields carried in the object, this
      value uniquely identifies an association.

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

I think this is sufficiently unambiguous to ensure interoperable
implementations.

> "uniquely identify the association"

The association of what? --> Sessions.

So I'm at a loss to see the difference.

In the interest of moving forward I'll use "association being
identified" (in 3 places.)

> This is not the question. If the association are set per source
> interface how this mechanism shall be used ? 

Huh, where is this stated or even implied in the document.  It only says:

  The Association Source field MUST be set to a unique address
  assigned to the node originating the association.

This can be any address associated with any node. E.g., a loop back or
even management station address.

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

You're right.  If the implementation uses different association sources
to try to identify a single association it won't work.  But this is just
a broken implementation.  The document already repeats the concept of
using the same address / object contents in so many places I don't think
it needs to be stated yet again.

I'll submit the changes we have so far, and if you still think there's a
need for a text change, please propose it as I'm at a loss.

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

So what you're really asking for is a compatibility section that says
how to deal with the case with inconsistent support of an association
type. Well, sure we can add something.  Now that said, it really should
have been done along with the original object definition.

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

Please send it in a response to the publication notification of the next
version.  Please also include the CCAMP WG as they will need to review
the text.

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

This is informative text (at this point).  I also think it says the same
thing.

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

Again, the association object is defined in [RFC4872] not this document.
 I'll add a reference to "chain of trust model".

Lou

PS I'll submit the draft in a couple of minutes.

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Wed, 5 Sep 2012 23:39:42 +0200

Lou,

Concerning the remark

"Now that said, it really should have been done along with the original object definition."

it is in RFC 4872, but it deals with LSP admission failure (because "type-specific"), as you cover a larger scope I just ask why it is not extended. Text extracted from RFC 4872:

  4) Error Code/Sub-code values

   The following Error code/sub-code values are defined in this
   document:

   o "Admission Control Failure/LSP Admission Failure" (4)
   o "Admission Control Failure/Bad Association Type" (5)

Thanks,
-d.
> Sent: Wednesday, September 05, 2012 23:31