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

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 20 Jun 2006 13:50:01 -0400

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:[email-masked]] 
Sent: Monday, June 19, 2006 5:56 AM
To: Ong, Lyndon; [email-masked]
Cc: [email-masked]
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

---

From: Lou Berger <[email-masked]>
Date: Tue, 20 Jun 2006 14:15:28 -0400

At 01:50 PM 6/20/2006, Ong, Lyndon wrote:
>One concern, though, is

Lyndon,
         There is a long standing protocol design approach to set 
unused fields to zero.  This is done precisely to enable future use 
of the field.  IMO (and if my memory holds) this was so well accepted 
by the 3209 authors it didn't occur to us to enumerate all the 
implications of "MUST be zero".  I think we did a bit better in 
rfc3473, but the change was only in response to the brain damage that 
was seen in 3209 interpretations...

Lou