RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt

["Ong, Lyndon" <Lyong@Ciena.com>]

Hi Adrian,

I can think of a number of advantages for a separate object:
-- avoids the errant processing issue we've been discussing
-- separates this more completely from RSVP Session processing
(right now, the draft has to have a separate statement that 
 the Call ID subfield must not be used in normal session processing.)
-- architecturally separates call and LSP information further

As far as the document is concerned, perhaps instead of removing
the description, there needs to be a stronger statement about
the "correct" processing of the field.  One concern, though, is
whether there were strong reasons for originally requiring that
the field be set to zero.

In RFC 2205, the same subfield is used in the IPv4 and IPv6 Session
objects
as a Protocol ID field, with the requirement that this is never all
zero,
plus a Flag field.  Was the requirement for all zero in RFC 3209
intended
to avoid confusion with the older use of the same bits in RFC 2205?

Cheers,

Lyndon


-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk] 
Sent: Monday, June 19, 2006 5:56 AM
To: Ong, Lyndon; Dimitri.Papadimitriou@alcatel.be
Cc: ccamp@ops.ietf.org
Subject: Re: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt

Hi Lyndon,

> As far as the Association Object, I understand from the definition 
> that this is serving a different purpose, however a separate object 
> (different from the Association Object) could still have some 
> advantage compared to using an existing field in the Session object.

You are right that using a separate object to carry the *short* call ID
was a possibility. And we did consider it. However, the motivation for
introducing a new object was not strong - it seems to be limited to
handling broken implementations, and we shouldn't let that particular
tail wag the dog.

In retrospect, perhaps we should not have included the description of
how broken implementations might behave. After all, we clearly don't
want to describe every possible broken implementation.

Adrian