[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Last Call: CR-LDP Extensions for ASON to Informational



Inline

> -----Original Message-----
> From: John Drake [mailto:jdrake@calient.net]
> Sent: woensdag 22 januari 2003 22:28
> To: 'Wijnen, Bert (Bert)'; Kireeti Kompella
> Cc: Bob Braden; iesg@ietf.org; ietf@ietf.org
> Subject: RE: Last Call: CR-LDP Extensions for ASON to Informational
> 
> 
> Bert,
> 
> I don't recall a SG15 Liason of the form 'Btw, we're planning 
> to change a couple of your protocols (CR-LDP, RSVP-TE),
> and we hope you don't mind".  
> 
Well... they did not word it as you are doing, but... the LIASON
statements that have been sent to CCAMP and that have been available
on the IETF web pages DO point to documents where that is described.

Also... I believe that an ITU SG-15 person was speakeing at every
CCAMP WG meeting since London or so to talk about the things they
were doing.

So don't give me the crap that the CCAMP WG members are not aware
of this for quite a long time. If you are not aware, then I can
only conclude that you have payed no attention.

> More importantly, do you really think it's a good idea to allow
> other organizations to change the IETF's protocols?

Now... the question is: are they indeed CHANGING an IETF protocol?

First, we have defined a few namespaces (for RSVP and for LDP) 
so that the protocols are extensible. We have split up those
name spaces, such that people or organisations can ask for 
code points in IETF-consensus-required section or in a FCFS section
(First Come First Served, formally no documentation required I think)

As you can see, in the RSVP space, there is a lot of FCFS code points.
For the RSVP solution, they (ITU/OIF) are mainly asking for code
points in the FCFS space. So what was our intention for that namespace
when we defined it?

My feeling is from all the discussions, that the biggest problem
is not so much on how RSVP or CR-LDP code points are added (the 
protocol is still the same, there are just more Objects and/or TLVs).
I'll admit that some comments have been received on if the way the
TLVs and Objects/Classes have been organized is very clean or ideal,
but that seems also a bit of a detail to me.

Rather the problem is that they talk about and want to provide:
- call and connection separation
- that they add NSAP addresses
- that they define a UNI interface (which we, IETF forcefully
  rejected to be worked on in IETF a few years back)

Now... if those are the 3 issues, then I think we have only seen
a few people object. But the objections are more of the form
that people don't like this (which is OK, this is one of the
reasons why we did not want to do this work in IETF), but I 
still fail to see any mention of the real technical problems
of what they are doing. But then, I am not a control-plabe
or data-plane (or MPLS or GMPLS for that matter) expert.

> As Jerry Ash pointed out, that's the same as having the IETF
> develop its own version of G.709.  I think it would have been
> a much better idea for the ITU to send G.7713 to the IETF
> (CCAMP) and ask them to develop protocols to support it.
> 
I believe that at least for teh UNI, they have done so in
the past and we told them to go away.
I believe that NSAP was also disliked and we did send them away.
I am not 100% clear on call and connection separation.

Hope this can help to bring the discussion to either consensus
to approve, or to show us what the real technical issues are
by those who have raised objections sofar.

Bert
> Thanks,
> 
> John