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

[JP Vasseur <jvasseur@cisco.com>]

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.

> 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" <arthi@juniper.net>
> > To: "Adrian Farrel" <adrian@olddog.co.uk>
> > Cc: "'Jean Philippe Vasseur'" <jvasseur@cisco.com>;  
> > <ccamp@ops.ietf.org>
> > Sent: Thursday, September 15, 2005 1:56 AM
> > Subject: Re: Comments on draft-ietf-ccamp-inter-domain-rsvp-te-01.txt
> >
> >
> >
> > > 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