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

["Francois Le Faucheur (flefauch)" <[e-mail]>]

Adrian, Lou,

Additional thoughts below:

===

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?


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
it your intention that all new implementations of RSVP MUST include an
implementation of this document?

Absolutely not the intent.

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

---

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.

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

Works for me.



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

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

Works for me.



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

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

Works for me.



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.


note this is path processing,

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.

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




I'm fine with should for both.

Co-authors?


4. Why "MAY" not "may"?

over zealousness.  i.e., your right!

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


---

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?

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?

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