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

["Adrian Farrel" <[e-mail]>]

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