Subject: [CCAMP] AD review of draft-ietf-ccamp-assoc-ext

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 8 Aug 2012 08:19:19 +0100

Hi,

I have done my usual AD review of this document prior to issuing IETF
last call. The purpose of my review is to catch any issues that might 
come up in last call or IESG evaluation, and so smooth the path of the
document.

This seems to be a well-written I-D, thanks. I have just a few small
points that are mainly stylistic. A quick respin should address them.
I start with one fundamental question that I hope can be answered by
email.

Thanks,
Adrian

===

To start with, a key question:

Why does the working group want to publish this as an RFC when there
is no immediate intention to implement for any of the many scenarios
described in the document?

Will this become just another Standards Track RFC that gathers dust
and obfuscates the real protocol specs, or is there good reason to 
publish it?

---

I can see how this updates 4872.

I am not convinced about this being an update to 2205, 3209 and 3473.

Let me ask the question as follows: Is this document needed in order to
produce a conformant implementation of RFC 2205 RSVP? In other words: is
it your intention that all new implementations of RSVP MUST include an
implementation of this document?

If the document does make the updates stated, it would be good if some
part of the document (maybe a new section, maybe just the Introduction)
contained text that described what has been updated.

Does Section 6.2 imply an update to RFC 4873?

---
                                        
Section 1

Some ambiguity, since it looks like the extension is to recovery 
contexts other than GMPLS!

OLD
   This document expands the possible usage of the ASSOCIATION object to
   non-GMPLS recovery contexts.  
NEW
   This document expands the possible usage of the ASSOCIATION object to
   contexts other than GMPLS recovery.  
END

---

Section 1 Voice Call Waiting

       However,
       there is no way in RSVP today to share the resources between the
       A->B and A->C subflows of the call since by definition the RSVP
       reservations for these subflows must have different IP addresses
       in the SESSION objects.

Since you are defining such a mechanism, "there is no way today" is not
true. I suggest...

       Since, by definition, the RSVP reservations for the subflows A->B
       and A->C of the call must have different IP addresses in the
       SESSION objects, this document defines a new mechanism to
       associate the subflows and allow them to share resources.

Similarly...

OLD
     o Voice Shared Line:
       A single number that rings multiple endpoints (which may be
       geographically diverse), such as phone lines on a manager's desk
       and their assistant.  A VoIP system that models these calls as
       multiple P2P unicast pre-ring reservations would result in
       significantly over-counting bandwidth on shared links, since
       today unicast reservations to different endpoints cannot share
       bandwidth.
NEW
     o Voice Shared Line:
       A voice shared line is a single number that rings multiple 
       endpoints (which may be geographically diverse), such as phone
       lines to a manager's desk and to their assistant.  A VoIP system
       that models these calls as multiple P2P unicast pre-ring 
       reservations would result in significantly over-counting 
       bandwidth on shared links, since RSVP unicast reservations to
       different endpoints cannot share bandwidth.  So a new mechanism
       is defined in this document allowing separate unicast
       reservations to be associated and share resources.
END

And...

OLD
     o Symmetric NAT:
       RSVP permits sharing of resources between multiple flows
       addressed to the same destination D, even from different senders
       S1 and S2.  However, if D is behind a NAT operating in symmetric
       mode [RFC5389], it is possible that the destination port of the
       flows S1->D and S2->D may be different outside the NAT.  In this
       case, these flows cannot share resources using RSVP today, since
       the SESSION objects for these two flows outside the NAT would
       have different ports.
NEW
     o Symmetric NAT:
       RSVP permits sharing of resources between multiple flows
       addressed to the same destination D, even from different senders
       S1 and S2.  However, if D is behind a NAT operating in symmetric
       mode [RFC5389], it is possible that the destination port of the
       flows S1->D and S2->D may be different outside the NAT.  In this
       case, these flows cannot share resources using RSVP, since the
       SESSION objects for these two flows outside the NAT have
       different ports.  This document defines a new mechanisms to 
       associate these flows and allow them to share resources.
END

---

Globally...

s/extended ASSOCIATION/Extended ASSOCIATION/

---

Section 1

OLD
   This document also defines the extended ASSOCIATION objects which can
   be used in the context of Transport Profile of Multiprotocol Label
   Switching (MPLS-TP).  Although, the scope of the extended ASSOCIATION
   objects is not limited to MPLS-TP.
NEW
   This document also defines the Extended ASSOCIATION objects which can
   be used in the context of the Transport Profile of Multiprotocol
   Label Switching (MPLS-TP).  The scope of the Extended ASSOCIATION 
   objects is not limited to MPLS-TP.
END

---

As with the previous ambiguity...

OLD
3. Non-GMPLS Recovery Usage
NEW
3. Uses other Than GMPLS Recovery
END

---

Section 3.1

s/defined generic/defines generic/

---

Section 3.1.2

   A node that wishes to
   allow downstream nodes to associate Path state across RSVP sessions
   MUST include an ASSOCIATION object in the outgoing Path messages
   corresponding to the RSVP sessions to be associated.

Yuck!

Are the sessions to be associated in the outgoing Path messages or the
Association object, or both. Actually, I don't think this needs a MUST,
but can be converted to descriptive text as follows.

   A node that wishes to allow downstream nodes to associate Path state
   across RSVP sessions sends a Path message corresponding to one RSVP
   session and includes in that message an ASSOCIATION object that 
   indicates the associated RSVP sessions.

Then you have...

   In the absence
   of Association Type-specific rules for identifying association, the
   included ASSOCIATION objects MUST be identical across all associated
   sessions.

I know what you mean, but what you have said would require that a Path
message must contain an Association object that refers to itself. I 
think what you need has to be more verbose to be accurate.

   In the absence
   of Association Type-specific rules for identifying association, each
   Path message for a session in a set of associated sessions MUST
   include an ASSOCIATION object that indicates all the other sessions 
   in the set.

---

3.1.1 vs 3.2.1

In 3.1.1 you have...
   Relative ordering of ASSOCIATION objects of the same
   type SHOULD be preserved by transit nodes.

In 3.2.1 you have...
   Relative ordering of ASSOCIATION objects of the same
   type MUST be preserved by transit nodes.  Association type specific
   ordering requirements MAY be defined in the future.

1. Why is 3.1.1 SHOULD and 3.1.2 MUST?
2. Why does 3.2.1 consider association type-specific rules, but these
   are not in 3.1.1?
3. s/type specific/Type-specific/
4. Why "MAY" not "may"?

---

3.2.2

s/This section apply/This section applies/

---

3.3.1

   Once an association is identified, resources SHOULD be shared across
   the identified sessions.

This use of "SHOULD" begs the question: under what circumstances MAY
resource sharing not be applied?

---

Globally...

Please be consistent with:
- Association ID
- association-id

---

Section 4.1

Global Association Source: 4 bytes

      This field contains a value that is a unique global identifier.
      This field MAY contain the 2-octet or 4-octet value of the
      provider's Autonomous System Number (ASN).  It is expected that
      the global identifier will be derived from the globally unique ASN
      of the autonomous system hosting the Association Source.  The
      special value of zero (0) indicates that no global identifier is
      present. Note that a Global Association Source of zero SHOULD be
      limited to entities contained within a single operator.

Given the statement that the content is globally unique, I don't think
there is room for you to pontificate about how this field might be 
filled. You need to make a definitive statement. Otherwise the content
cannot be guaranteed to be globally unique (unless you envisage a 
central registration system!).

---                                                          

Section 4.1

   Extended Association ID: variable, 4-byte aligned

      This field contains data that is additional information to support
      unique identification.  The length and contents of this field is
      determined by the Association Source.  This field MAY be omitted,
      i.e., have a zero length.  This field MUST be padded with zeros
      (0s) to ensure 32-bit alignment.

This is confusing. I think that the length of the field is chosen by the
Association source and determined by the Length field of the Association
object. 

But your text implies that the contents of the field may be different 
from a four octet quantity. Since you have not included a separate 
length indicator, this cannot be. The object length must always be a
multiple of 4 (says RFC 2205) and so there is no difference between a
zero padded field and a field where the zeros have meaning.

You *could* say that the length of this field is Association Type-
specific, but that would be ugly.

---

While you're at it, please note that draft-ietf-ccamp-assoc-info has
been published as RFC 6689

---

From: Lou Berger <[email-masked]>
Date: Wed, 08 Aug 2012 10:26:26 -0400

Adrian,
	Thank you for the review.  Please see below for in-line responses.

Lou (as co-author)

> and obfuscates the real protocol specs, or is there good reason to 

The document was motivated to support applications such as defined in
draft-ietf-ccamp-rsvp-resource-sharing (whose authors say they intend to
revive this work now that the foundation work has reach maturity.)

> I am not convinced about this being an update to 2205, 3209 and 3473.

only as much as it provides additional capability to those RFCs, not
that it modifies their basic behavior. The point of listing them was to
make it clear that this draft's scope is beyond rfc4872 / recovery.
Perhaps it's sufficient to put this in the narrative and not as part of
the updates field.

> produce a conformant implementation of RFC 2205 RSVP? 

No.

> In other words: is

Absolutely not the intent.
> contained text that described what has been updated.

The relevant text is in section 3.  If this isn't sufficient can you
propose some alternate/additional language?

   The remainder of this section defines the general rules to be
   followed when processing ASSOCIATION objects.  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].

> Does Section 6.2 imply an update to RFC 4873?

Perhaps, it extends the definition provided in 4873 to non-recovery
application. implementations of rfc4873 aren't impacted by 3.3/6.2.  So
for this reference, I don't think so.

That said, 4873 does make use of the association object defined in 4872.
 4873 implementations can certainly make use of the Extended ASSOCIATION
Objects (section 4), but we didn't list an update to 4873 as 4873
references 4872 for the definition of ASSOCIATION Objects. So we thought
the 4872 update indication was sufficient.

>    contexts other than GMPLS recovery.  

I agree -- looking at it again after all this time.

How about (in multiple places)
OLD
non-GMPLS recovery
NEW
non-GMPLS and non-recovery

>        associate the subflows and allow them to share resources.

looks good to me. (assuming my co-authors don't object.)

>        reservations to be associated and share resources.

okay (assuming my co-authors don't object.)

>        associate these flows and allow them to share resources.

okay (assuming my co-authors don't object.)

> s/extended ASSOCIATION/Extended ASSOCIATION/

sure

>    objects is not limited to MPLS-TP.

sure.

> 3. Uses other Than GMPLS Recovery

propose same change as above: Non-GMPLS and Non-Recovery Usage

> s/defined generic/defines generic/

thanks.

> but can be converted to descriptive text as follows.

Agreed. This sentence is clearly subject to misinterpretation and must
be fixed!

>    indicates the associated RSVP sessions.

I think this actually doesn't match our intent.

See below for proposed wording as I think it's easier to parse the
sentences changes/together.

>    include an ASSOCIATION object that indicates all the other sessions 

how about:
   To indicate association between multiple sessions, an appropriate
   ASSOCIATION object MUST be included in the outgoing
   Path messages corresponding to each of the associated sessions.
   In the absence of Association Type-specific rules for identifying
   association, the included ASSOCIATION object MUST be identical.

>    type SHOULD be preserved by transit nodes.

note this is path processing,

>    ordering requirements MAY be defined in the future.
Note this is resv processing.

> 1. Why is 3.1.1 SHOULD and 3.1.2 MUST?

I'm not sure, other than 3.1.2 is new so there's no chance of placing a
new requirement on implementations of 4872&3 (which only use association
objects in Path messages.)

I'm fine with should for both.

Co-authors?

> 2. Why does 3.2.1 consider association type-specific rules, but these

3.1.1 relates to path messages and we didn't want to impose new
requirements on implementations of 4872&3.

> 3. s/type specific/Type-specific/

sure.

> 4. Why "MAY" not "may"?

over zealousness.  i.e., your right!

> s/This section apply/This section applies/

Thanks.

> resource sharing not be applied?

actual resource allocation is really an implementation choice and
different internal implementation choices.  We didn't want to overly
constrain an implementation. "is expected" is really what we mean, but
how do you say this in 2119 language?

> Please be consistent with:

okay.

> central registration system!).

Humm this text is actually lifted from 6370 which says:

   Quoting from RFC 5003, Section 3.2:
      The global ID can contain the 2-octet or 4-octet value of the
      provider's Autonomous System Number (ASN).  It is expected that
      the global ID will be derived from the globally unique ASN of the
      autonomous system hosting the PEs containing the actual AIIs.  The
      presence of a global ID based on the operator's ASN ensures that
      the AII will be globally unique.

How about:

    This field contains a value that is a unique global identifier.
    This field MAY contain the Global_ID as defined in [RFC6370].
    The special value of zero (0) indicates that no global identifier
    is present. Note that a Global Association Source of zero SHOULD be
    limited to entities contained within a single operator.

> specific, but that would be ugly.

How about:

      This field contains data that is additional information to support
      unique identification.  The length and contents of this field is
      determined by the Association Source.  The length of this field
      is derive from the object Length field and as such MUST have a
      zero length or be 4-byte aligned.  A zero length indicates that
      this field is omitted.

> been published as RFC 6689

Sure.

Thanks for the comments.

> 
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
>

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 8 Aug 2012 16:02:21 +0000

Adrian, Lou,

Additional thoughts below:

===

Implementation for some of the discussed scenarios is being considered. This RFC will allow such implementation to be open for interoperability.

In other words: is

Agree with Lou. Not the intent. So in that sense, probably not an "update" to 2205.

---

      However,

Works for me.

Similarly...

OLD
    o Voice Shared Line:

Works for me.

And...

OLD
    o Symmetric NAT:

Works for me.

3.1.1 vs 3.2.1

In 3.1.1 you have...

In 3.2.1 you have...

I believe the idea is that while ordering is currently irrelevant, it might be relevant in some future application so we may as well avoid re-ordering when it is easy (i.e. new implementation).  Hence the logic of SHOULD & MUST. I am happy either way SHOULD/MUST or SHOULD/SHOULD.

Co-authors?

4. Why "MAY" not "may"?

or maybe something like :
"Note that association type specific ordering requirements could be defined in the future."

---

3.3.1

2205 uses the term "Admission control", so would it work if we said:
"
Once an association is identified, resources MUST be considered as shared across
  the identified sessions by the admission control function.
"

Francois

---

From: Lou Berger <[email-masked]>
Date: Thu, 09 Aug 2012 09:44:26 -0400

How about "MUST be" --> "is"

Lou

---

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

Hi,

Nearly there. See in line.

Thanks or the work.

Adrian

> revive this work now that the foundation work has reach maturity.)

OK. I think that this and the other responses probably tip it towards
publication. It feels a little premature, but not overly.

> > I am not convinced about this being an update to 2205, 3209 and 3473.

[snip]

The bottom line here appears to be:
- leave updates 4872 
- remove updates 2205, 3209, 3473
- retain text in Section 3
- don't add updates 4873

> non-GMPLS and non-recovery

wfm

> looks good to me. (assuming my co-authors don't object.)

You have acks

> okay (assuming my co-authors don't object.)

You have acks

> okay (assuming my co-authors don't object.)

You have acks

> propose same change as above: Non-GMPLS and Non-Recovery Usage

OK

>    association, the included ASSOCIATION object MUST be identical.

OK

> I'm fine with should for both.

Francois seems to indicate SHOULD and SHOULD is OK.

> how do you say this in 2119 language?

I think you are fine using SHOULD in this case. But you need to add
...although implementations MAY vary this according to local policy and
resource-sharing capabilities.

(Note that Francois proposed to promote this to a MUST, which would be OK, but
doesn't seem to be the original intent.)

>     limited to entities contained within a single operator.

Notwithstanding the problems of ambiguity introduced in RFC 5003 (the text you
quote is poor, but section 3.2 is clearer about the actual content of the
identifier) *this* document must not be ambiguous. Noting also that RFC 5003
allows a provider to decide to not bother with global uniqueness.

So, I would prefer you to write...

     This field contains a value that is a unique global identifier
     using the Global_ID as defined in [RFC6370] or the value zero (0).
     The special value of zero indicates that no global identifier is
     present. Note that a Global Association Source of zero SHOULD be
     limited to entities contained within a single operator.

>       zero length or be 4-byte aligned.  A zero length indicates that

Still having trouble with "determined by".  Try "dependent on".
s/derive/derived/

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 10 Aug 2012 12:07:26 +0000

Lou,

> How about "MUST be" --> "is"

I think the situation is that:
	* we want to define a Resource Sharing Association whose semantics is clearly that resources ought to be shared
	* at the same time, all things related to admission control, bandwidth accounting etc are out of scope, so the exact meaning of "sharing resources" is somewhat implementation specific.
Do you agree?

My personal preference is that :
	* we have a strong statement about semantics (i.e. "MUST" or a "SHOULD")
	* we clarify that the realization of this is somewhat implementation specific (to that end, I like Adrian's suggestion below to add an explicit statement clarifying that it may mean different things to different implementations)
This is as opposed to an alternative approach which has a weak statement ("is") on semantics of the Association.

So I'd suggest something like:
"
Once an association is identified, resources MUST be considered as shared across the identified sessions by the admission control function. Since the admission control function is outside the scope of RSVP, we observe that how resource sharing is actually reflected may vary according to specific implementations (e.g. depending on the specific admission control and resource management algorithm, or on how local policy is taken into account).
"

A SHOULD instead of a MUST can work for me to.

Would that be acceptable?

Francois

---

From: Lou Berger <[email-masked]>
Date: Fri, 10 Aug 2012 10:18:47 -0400

Francois,

> 	* at the same time, all things related to admission control, bandwidth accounting etc are out of scope, so the exact meaning of "sharing resources" is somewhat implementation specific.

precisely.

> "Once an association is identified, resources MUST be considered as
> shared across the identified sessions by the admission control
> function. Since the admission control function is outside the scope
> of RSVP, we observe that how resource sharing is actually reflected
> may vary according to specific implementations (e.g. depending on the
> specific admission control and resource management algorithm, or on
> how local policy is taken into account). "
> 

WFM

Adrian are okay with this language?

Lou

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 10 Aug 2012 15:47:02 +0100

> Adrian are okay with this language?

I can live with it.

It is fabulously woolly :-)
"MUST be considered as shared, but might not actually be shared"

I think that you are actually saying "MUST be made available to be shared across
the identified sessions, but admission control..."

Anyway, pick some words and go for it.

A

---

From: Lou Berger <[email-masked]>
Date: Fri, 10 Aug 2012 16:37:42 -0400

Adrian,

See below.

> - remove updates 2205, 3209, 3473

Are you sure about this?  Other RFCs that provide incremental functions
that are not required by all implementations identify the base protocol
in the Updates field. For example, take a look at rfc5151 it says both
3209 and 3473 are updated.

> - retain text in Section 3

...

> Francois seems to indicate SHOULD and SHOULD is OK.

done, although this means that we have to drop the following sentence.

>      limited to entities contained within a single operator.

The old text allowed for TP Global_ID while you are now requiring it's use.

How about:

  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. Note that a Global Association Source of zero SHOULD be
  limited to entities contained within a single operator.

> Still having trouble with "determined by".  Try "dependent on".

how about "scoped by"

> s/derive/derived/

k

...

Thanks,
Lou

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 13 Aug 2012 10:19:36 +0100

Hi Lou,

> 3209 and 3473 are updated.

Are you sure the authors of 5151 did not intend that all new implementations of
3209 and 3473 should include full support for 5151?

But I can see that there may have been confusion in the WG consensus on this
point if there is lack of clarity about what "updates" means in the header. My
view is that "updates" means "this becomes part of the protocol spec originally
stated by the updated RFC". It is quite possible that this has not been
applied/enforced in the past, and I am currently hunting for a definitive
reference (if I can't find one, I will have to run some IETF process to create a
clear definition of "updates" for future use).

[snip]
>   limited to entities contained within a single operator.

Yes. Thanks.

[snip]
> > Still having trouble with "determined by".  Try "dependent on".

Yes.

Many thanks,
Adrian

---

From: Lou Berger <[email-masked]>
Date: Mon, 13 Aug 2012 08:55:21 -0400

Adrian,

> 3209 and 3473 should include full support for 5151?
humm have to check with the authors;-) Either way, I don't think that
was the WG's intent.

I think keeping the updates reference is consistent with precedent and
http://www.rfc-editor.org/rfc-editor/instructions2authors.txt, so would
prefer to keep it.

Lou