Subject: Re: Comments on draft-ietf-ccamp-inter-domain-rsvp-te-01.txt

From: Arthi Ayyangar <[email-masked]>
Date: Wed, 14 Sep 2005 17:56:05 -0700 (PDT)

Hi Adrian,

Sorry for the delay (as usual) and thanks for your comments (as usual).
I have incorporated your comments and suggestions for the next rev. Just 
one major point of contention. See below.

> Section 4.1 (also section 9.1)
>   0x01 (TBD): Contiguous LSP bit - this flag is set by the head-end
>   node that originates the inter-domain TE LSP if it desires a
>   contiguous end-to-end TE LSP (in the control & data plane). When set,
>   this indicates that a boundary node MUST not perform any stitching or
>   nesting on the TE LSP and the TE LSP MUST be routed as any other TE
>   LSP (it must be contiguous end to end). When this bit is cleared, a
>   boundary node may decide to perform stitching or nesting. A mid-point
>   node not supporting contiguous TE LSP MUST send a Path Error message
>
> a. s/MUST not/MUST NOT/
> b. I have allocated bit number 4 (0x08) in the temporary registry of
> LSP_ATTRIBUTE bits available at http://www.olddog.co.uk/lsp-attrib.txt as
> a place holder until the IANA takes over this work. (I think we've
> discussed this before -  the point of the temporary registry is to save
---------> This has been 0x01 for Contiguous LSP desired and 0x02 for 
Stitching desired since the beginning of any of these drafts, through the 
merger and split. And I remember that the LSP Attributes registry used to 
carry the matching numbers before. But looks like other drafts have 
appeared and now the numbers for the inter-domain IDs in the registry no 
longer match the ones in the IDs.

Just one point that these inter-domain IDs predate most of the other IDs 
actually (in fact we went the LSP ATTRIBUTES path because we ran out of 
bits for the inter-domain IDs), so I am not sure what you propose we do 
at this point.

thanks,
-arthi

---

From: Arthi Ayyangar <[email-masked]>
Date: Sun, 18 Sep 2005 19:20:57 -0700 (PDT)

Hi Adrian,

It is unfortunate that this conflict occured and it took so long to find 
this out. Thanks for noticing it, when you did. On the bright side, 
atleast we can still fix this. I am okay with changing the bits in the 
inter-domain and stitching IDs. JP, is this fine with you ?

I will send out a mail pointing out this change once the next version has 
been posted, so that if someone thinks this change is significant 
and it affects them, then hopefully they will bring it up.

thanks,
-arthi

> I'm sorry that there is a conflict for these bits. Way back in the distant
> past a predecessor of your I-D had the Contiguous bit at 0x02 and the
> Stitching bit at 0x03 while it also had a Crankback bit at 0x01. There was
> an obvious conflict even then with the Crankback I-D and I started the
> registry to try to resolve this and sent mail to the MPLS and CCAMP lists.
>
> Obviously I didn't draw it to your attention well enough.
>
> I don't think that you can claim to predate the crankback work which was
> already at revision 6 in June 2003. But that probably isn't important.
>
> We have a conflict we need to resolve.
>
> Since the Crankback I-D completed WG last call in April this year and was
> passed to the ADs in May, I think it "wins".
>
> Cheers,
> Adrian
>
> ----- Original Message -----
> From: "Arthi Ayyangar" <[email-masked]>
> To: "Adrian Farrel" <[email-masked]>
> Cc: "'Jean Philippe Vasseur'" <[email-masked]>; <[email-masked]>
> Sent: Thursday, September 15, 2005 1:56 AM
> Subject: Re: Comments on draft-ietf-ccamp-inter-domain-rsvp-te-01.txt
>
>
>> Hi Adrian,
>>

---

From: JP Vasseur <[email-masked]>
Date: Mon, 19 Sep 2005 14:33:38 -0400

Hi Arthi,

On Sep 18, 2005, at 10:20 PM, Arthi Ayyangar wrote:

> Hi Adrian,
>
> It is unfortunate that this conflict occured and it took so long to  
> find this out. Thanks for noticing it, when you did. On the bright  
> side, atleast we can still fix this. I am okay with changing the  
> bits in the inter-domain and stitching IDs. JP, is this fine with  
> you ?
>

Yes,

> I will send out a mail pointing out this change once the next  
> version has been posted, so that if someone thinks this change is  
> significant and it affects them, then hopefully they will bring it up.
>

Thanks.

JP.

>>>>   contiguous end-to-end TE LSP (in the control & data plane). When
>>>>
>> set,
>>
>>>>   this indicates that a boundary node MUST not perform any  
>>>> stitching
>>>>
>> or
>>
>>>>   boundary node may decide to perform stitching or nesting. A
>>>>
>> mid-point
>>
>>>> LSP_ATTRIBUTE bits available at http://www.olddog.co.uk/lsp- 
>>>> attrib.txt
>>>>
>> as
>>
>>>> discussed this before -  the point of the temporary registry is to
>>>>
>> save
>>
>>> Stitching desired since the beginning of any of these drafts,  
>>> through
>>>
>> the
>>
>>> merger and split. And I remember that the LSP Attributes registry  
>>> used
>>>
>> to
>>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 18 Sep 2005 23:02:41 +0100

Hi Arthi,

Cheers,
Adrian

----- Original Message ----- 
From: "Arthi Ayyangar" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: "'Jean Philippe Vasseur'" <[email-masked]>; <[email-masked]>
Sent: Thursday, September 15, 2005 1:56 AM
Subject: Re: Comments on draft-ietf-ccamp-inter-domain-rsvp-te-01.txt

set,
mid-point
save