Draft Response to OIF on Resv Usage

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

We (well, mainly Deborah and I) have been delinquent in responding to the 
OIF's communication http://www.olddog.co.uk/oif2008_063_02.pdf

Here is a draft response. Please comment this week and we will send the 
response as a Christmas present.

Thanks,
Adrian

===

Dear Lyndon,

CCAMP owes the OIF responses to several communications. Apologies for the 
delay in producing formal responses. The issues raised were discussed at 
some length during the months after we received the communication both on 
and off the CCAMP mailing list, and I know you were involved in some of 
those discussions, but we forgot to send the formal responses.

We will generate a series of responses with the technical issues broken out 
into separate threads. This first one addresses the issue of Resv usage 
during make-before-break as raised in oif2008.063.02.pdf.

Best regards,
Adrian Farrel and Deborah Brungard
IETF CCAMP Working Group Co-chairs

---

> OIF thanks CCAMP for its prompt and very informative response
> to our liaison on OIF interoperability demo findings, sent
> from our 4Q2007 meeting. We appreciate CCAMP's offer to use
> the CCAMP mailing list for questions during our demo planning
> and testing, although more structured liaisons are still
> useful in our view to reflect meeting results and issues or
> comments that are agreed across OIF members (as opposed to
> individual views).

[SNIP]

> Based on your response liaison, it is our understanding that
> per-LSP RESV messages should be expected for the "make-
> before-break" scenario of modification. However, some members
> have commented that it appears to be possible in the
> specifications to use a single RESV message for multiple LSPs
> because:
> a) RFC 2205 allows the RESV message to carry multiple
>    FILTER_SPEC objects, specifically with the Shared Explicit
>    (SE) style that supports reservation sharing; and
> b) The FILTER_SPEC object was extended in RFC 3209 to carry
>    the LSP_ID.
>
> Clarification would be appreciated as to whether we should
> allow for receiving a single RESV message with multiple
> FILTER_SPEC objects in the "make-before-break" scenario using
> the SE style.

We believe this issue is substantially the same as the
following issue raised in the OIF correspondence dated November
29, 2007 with the subject "Liaison to IETF Regarding 2007
Interop Test Findings". Here you wrote:

> > - How many RESV messages are expected to be generated? Is it
> >   one since the resources in use by both LSPs are the same,
> >   or two since the LSPs are handled through separate
> >   signaling sessions.

In our response, dated January 3, 2008, we stated:

> >   In make-before-break, each LSP is signaled independently.
> >   Per LSP Resv messages should be expected.  Assuming the
> >   old LSP is in-place at the time of signaling the new LSP,
> >   and only one Path message is issued, then only one Resv
> >   would be expected. That is, a Resv for the new LSP, but no
> >   further Resv for the existing LSP.
> >
> >   When the old LSP is also modified as part of the make-
> >   before-break, e.g., to update administrative status prior
> >   to alarm-free tear-down, then a Resv message on the old
> >   LSP may also be generated.

To help clarify this point, we draw your attention to RFC 3209
which states:
    The SESSION object uniquely defines a traffic engineered
    tunnel. The SENDER_TEMPLATE and FILTER_SPEC objects carry
    an LSP ID. The SENDER_TEMPLATE (or FILTER_SPEC) object
    together with the SESSION object uniquely identifies an
    LSP tunnel.

As LSP tunnels (or LSPs for short) are identified using
different LSP IDs (as carried in SENDER_TEMPLATE and
FILTER_SPEC objects) and each LSP is signaled independently,
multiple FILTER_SPEC objects SHOULD NOT be allowed as part of
make-before-break.