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

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

Hi,

Nearly there. See in line.

Thanks or the work.

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

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

> > I can see how this updates 4872.
> >
> > 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

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

wfm

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

You have acks

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

You have acks

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

You have acks

> > Globally...
> >
> > s/extended ASSOCIATION/Extended ASSOCIATION/
> 
> sure
> 
> > 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
> 
> sure.
> 
> > ---
> >
> > As with the previous ambiguity...
> >
> > OLD
> > 3. Non-GMPLS Recovery Usage
> > NEW
> > 3. Uses other Than GMPLS Recovery
> > END
> 
> propose same change as above: Non-GMPLS and Non-Recovery Usage

OK

> > Section 3.1
> >
> > s/defined generic/defines generic/
> 
> thanks.
> 
> > 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.
> 
> Agreed. This sentence is clearly subject to misinterpretation and must
> be fixed!
> 
> >    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.
> 
> 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.
> 
> > 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.
> 
> 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.

OK

> > 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'm fine with should for both.
> 
> Co-authors?

Francois seems to indicate SHOULD and SHOULD is OK.

> > 2. Why does 3.2.1 consider association type-specific rules, but these
> >    are not in 3.1.1?
> 
> 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!
> 
> > 3.2.2
> >
> > s/This section apply/This section applies/
> 
> Thanks.
> 
> > 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?

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

> > Globally...
> >
> > Please be consistent with:
> > - Association ID
> > - association-id
> 
> okay.
> 
> > 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!).
> 
> 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.

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.

> > 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.
> 
> How about:
>    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.  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.

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

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