Subject: Re: Last Call: CR-LDP Extensions for ASON to Informational

From: Kireeti Kompella <[email-masked]>
Date: Mon, 13 Jan 2003 17:26:20 -0800 (PST)

Hi All,

On Tue, 31 Dec 2002, The IESG wrote:

> The IESG has received a request to consider CR-LDP Extensions for ASON
> <draft-aboulmagd-ccamp-crldp-ason-ext-02.txt> as an Informational RFC.
> This has been reviewed in the IETF but is not the product of an IETF
> Working Group.

I have two comments about this draft.

The first is that the draft calls for assignment of code points for
some new messages, TLVs and status codes.  The draft, however, fails
to say from which spaces these should come (e.g., that to be allocated
by IETF Consensus, First Come First Served, Experimental).  If this is
not specified, then I would suggest that code points from Experimental
spaces be used.

If code points are to be allocated from the space to be allocated by
IETF Consensus, I strongly suggest that a *Standards Track* document be
written, with more detail on the messages, especially their processing.
Also, more detail on what the goal is here, under what circumstances
these messages need to be sent/replied to, etc.

Kireeti.

---

From: John Drake <[email-masked]>
Date: Tue, 14 Jan 2003 07:06:34 -0800

Kireeti,

Presumably your comments, which I agree with, apply to
draft-lin-ccamp-gmpls-ason-rsvpte-04.txt as well?

Thanks,

John

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Monday, January 13, 2003 5:26 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Last Call: CR-LDP Extensions for ASON to Informational

Hi All,

Kireeti.

---

From: Bob Braden <[email-masked]>
Date: Wed, 15 Jan 2003 17:01:14 GMT

*> 
  *> >   *> If code points are to be allocated from the space to be allocated by
  *> >   *> IETF Consensus, I strongly suggest that a *Standards Track* document be
  *> >   *> written, with more detail on the messages, especially their processing.
  *> >
  *> > Indeed, that is what "IETF consensus" means, isn't it?
  *> 

Kireeti,

Following Randy Bush's suggestion, I did a "quick reread of RFC 2434",
and I realized that my comment above was incorrect. I had interpreted
"standards track" as meaning "by IETF process", but RFC 2434 does
distinguish standards track from IETF-approved Informational.  But then
I don't grok why it is particularly desirable to make the documentation
standards track, since in either case formal IETF action is involved.

Bob Braden

  *> Is it?  That's good.  Currently, the document is Informational, and
  *> is being processed as such.  Can this be changed?
  *> 
  *> Kireeti.
  *>

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 21 Jan 2003 16:42:17 +0100

Inline

> Sent: maandag 20 januari 2003 22:49
> To: Wijnen, Bert (Bert)
> Cc: Bob Braden; [email-masked]; [email-masked]
> Subject: RE: Last Call: CR-LDP Extensions for ASON to Informational
> 
> 
> Hi Bert,
> 
> On Sat, 18 Jan 2003, Wijnen, Bert (Bert) wrote:
> 
> > Yes they are from the  "IETF Consensus space".
> >
> > Now can you be more specific as to why you do not consider this doc
> > ready for publication?
> 
> There are a large number of nits and typos -- so much so that in my
> opinion, this document should not have been sent to IETF Last Call
> without another round of edits.  However, I will ignore those and
> concentrate on the substance.
> 
It would be great if you can send a list of nits and typos to the
author and copy Scott and Myself, possibly aslo the RFC-Editor.

> I would like to know what the intent is in not granting "the right
> to produce derivative works",
Did Steve Trowbridge not answer the first question?

> and whether the IETF should progress a
> document that is a derivative of IETF protocols with this clause.
> 
I think you meant a colon after "clause" and not a priod?

> The main thrust of the document is the "separation of call and
> connection"; 

> there is one short paragraph that describes this, and
> a reference to an ITU document.

Well, the ITU document should document the details. I don't think
we just want them to copy all their documentation into RFCs, do we?

> In my discussions with people who
> go to the ITU, I didn't hear a clear consensus on the need for this.
>
Well, then they should speak up in ITU I think. The ITU-T SG15 is 
discussing this in their meeting this week, and the technology is
up for consent. Any "people who go to the ITU" (to use your words)
and who do NOT agree with it should then speak up in ITU SG15,
don't you think so?

> An *IETF* document that describes the background, needs and how this
> is to be used would be very useful.  This is especially important as
> the very next paragraph says that separation can be achieved "where
> the call set up request is always accaccompanied by a connection
> request", which (to my naive understanding) hardly is separation.
> 
Why would we need them to replicate their own documentation into an
IETF document?

> Secondly, there is a real paucity of detail in the description and
> use of the new messages: the Call Setup Message refers to the OIF
> UNI document for formating and doesn't say much about when and how
> it is to be used; there is no justification for the format of the
> Call ID (why is there an International Segment, etc.?  Won't IP
> addresses do?  Is this to be used for telephone calls???  My
> recollection is that Fred Baker (then IETF chair) said that using
> CCAMP for telephony was a no-no ....)
> 
I will leave it to the "ITU" folk to answer the details.
But your main point seems to be that you have not seen enough
documentation. ITU-T did a Liason Statement to us, and I believe
even specifically to CCAMP WG (that you co-chair) and so can you
tell me if you read their documentation that they have made
(freely) available to us to check? And after reading that, do
your points still hold. If so, then maybe we (CCAMP) should answer
the Liason Statement and explain to them how and where they should
add more detail and ask specific questions based on what they
document in their "drafts" (or documents) to which they point.

> Call Release can be "sent by any entity of the network".  This surely
> can't be correct.
> 
Will let ITU-folk answer that.

> The Call Capability TLV is completely undocumented beyond the format
> of the TLV.
> 
How about in the documents in OIF and ITU that they point to?

> As someone else pointed out, crankback for CR-LDP has already been
> defined.  Furthermore, this document does not say what procedures
> the sender and receiver must follow, and how crankback is to be
> effected.
>
What do you mean by "has already been defined" ??
And are the procedures not documented in the documents they point to?
 
> The "Additional Error Codes" have absolutely no detail about what
> they mean, when they are to be sent, and what the receiver should
> do with them.  They also use a slew of unidentified acronyms.
> 
They do in the documents they point to.

Bert

---

From: John Drake <[email-masked]>
Date: Wed, 22 Jan 2003 13:28:02 -0800

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".  

More importantly, do you really think it's a good idea to allow other
organizations to change the IETF's protocols?  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.

Thanks,

John
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Tuesday, January 21, 2003 7:42 AM
To: Kireeti Kompella
Cc: Bob Braden; [email-masked]; [email-masked]
Subject: RE: Last Call: CR-LDP Extensions for ASON to Informational

Inline

 

Bert

---

From: Bob Braden <[email-masked]>
Date: Wed, 22 Jan 2003 21:43:14 GMT

Not liking to create unnecessary noise on large public lists (really!),
I trimmed the IETF off the following message. Bert W. has suggested that
this was inappropriate, as the issue is a general IETF issue.

Bob Braden for the RFC Editor

----- Begin Included Message -----

---

From: Bob Braden <[email-masked]>
Date: Tue, 21 Jan 2003 21:59:32 GMT

*> 
  *> Hi Bert,
  *> 
  *> On Sat, 18 Jan 2003, Wijnen, Bert (Bert) wrote:
  *> 
  *> > Yes they are from the  "IETF Consensus space".
  *> >
  *> > Now can you be more specific as to why you do not consider this doc
  *> > ready for publication?

Just for the record, although I am not technically competant to pass
detailed judgment, many of Mr. Kompella's comments fit my prejudices
about this document.

  *> 
  *> There are a large number of nits and typos -- so much so that in my
  *> opinion, this document should not have been sent to IETF Last Call
  *> without another round of edits.  However, I will ignore those and
  *> concentrate on the substance.

This saddens me.  I will go reread it.  The RFC Editor DID go one round
with the author (you should have seen the FIRST version!), and we
judged that the result was "good enough".  We are now both pleased and
embarrassed when someone from the community tells us that it was
NOT good enough!  But we do appreciate such feedback, really.  ;-)

...

  *> 
  *> The main thrust of the document is the "separation of call and
  *> connection"; there is one short paragraph that describes this, and
  *> a reference to an ITU document.  In my discussions with people who
  *> go to the ITU, I didn't hear a clear consensus on the need for this.

Our gripe was that the document did not even TRY to explain what this
distinction MEANS.

  *> An *IETF* document that describes the background, needs and how this
  *> is to be used would be very useful.  This is especially important as
  *> the very next paragraph says that separation can be achieved "where
  *> the call set up request is always accaccompanied by a connection
  *> request", which (to my naive understanding) hardly is separation.
  *> 

This is an important and sticky point... what are the IETF's rights and
duties with respect to the work of other standards bodies?  One of the
reasons the RFC Editor did not press harder was that the protocol was
essentially a fait accompli and presumably documented completely and
clearly by ITU-T.  The only purpose of the RFC was to document the IANA
registration, so fragmentary description without explanation seemed all
we could expect.  The RFC Editor rather hates to publish documents like
this, but of course there are political realities to be served, and we
understand Bert's point about duplication.

----- End Included Message -----

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 23 Jan 2003 02:51:57 +0100

In response to some questions that were not yet
answered in the below discussion

> From: <IETF-participant>
> Sent: donderdag 23 januari 2003 1:04
> To: Wijnen, Bert (Bert)
> Cc: Scott Bradner
> Subject: Re: [Fwd: quick review of the ason cr-ldp draft]
> 
> < snip >
> 
> >>My documented concerns are on the cr-ldp draft, there are a bunch of
> >>things that are just documentation, but some other things
> >>
> >>- the use of mpls for b-isdn (Kireeti called telephony)
> > 
> > Well, the fact that they use "call" terminology, does that really mean
> > that they are doing what you claim here?
> 
> this is tricky, I guess that you could claim they are not, but I was
> deeply involved in some of the ISDN work, and it looks disturbingly
> familiar. but you are right it needs to be proven that they don't, and
> that has not been done
> 
> >>- use of non-IP addresses
> > 
> > 
> > I understand that we IP-biggots want everything in the whole world
> > to be IP based. But can we actually prescribe that to the world?
> > 
> 
> oh, but we have had it as an architectural principal that mpls follows
> ip routing, it is even true when you have constraint based routed LSPs,
> it is the routing protocol that describes the network
> this wouldn't be an issue if they just were transferring non-IP addresses
> across the cloud, but they talk about "Call Release message is sent by
> any entity of the network" and it is not entirely clear that this is
> the case.
> 
Can the ITU folk answer this one please?

> > 
> >>- UNI/NNI fuzziness
> > 
> > 
> > Is that a matter of cleaning up the text?
> 
> possibly - I'm through the better part of the OIF document
> 
OK, eager to see where we get when you have read it all

> > Have you read the OIF spec(s)? Is it still fuzzy after that?
> > I also understand that most of the OIF UNI/NNI stuff has been worked
> > on by many (if not all) of the same people that are actibe in IETF.
> > Besides, a few years back, (I believe Rob Coltun was still RTG AD
> > and MPLS and such was all in RTG area), we (IETF) did send UNI folk
> > away stating that we did not want to work on it and so they did their
> > thing in OIF. The fact that most IETF-ers are participating there,
> > made me feel that they wanted it anyway, even though we in purists
> > land did not want to deal with it.
> > I believe OIF has approved UNI (and maybe also NNI, not sure) and that
> > vendors actually have products that comply with the UNI spec. I suspect
> > that they (these products) in fact already use the numbers that people
> > now ask IANA to assign. I know that such is a violation... but what
> > can we do?
> 
> we could at least understand what is going on and try to stop further
> "damage" ;)
> 
The damage has been done if they indeed have used such numbers in
any products. But I do know that OIF was using numbers out of the
LDP number space and RSVP number space a year or more ago, and I 
just happened to run into one of their documents and then started
to reaise concerns. That then actually made bala send a I-D that
requested for assigments (I think he did so early 2002 or probably
already in 2001). It got delayed and delayed and revised and delayed
etc... And then OIF approved their UNI 1.0 in Oct 2001, so I would
be surprised if there are not yet already products on the market
that use those code-points they originally wanted.

Maybe Bala or someone else can react to this.

It is in fact also very interesting to see that some of the people
who now are objecting are on the contributors list of the OIF document:
   John Drake
   Kireeeti Kompella

But if you read the page 2 (contributors list) of the OIF document
then you see that many (like 10+ or so) of the major players in
our CCAMP and MPLS WGs were actually contributing to the OIF
LDP and RSVP specs for UNI.

> > 
> > 
> >>- the level violation
> >>
> > 
> > 
> >>do concern me quite a bit, if ITU go and do this the risk is high that
> >>ldp starting to developing away from being an ietf protocol.
> >>
> > 
> > When we make things extensible, then that is always a risk. And how
> > do we control that. 
> > 
> > 
> >>Jerry Ash and John Drake sent as comments much to the same effect
> >>during the last call.
> >>
> > 
> > But I think that Steve Trowbridge (and possibly others) refuted that
> > did they not? If it is indeed such a SERIOUS and BAD violation,
> > why not did MOST or ALL of the IETF-folk object and speak up, or
> > at least support the statements from Jerry and John?
> 
> I know why I didn't - part of this was outside my horizon and 
> it became visible only after I started to review it
> 
Ok, but as I said above, many of our IETF folk were actively
participating in OIF... and I believe quite a few are also 
active in ITU. So if it is such a technical issue, I would
have expected alarm bells to have gone off much much earlier.

> > 
> > 
> >>If you ask me today I would object to let ITU go away and do this.
> >>It is possible that some/most/all of the would go away if it were
> >>better documented.
> >>
> > 
> > Well, did you read the ITU specs they pointed to?
> 
> nope -started with the OIF  - since that was easier to find, the
> ITU specs are on my list
> 
Great, thanks for investing the time and doing a serious and
detailed review. 

> > I do not believe that we MUST REQUIRE that all is documented in RFCs.
> > Are the ITU specs not clear enough?
> > Is Jerry Ash and others (who also participate in ITU) speaking up
> > there to BLOCK the achievement of CONSENT on thes documents?
> > 
> > You know, when people in ITU make trouble about our documents, we
> > often tell ITU: why don't you make your people participate in 
> > IETF WGs and speak up there. We can do similar thing in the
> > otehr direction. Kireeti in fact mentioned that various ITU-goers 
> > he knows claim that ITU does NOT have CONSENSUS on this. If this
> > is the case, then I guess there is no problem, cause those
> > people will then BLOCK the CONSENT in ITU, no?
> 
> well, I guess so - but I'm concerned about that IESG is about to
> approve a document that are not up to the quality that
> we've pushing on other authors, if I sent this to IESG - it would
> have been bounced on the nits within 10 minutes
> 
> (note - the only informational document I've first hand experience
> with is the documenation of the cr-ldp decission, but I've the
> feeling that similar problems actually held that document until they
> were taken care of)
> 
> I'm not counting on internal ITU politics to do our job
> 
And we should not. That is why we did the IETF Last Call when it
turned out that they want assignments in the IETF-Consensus needed
name space.

> > Or are those ITU-goers a very small minority in ITU and are they
> > trying to do an end-run around the ITU process and trying to block
> > things by convincing us (IESG) to not approve assignment of 
> > the reuqired numbers in RSVP and LDP namespaces?
> 
> have no idea - don't go to ITU, don't want to block good standards,
> but want to have proper documents
> 
We agree

> > 
> > 
> >>I'm also a bit concerned with the statements on the possibility
> >>to document after approval - seems to be a queer process, and not
> >>something that I've seen before.
> >>
> > 
> > When technical changes are expected, then we should indeed not go
> > that path. When it is a matter of clarifications that we can
> > identify, then I have seen that happen many times, even at 48-hour
> > author-call from RFC-Editor.
> 
> so this is the formula you could use to do something along the lines
> I proposed in an earlier mail
> 
OK, there you suggested:

  As Bert has demonstrated below thaer are things in at least the
  cr-ldp draft that does not meet the (formal) critiera for be
  an RFC.

All I know of now are some typos-type things that can be done
during editorial process.
I also know about the incorrect ref to the OIF document (see below)
we will fix that. When other people see more specific things, pls
point them out and be specific.

  How would the IESG react to something like this?

  - a statement that we understand the time constraints that ITU
    are in and recognize that they need the code points
  - inform the ITU that we are preparing a (g)mpls change process
  - request that ITU submit their changes to the (g)mpls protocols
    to us according this change process, in the same message inform
    them that they will get their code points as requested
  - a statement (in that same message) that this does not imply that
    we are accepting changes to LDP or any other IETF protocol
    by indirection
  - a request to IANA to give ITU their code points
  - inform other "potential (g)mpls protocol extenders" that we are
    working on the change process

  If this could be handled this way (or similar), it would work for me.
  Otherwise I would object to approving the three drafts. Mostly based
  on the fact that I don't understand where the LDP protocol are going.

Well, Scott and I have actually been talking with a few SUB-IP WG
chairs that we need to document something about (G)MPLS change process.

As a result of the ITU requests for assigments in RSVP namespace, we
also think that we probably need better and approved/published 
IANA considerations/guidelines for RSVP paramter assignments.

Once we have that in-place, it seems obvious that we should tell 
other people (organizations) what our (new or now documented) rules
are for making changes/ectensions/assignments. And of course we will
follow those in the future.

I am not sure it behooves us to now stall the ITU request and let them
wait till we get our act together. Not sure if that is what you meant?

> > 
> > 
> >>As for rsvp I've not reviewed it carefully enough, but at least if
> >>the use of non-IP addresses are in there I guess it should be a no.
> >>
> > 
> > They are. Funny thing here is that they ask for assignments mostly
> > in FCFS space (and the one or 2 code points that are not in FCFS
> > space could easily be moved into FCFS space), and so I do not see
> > how IANA (or we) can actually block/reject such assignments.
> > 
> > 
> >>But just to point on the complexity here, the Bala and Lin drafts
> >>includes normative references to
> >>"OIF-UNI-01.0, User Network Interface (UNI) 1.0 Signaling 
> >>Specification"
> >>that specification specifies at least one new LDP message (Status
> >>Enquiry Message) and several TLVs. I'm not aware of that we have 
> >>approved those, they are not in the IANA registry.
> >>
> > 
> > Scott and I noticed that when evaluating over the last weekend.
> > Since the ASON CR-LDP doc that we Last Called indeed has a normative
> > reference to the bala document, and since it makes sub-assignments
> > udnerneath some of the code point of the bala document, it seemed
> > that we more-or-less did an implicit Last Call for the bala doc.
> 
> I can only speak for myself - and I was not aware of this - if for no
> other reason the ason cr-ldp doc do not separate into normative and
> non-normative references
> 

Although I personally like it that even informational documents split
their normative and informative references, I normally leave it to
the RFC-Editor to push back when they come in as individual submissions
via the RFC-Editor, and that is what happened with these docs.

Now that the BALA doc is normative should be very clear, cause
the cr-ldp-extensions-for-ason doc does in fact use the Source ID TLV
and the Dest ID TLV (sections 3.1 and 3.2) as specified in ref 07
And ref 07 is the BALA document.

> > In any event, no one brought this up yet except you do at this point.
> > So we assumed that by having IETF consensus on the ASON CRLDP doc
> > we can defend that it also approves the bala doc. This is possibly
> > a trouble-some assumption... Scott and I understand that. And we
> > have presented the issue in similar wording to the IESG, so the
> > whole IESG is aware and can decide on this.
> > 
> > Do you see our reasoning as seriously flawed here?
> 
> you might get away with that reasoning, but I really would like it
> out in the open, it would have been possible to last call all three
> documents together
> 
Well, with the posting of this discussion it is.
In fact Scott was going to post it anyway, but I suspect he has
not found the time yet.

> > 
> > 
> >>If the IESG go about approving those drafts does this come to that
> >>the LDP extensions in the normative references are approved?
> >>
> > 
> > See above. The answer is yes. the 3 docs:
> >   draft-lin-ccamp-gmpls-ason-rsvpte-04.txt
> >   draft-aboulmagd-ccamp-crldp-ason-ext-02.txt
> >   draft-bala-uni-ldp-rsvp-extensions-04.txt
> > basically go together. They document (with ptrs to OIF and ITU docs
> > for details) the RSVP and CR-LDP code points requested for ASON
> > stuff. ITU has asked (cia a liason statement) back in May 2002
> > (I thijnk that was the month) that we review their docs and 
> > approve the request to IANA for assignments. 
> 
> this concerns me - how far do the indirection go? ptr to a doc with a
> ptr to a doc with a ptr to a doc ....
> 
I don't think it is any worse then when we use our own RFCs.
You should try to find something in our RFC-Series. Specifically
in the area of MPLS, GMPLS, CR-LDP and RSVP-TE... I know from
experiences that you keep getting pointed to yet more RFCs or
I-Ds all the time.

The tradeoff I think is that we want some RFC that documents where
we can find the details in the documents of the other organization.
We should not need to have them reproduce all the documents in
RFC-form.

> was that liaison sent to SubIP, ccamp or the mpls wg?
> 
I believe there where several, and they were to CCAMP mainly.
They are all accessible from the IETF web pages:
   http://www.ietf.org/IESG/liaison.html
And ITU SG 15 has been giving ptrs and summaries at the last 4-5
CCAMP meetings at least.

> > 
> > 
> >>The ason cr-ldp draft references the
> >>       B. Rajagopalan, User Network Interface (UNI) 1.0 Signaling
> >>       Specification, OIF-UNI-01.1, October 2001.
> >>
> >>if this is not the (and it shouldn't if there is any meaning to the
> >>OIF-UNI-01.0 vs. OIF-UNI-01.1 I can't find it on the OIF page, but I
> >>guess that it will include the same extensions to LDP.
> >>
> > 
> > So it seems we need to clarify the exact reference. I am sending
> > then a question about this.
> 
> saw the answer - and it just strengthen the feeling I've on that the
> ason cr-ldp is not very well thought through and reviewed
> 
Right, The answer from the authors was that there is just one
spec and that is UNI 1.0. So this is a typo that needs fixing.

> > 
> > 
> >>I guess I'm confused and in need of the (G)MPLS change process.
> >>
> > 
> > We should have had proper IANA Considerations for RSVP (which 
> > would have caused an earlier IETF Last Call on the RSVP doc
> > which now passed without IETF Last Call) and indeed we should
> > have had proper "(G)MPLS change control documentation". 
> > We cannot say that we have not seen this coming... ITU has been
> > working on this for more than a year. So I guess we have to 
> > (at least partly) blame ourselves.
> 
> agreed - I should have reviewed the ITU work back in May
> 
Bingo.

> > 
> > Thanks for your continued input and review. It is appreciated,
> > even though it causes us some trouble at this late time.
> > 
> > Main question I want answered from this email:
> >   - if you read the OIF and ITU documents, does that more or less
> >     make the stuff acceptable (let us say at least to the point
> >     that things are properly documented).
> 
> So far I think the OIF document is pretty good as far as documentation
> goes, but it contained stuff that I'm not entirely happy with
> technically and that I was not aware of before this - part of the
> problem is that it is not an open process that we can
> influence, if the ITU docs are of the same quality that would be good,
> but it would still leave the ason cr-ldp as severely sub-quality
> 
> > But answer/reaction to all of my statements above would be helpful
> > too.
> 
> ok - I've tried :)
> 
Thanks for trying. And we all appreciate the serious review you
are doing.

> <IETF-participant>
Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 23 Jan 2003 01:56:57 +0100

As you may all know, when an IETF Last Call is issued,
people can send comments to IETF and/or IESG mailing lists.

Here is a comment (with some back and forth discussionbs)
that was only sent to Scott Bradner and myself, but that 
deserves publicity. It is from a constructive and conscientious 
participant in the IETF in the Sub_IP area. For various
reasons, the person does not want to go public him/herself.

So I am forwarding without revealing the originators name. 

Bert 

-----Original Message-----
From: <IETF-participant>
Sent: donderdag 23 januari 2003 1:04
To: Wijnen, Bert (Bert)
Cc: Scott Bradner
Subject: Re: [Fwd: quick review of the ason cr-ldp draft]

Bert,

Wijnen, Bert (Bert) wrote:
< snip >
> Last weekend, Scott and I evaluated the comments and documents and
> based on that we recommended to IESG that approval seemed OK.
> We also informed ITU SG15 that we made a positive recomendation
> (they need the assignments this week), but that IESG still had
> to decide in their upcoming telechat.
> So if we have to retract based in this continued discussion, that
> looks ugly. But we have to do what needs to be done.
> 

< snip >

> Also... not having these comments in the open, does not show to
> ITU people (or anyone) who is following the Last Call that this
> is happening and what the arguments are.
> Possibly Scott or I should post this to ietf list as coming from
> an anonymous commenter. So that at least the issues are on the table.

I guess that is OK

< snip >

the case

> 
>>- UNI/NNI fuzziness
> 
> 
> Is that a matter of cleaning up th text?

> at least support the statements from Jerry and John?

I know why I didn't - part of this was outside my horizon and it became
visible only after I started to review it

ok - I've tried :)

<IETF-participant>

---

From: John Drake <[email-masked]>
Date: Thu, 23 Jan 2003 09:22:32 -0800

Snipped

-----Original Message-----
From: Lin, Zhi-Wei (Zhi) [mailto:[email-masked]]
Sent: Thursday, January 23, 2003 12:24 AM
To: Wijnen, Bert (Bert); Scott Bradner (E-mail); [email-masked]';
[email-masked]'; [email-masked]'
Cc: Lam, Hing-Kam (Kam); Malcolm Betts (E-mail); Stephen Shew (E-mail);
Lyndon Ong (E-mail); Alan McGuire (E-mail); Trowbridge, Stephen J
(Steve)
Subject: RE: Last Call: CR-LDP Extensions for ASON to Informational

<zhi> Where do you see that we deprecate ResvErr and ResvTear? (for the
record: these are not deprecated)
Where do you see that we deprecate FILTER_SPEC and LABEL objects? (for the
record: these are not deprecated)
Also, where do you see that we wish to identify the RSVP session endpoints
with GENERALIZED_UNI? (for the record: the RSVP session is still SESSION
object)
</zhi>

============================================================================
====================================
JD:  I've obviously misread the follwing text:

"Note that from the perspective of the ASON model ResvErr and ResvTear
messages are not used. For backwards compatibility, when an ASON-compliant
GMPLS node receives either a ResvErr or ResvTear as a response during the
setup phase of message exchange, the GMPLS-ASON node should instead issue a
PathTear message downstream and a PathErr (with Path_State_Removed flag set)
message upstream. This is so that RSVP states are immediately removed upon
error during the setup process." 

"... the SPC services support for the ASON model uses the GENERALIZED_UNI
object for this extension to help    align the model for both switched
connection and soft permanent connection, as well as to use the service
level and diversity attributes of the GENERALIZED_UNI object"

"Note that although the GENERALIZED_UNI and CALL_ID objects are optional for
GMPLS signaling, these objects are mandatory for ASON-compliant networks,
i.e., the Path message MUST include both GENERALIZED_UNI and CALL_ID
objects." 

"Note that LABEL_REQUEST, SENDER_TSPEC and UPSTREAM_LABEL are not required
for a call; however these are mandatory objects. As such, for backwards
compatibility purposes processing of these objects for a call follows the
following rules: 
    
   -    These objects are ignored on receipt; however, a valid-formatted 
        object (e.g., by using the received valid object in the 
        transmitted message) must be included in the generated message." 
============================================================================
====================================   

<zhi>The statement above about G.709 is irrelevant to the discussion. In
terms of sending G.7713 to IETF and asking to develop protocol...that's what
was done. Back on 2001 discussions were started on what requirements and
architectures are needed to support G.8080. Individuals (who happens to
participate in both IETF and ITU) then started submitting protocol
extensions. People either choose to ignore these or expressed opposition to
making these extensions simply because it went beyond the traditional IP
services.</zhi>

JD:  What you saying is not the same as what I am saying.  I am asking for
G.7713 to be sent as a formal liason to the IETF (CCAMP).  I am not asking
for individuals' interpretations of ITU specs.

<zhi>Existing mechanisms we mentioned may be used, but the preference would
be to use GEN_UNI for SPC (and this is in fact what we use for the ASON
specification). This is because (again) of the architecture assumptions made
in G.8080. An ASON network is assumed to be composed of multiple domains. In
the vision of a global ASON network you might have multiple carriers
connecting together (but also multiple domains within a single carrier
network). The interfaces defined for these inter-domain signaling is the
E-NNI interface. However, across an E-NNI the ERO object is an optional
object, and in certain instances the information may not be passed due to
policies that carriers may impose on the inter-domain interface.

If we were to use the ERO to carry the SPC information, then conceivably
there are cases where this information would not pass the interface.</zhi>

JD:  What standards body has defined the E-NNI? 

<zhi>I hope this helps to explain the issues expressed by John (of course I
expected John to understand call/connection as he was a member of ATM Forum
in developing the PNNI specification...)

JD:  During my time at the ATM Forum we were never able to get
call/connection to work.

---

From: "Ong, Lyndon" <[email-masked]>
Date: Thu, 23 Jan 2003 08:13:55 -0800

Hi Folks,

I can reaffirm Zhi's comment that call and connection separation 
goes back to G.8080, an already approved ITU specification of
the G.ASON architecture.

I'm a bit puzzled by the argument that no one but IETF should be
allowed to extend an IETF protocol - I would think that extensions
are generally allowed if they don't cause a limitation on 
the available codepoints and are documented to allow people
to use them.  Aren't some codepoint 
partitions designed for people to do this, without having to 
force all extension work through a WG?

Also, I would think that approving the drafts is just that,
approving the drafts and their contents as Informational
documents, it is not being asked that these become IETF Standards.

Cheers,

Lyndon Ong  

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: Thursday, January 23, 2003 3:59 AM
To: Lin, Zhi-Wei (Zhi)
Cc: Wijnen, Bert (Bert); Scott Bradner (E-mail); [email-masked]';
[email-masked]'; [email-masked]'; Lam, Hing-Kam (Kam); Malcolm
Betts (E-mail); Stephen Shew (E-mail); Ong, Lyndon; Alan McGuire
(E-mail); Trowbridge, Stephen J (Steve)
Subject: Re: Last Call: CR-LDP Extensions for ASON to Informational

All,

taking a step back - I think we are discussing several issues in a mix
that makes it very hard to sort this out.

1. What other organizations may do to IETF (in this context (G)MPLS)
    protocols

    This won't be sorted out in this thread - and the only opinion so far
    is that it is a bad idea to let anyone else change or extend IETF
    protocols.

    This will require at statement from involved wg chairs and ADs and an
    approval from the IESG. I will push for such a statement.

2. Have the IETF protocols been changed

    This is is a matter of how "changed" is defined. Clearly the OIF
    UNI signaling spec extends the LDP protocol, message and new TLV.
    This is referenced by a normative reference in the three drafts
    discussed here

    I understand that the IESG wants to treat those as a packet, and that
    the last call on the CR-LDP Extensions for ASON to Informational in
    fact is a last call on all three of them. Further this could be
    construed to be seen as an "last call" on normative references -
    after all normative references are considered to necessary for
    implementing a spec.

    Also, the ITU work extends the IETF protocols, new objects, new TLVs
    and new error codes, that is why the drafts were written - to make it
    possible for IANA to approve the needed code points.

    In our normal use of terms change includes extends, but we should
    probably make that clear.

    The consequence of approving the drafts will be that the extensions
    by OIF and ITU will be approved by the IETF. I'm not sure that this
    has been in the open.

    However, not having a change process that relates to these protocols
    I'm not sure if the IESG can do anything else than approving that the
    IANA allocate the code points.

3. The quality of the drafts

    In my opinion (if I were to review them as a wg chair, but I'm not
    sure that those criteria apply to informational documents) we have a
    problem here.

    The draft-lin-ccamp-gmpls-ason-rsvpte-04.txt and the
    draft-bala-uni-ldp-rsvp-extensions-04.txt is an a shape such that I
    would (reluctantly) request publishing.

    But the draft-aboulmagd-ccamp-crldp-ason-ext-02.txt is not, there is
    a long series of points that needs to be updated. References, TLV
    description, un-expanded acronyms, etc. Would have returned this to
    the author for further work. Aside from that I have a couple of
    technical issues.

    Now, if the IESG considers them to be a package, this would effect
    all of them. I guess that it would be possible to weed the draft
    after it has been approved, but it deviates from normal practice.

My belief is that we should try to separate these issues from each
other.

/Loa

-- 
Loa Andersson

Mobile          +46 739 81 21 64
Email           [email-masked]

---

From: "Stephen Shew" <[email-masked]>
Date: Thu, 23 Jan 2003 11:45:49 -0500

I agree with Zhi-Wei's points below.  On the matter of concensus I think the
original email implied "agreement" as opposed to the ITU-T meaning of
"consent".  The existence of the G.8080 and G.7713 (which are ITU-T
"consented") do mean that call and connection separation are agreed to in
the ITU-T.  This is why the notion is contained in all three signalling
draft recommendations (G.7713.x).  The call/connection architecture is well
established in ISDN and B-ISDN documents and so I think there is very wide
agreement on this concept.
 
As far as the call being carried by the connection, this is one of two call
setup models and has been called "logical separation".  In the second model,
the call is in fact separated from connection setup.  In either case, the
separation is useful for ASON services in that allows the transport network
to support calls with capabilities like redialing for restoration and setup
of diverse virtually concatenated connections.

-----Original Message-----
From: Lin, Zhi-Wei (Zhi) [mailto:[email-masked]] 
Sent: Wednesday, January 22, 2003 14:09
To: [email-masked]'; [email-masked]'; Wijnen, Bert (Bert); Scott Bradner
(E-mail); [email-masked]'
Cc: Shew, Stephen [SKY:QW33:EXCH]; Lyndon Ong (E-mail); Betts, Malcolm
[SKY:1ID0:EXCH]; Lam, Hing-Kam (Kam); Alan McGuire (E-mail); Lin, Zhi-Wei
(Zhi); [email-masked]'; Dimitrios Pendarakis (E-mail)
Subject: RE: Last Call: CR-LDP Extensions for ASON to Informational

Hi,
 
I wanted to respond to some of the comments raised by Kireeti.

With respect to the issue re call and connection separation, call and
connection separation is an architectural requirement that is fully
documented within Rec. G.8080.  Rec. G.8080 was liaised to the IETF quite
some time ago (it was Approved end  '01; Consented Oct. '01), and at every
meeting of the IETF for the past few meetings, there have been status
updates provided on associated ITU-T work efforts.    As you may recall, Kam
sent out an email earlier in reply to some other comments on where these
documents can be obtained.  Rec. G.7713, which also reflects call and
connection separation, was also sent to the IETF almost a year ago upon it's
Approval end of  '01

To find the information that has been transmitted from ITU-T to IETF on this
subject (from 26 October 2001), see:

ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATION
S/index.html
<ftp://sg15opticalt:[email-masked]/tsg15opticaltransport/COMMUNICATIO
NS/index.html> 

In terms of the formatting of the CALL_ID, Kireeti raised a question as to
why IP addresses only were not sufficient.   The answer to this illustrates
one  difference between the IETF and ITU-T scope.   The focus of the IETF is
upon IP-based client services while ITU-T has a multi-service focus,
including not only IP but also other types of services (such as ATM). As
such, it cannot be assumed that all NEs have IP addresses associated with
them. In addition, it cannot be assumed that, even if the NE has an IP
address, that those IP addresses are globally unique. As such, it was
necessary to come up with a identifier format that does not assume the
global uniqueness of an address.   The selected approach was to re-use
existing identifier formats (e.g., from the TTI format such as G.709) that
provides "free" globally unique identifiers.

As mentioned in the documentation for G.7713.x, the CALL_ID IS and NS is
used only when "global" uniqueness is needed. In the event that networks are
just been deployed or it's a single carrier's network where their addressing
space is unique, then they can use the "operator specific" CALL_ID format.
In this format the CALL_ID is essentially the IP address (if the type is
4-byte or 16-byte variety).

In terms of the "didn't hear a clear consensus on the need for this", the
text was published in Report COM15-24 (Part IIA of the report of WP 3/15).
According to ITU-T practice, inclusion in part IIA indicates that the text
is "agreed", although not at the point of "consent" ready to issue for a
Last Call. The agreement to place text in part IIA of a report occurs at the
final plenary of the Study Group meeting. This meeting was attended by
approximately 300 participants. The reason that the text was not put for
consent at the May 2002 meeting of Study Group 15 was to provide time for
comments on the text in response to liaisons sent to IETF ccamp and the ATM
forum, and to allow IANA assigned codepoints to be included in the document.
A clear U.K. national position paper was contributed to the meeting
currently underway (delayed contribution 483), supporting that all three of
the ASON signaling Recommendations should be put for consent at this
meeting.

Hope this helps...

Zhi

-----Original Message-----

Sent: dinsdag 21 januari 2003 16:42

To: Kireeti Kompella

Inline

don't you think so?

IETF document?

Bert

---

From: "Stephen Shew" <[email-masked]>
Date: Thu, 23 Jan 2003 11:59:17 -0500

On the separation of issues, I think that's helpful.  On issue 1, I think
that there is definitely precedent on use of IETF protocols by the ITU-T (I
think it was in the OAM area and SG13).  SG15's use of GMPLS protocols has
to do with extensions that enable them to fit into the ASON architecture.

I would like to point out that for G.7713.1 (PNNI based ASON signalling),
the ATM Forum has been very helpful in enabling the work and liaising back
to SG15.

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Thursday, January 23, 2003 06:59
To: Lin, Zhi-Wei (Zhi)
Cc: Wijnen, Bert (Bert); Scott Bradner (E-mail); [email-masked]';
[email-masked]'; [email-masked]'; Lam, Hing-Kam (Kam); Betts, Malcolm
[SKY:1ID0:EXCH]; Shew, Stephen [SKY:QW33:EXCH]; Lyndon Ong (E-mail); Alan
McGuire (E-mail); Trowbridge, Stephen J (Steve)
Subject: Re: Last Call: CR-LDP Extensions for ASON to Informational

All,

taking a step back - I think we are discussing several issues in a mix that
makes it very hard to sort this out.

My belief is that we should try to separate these issues from each other.

/Loa

-- 
Loa Andersson

Mobile          +46 739 81 21 64
Email           [email-masked]

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Thu, 23 Jan 2003 19:49:24 -0500

Parallel discussions on the thread 'IANA considerations for RSVP' (postings by Steve Trowbridge and David Charlap) and this thread (Loa Andersson) have shed some light on a) how extensions to GMPLS protocols to satisfy ASON requirements shifted from IETF to ITU, and b) the consequences:

steve> - On February 19, 2002, ITU-T sent IETF ccamp a liaison statement regarding
steve>   the gaps that had been identified between the ITU-T requirements (sent
steve>   earlier) and what seemed to be implemented by the GMPLS protocols.
steve>   Specifically,
steve>   1. Call & Connection separation, e.g., a call provides the service
steve>      relationship, which may support connection operations as part of a 
steve>      call. 
steve>   2. Additional error codes/values, for example, for connection rejection
steve>      (invalid connection ID). 
steve>   3. Restart mechanisms: Depending on the introduction by the ITU of 
steve>      additional control plane resiliency requirements, enhancements of the 
steve>      protocol (RSVP-TE, CR-LDP) "graceful restart" mechanisms may be 
steve>      required. 
steve>   4. Protocol enhancements in CR-LDP for support of crankback capability 
steve>      from intermediate nodes. 
steve>   This liaison was presented in the Minneapolis IETF meeting during the 
steve>   ccamp working group and posted on the IESG web site. The liaison requested
steve>   assistance in closing these gaps and invited input from IETF on our work
steve>   in ITU-T.

I recall this discussion and understood that the intent was to have extensions made by CCAMP to GMPLS protocols based on these ASON requirements and thus close the 'gaps'.

steve> - At the April/May 2002 meeting of ITU-T Study Group 15 meeting,
steve> contributions were considered to close these gaps, resulting in text for
steve> draft Recommendations G.7713.2 (our rsvp-te document) and G.7713.3 
steve> (our cr-ldp document). Again, we sent a liaison (dated May 10, 2002) to ask
steve> for comments on our draft Recommendations (made available on the ftp site),
steve> to request alignment, and to ask for IANA code point assignments. To quote
steve> from that liaison:
steve> "Please consider including the proposed solutions provided in G.7713.2 and 
steve> G.7713.3 to update the existing GMPLS signaling work in support of ASON 
steve> requirements.

I think this is consistent with the understanding that the intent was to have extensions made by CCAMP to GMPLS protocols based on the ASON requirements and thus close the 'gaps'.

steve> To hear now that someone thinks that the ASON work in ITU-T is some kind
steve> of secret end-run around IETF, and not involved with or related to the
steve> work being done internally in IETF is absurd. At every stage of the work,
steve> IETF was kept informed of the work and invited to participate. At the
steve> invitation for help to address the additional ITU-T requirements, there
steve> was no response. As ITU-T progressed this work and invited further comments
steve> and alignment of the base GMPLS protocols, again no response. And to the
steve> final pleas for comments and codepoint assignments, no response.
steve> ...
steve> After some private communication with the Area directors, we received some
steve> advice that one tool that might be used to finally get the IANA codepoint
steve> assignment complete would be to publish what we were doing in ITU-T as
steve> informational RFCs. This is the stage we are at today, and given the
steve> history I describe above, I do not think anybody can say that we are
steve> at this point because any of us did not do everything possible to
steve> do this work (a) in IETF, with the initial communication of requirements;
steve> or (b) in cooperation between ITU-T and IETF, once this work had
steve> progressed in ITU-T.
steve> 
steve> But this is all water under the bridge. We are at the point of trying
steve> to get some codepoints assigned for ITU-T documents we are trying to
steve> complete. Nobody should say "no" at this point because they think we
steve> didn't try to work this IN or WITH IETF first. It should be clear to
steve> all that this is not the case.

I can understand the frustration in not getting cooperation and follow-up on the ITU/ASON requirements.  However, the 'private communication with ADs' left most of us in the dark as to what was (is) going on.  

The concern still is (drawing from posts by Loa Andersson and David Charlap):

loa> The consequence of approving the drafts will be that the extensions
loa> by OIF and ITU will be approved by the IETF. I'm not sure that this
loa> has been in the open.

david> I'm far more concerned with non-IETF groups (like ITU, ATM Forum and 
david> others) deciding to develop their own incompatible extensions without 
david> even informing any IETF groups of their actions.
david> Groups like these should not be extending IETF protocols without 
david> consulting with the relevant IETF working groups.  Otherwise 
david> we end up with extensions that duplicate existing IETF functionality, 
david> don't coexist gracefully, and/or break interoperability.  And if these 
david> extensions become popular in products, the IETF will be forced to 
david> include them in the standards in order to prevent future IETF work from 
david> breaking them.

I agree.  

To give one concrete example of the consequences of not doing as David suggests: Now that the subject ID http://www.ietf.org/internet-drafts/draft-aboulmagd-ccamp-crldp-ason-ext-02.txt has been approved, the crankback TLV defined in Section 4.3 becomes the de-facto crankback TLV, no?  Further discussion/debate in IETF on other proposals (e.g., as proposed in http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-04.txt) becomes moot.  This doesn't seem to be the right process to arrive at this technical conclusion.

Jerry Ash

---

From: "Lin, Zhi-Wei (Zhi)" <[email-masked]>
Date: Fri, 24 Jan 2003 02:56:55 -0500

Hi Jerry,

I'm not sure how long you've followed the entire GMPLS and ASON work, but I'm assuming here that you weren't part of the original discussions over the last 1.5 to 2 years on this matter. That's understandable as this wasn't your original area of interest.

However, if you talk with some folks involved since the beginning, you would realize (and also reading Steve's email on the history, or simply going back to the email archives in both MPLS and CCAMP) that
(a) ITU-T tried to get the work done in IETF (I believe Steve mentioned Oct. 21, 2001)
(b) IETF never actually started/initiated work to fill these gaps. So a set of individuals who happens to attend IETF, OIF and ITU decided that they would work towards a solution
(c) This solution was submitted into IETF, OIF, and ITU -- with clear intention of trying to get feedback from the "true" RSVP experts
(d) I (and Bala) created I-Ds in IETF (Bala actually started this I think sometime in early 2002? -- Bala you can confirm or correct -- while I submitted my I-D in June 2002)
(e) These documents were never taken seriously (This is the first email I sent: http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00918.html -- but of course no one responded)
(f) ITU-T requests which were publicly presented in CCAMP meetings by Wesam and Steve (see Steve's email to see how many requests were made) were never taken seriously

The ITU-T delayed their process by several months in order for RSVP experts (I guess Bob Braden would call folks who's done this work "non-RSVP experts") to review. Of course no comments were ever provided by the "true" RSVP experts.

Several individuals tried very hard to try and get a good relationship and collaboration going amongst the three organizations. The break-down is not for lack of trying or exposing the work to the RSVP experts.

As such, although I agree that the original intent of all the individuals who came into this work expecting to collaborate and do the work in IETF CCAMP WG, the actual situation is very much different, and is a result of certain members of the CCAMP WG community deciding not to bother with paying attention to the work. Again I can understand the perception that you get since you weren't involved from the beginning. But a casual perusal of the email archives (too much work for me, if you're interested you should take a look at the history first) would give you a much better and accurate history of the discussions (see http://ops.ietf.org/lists/ccamp for the CCAMP email archive, and http://cell.onecall.net/cell-relay/archives/mpls/mpls.index.html for the MPLS email archive).

Thanks
Zhi

-----Original Message-----
From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]]
Sent: Thursday, January 23, 2003 7:49 PM
To: [email-masked]; [email-masked]
Cc: Ash, Gerald R (Jerry), ALABS; Stephen Trowbridge; David Charlap; Loa
Andersson

I agree.  

Jerry Ash

---

From: Bob Natale <[email-masked]>
Date: Thu, 23 Jan 2003 14:48:24 -0500

At 1/23/2003:11:13 AM, Ong, Lyndon wrote:

Hi all,

[I hope no one minds that I've trimmed the numerous individual
recipient names from the address headers on this thread! :-]

FWIW, I'd like to "second" the comments made by Lyndon below,
in all three parts of his message.

Furthermore, I'd like to add that the IETF leadership should
proceed along the lines of developing more positive and proactive
procedural relationships (quantitatively and qualitatively) with
related external SDOs, especially the OIF and ITU-T in the GMPLS
domain, for the purpose of maximizing overall solution quality
(i.e., how well our protocols play in the real world).  The bottom
line is that we need the benefit of the large-carrier requirements
gathering and specification tasks performed well by the ITU-T and
we can generally leverage the interworking applications analysis
and specification tasks being spearheaded by the OIF.  True, the
IETF does those same tasks at times, sometimes to a large degree
and sometimes to a very limited degree, sometimes successfully
and sometimes not.  Ideally, things will progress (over time) to
the point where formal work plans (divisions of labor) among the
IETF and relevant SDOs can be worked into WG charters and milestones.
There is really no sense in pretending that we can do otherwise
(or need to do so), in the general case, any longer.  [These
comments were intended as much for the "problem-statement"
topic as for this specific thread.]

Cheers,

BobN
- - - - -
>are generally allowed if they don't cause a limitation on the available
>codepoints and are documented to allow people to use them.  Aren't some
>codepoint partitions designed for people to do this, without having to

---

From: "Varma, Eve L (Eve)" <[email-masked]>
Date: Fri, 24 Jan 2003 10:34:12 -0500

Hi Gerry,

In your email, below, you indicate that "What was not well communicated is the the ITU decided (recently) to do the GMPLS/ASON extnesions themselves.  I think many of the postings on this thread indicate that people were not aware of,
and disagree with, this approach".

Quoting from an earlier message from Steve Trowbridge (see below), you can see that proposed extensions were communicated
to ccamp via a May 10, 2002 liaison, and presented at the following Yokohama IETF meeting.  This was subsequent to the Feb. 19, 2001 liaison identifying the gaps that had been identified and requesting support.

 "On February 19, 2002, ITU-T sent IETF ccamp a liaison statement regarding
  the gaps that had been identified between the ITU-T requirements (sent
  earlier) and what seemed to be implemented by the GMPLS protocols. Specifically,
  1. Call & Connection separation, e.g., a call provides the service
     relationship, which may support connection operations as part of a call. 
  2. Additional error codes/values, for example, for connection rejection
     (invalid connection ID). 
  3. Restart mechanisms: Depending on the introduction by the ITU of additional
     control plane resiliency requirements, enhancements of the protocol
     (RSVP-TE, CR-LDP) "graceful restart" mechanisms may be required. 
  4. Protocol enhancements in CR-LDP for support of crankback capability from
     intermediate nodes. 
  This liaison was presented in the Minneapolis IETF meeting during the ccamp
  working group and posted on the IESG web site. The liaison requested
  assistance in closing these gaps and invited input from IETF on our work
  in ITU-T.
- At the April/May 2002 meeting of ITU-T Study Group 15 meeting, contributions
  were considered to close these gaps, resulting in text for draft Recommendations
  G.7713.2 (our rsvp-te document) and G.7713.3 (our cr-ldp document). Again,
  we sent a liaison (dated May 10, 2002) to ask for comments on our draft
  Recommendations (made available on the ftp site), to request alignment, and
  to ask for IANA code point assignments. To quote from that liaison:
"Please consider including the proposed solutions provided in G.7713.2 and G.7713.3
to update the existing GMPLS signaling work in support of ASON requirements.
We hope that you can help expedite the assignment of appropriate additional
error codes/values by IANA.  These are needed for both RSVP-TE and CR-LDP."
  This liaison was presented at the Yokohama IETF ccamp meeting."

Best regards,
Eve

-----Original Message-----
From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]]
Sent: Friday, January 24, 2003 9:28 AM
To: Lin, Zhi-Wei (Zhi); [email-masked]; [email-masked]
Cc: Ash, Gerald R (Jerry), ALABS; Stephen Trowbridge; David Charlap; Loa
Andersson; Wijnen, Bert (Bert)
Subject: RE: Last Call: CR-LDP Extensions for ASON to Informational

Zhi,

I have followed the ASON and CCAMP work quite closely over the last couple of years.  I am quite familiar and mostly in agreement with your summary of events below.  

What was not well communicated is that the ITU decided (recently) to do the GMPLS/ASON extensions themselves.  I think many of the postings on this thread indicate that people were not aware of, and disagree with, this approach.

I can understand the frustration of not getting attention to the needed ASON requirements in IETF/CCAMP.  IETF/CCAMP had been saying (quoting statements made by chairs and ADs) they need to 'close the gaps' to meet ASON requirements as far back as IETF-53/Minneapolis (March).  CCAMP charter extensions to address same were suggested(IETF-54/Yokohama CCAMP meeting minutes say "The charter update is way overdue. Items may be added - protection/restoration, crankback and multi-area operations."), but CCAMP charter extensions are still pending even to this day.  

However, the answer is not for the ITU (or any other standards body) to extend IETF protocols, and visa versa.  This leads to interoperability problems, I believe, wherein we have 'ITU-TLVs', 'IETF-TLVs', 'OIF-TLVs', etc. for GMPLS protocols.  Furthermore, we are now inheriting many 'ITU-TLVs' for RSVP-TE and CRLDP.  This precludes, or at least inhibits, proper technical discussion to arrive at the best technical approach.  Further discussion on 'ITU-TLVs' (e.g., call control, crankback, etc.) is now moot.

Perhaps we can learn from this and improve the process, e.g.:

a) Bert has proposed a (G)MPLS change process (seems like a good idea),
b) better communication and responsiveness, especially from WG chairs on direct queries (e.g., 'where is the CCAMP charter update?' has been asked many times, but there is no response, still pending).

Regards,
Jerry

> Sent: Friday, January 24, 2003 2:57 AM
> To: Ash, Gerald R (Jerry), ALABS; [email-masked]; [email-masked]
> Cc: Stephen Trowbridge; David Charlap; Loa Andersson
> I'm not sure how long you've followed the entire GMPLS and 
> ASON work, but I'm assuming here that you weren't part of the 
> original discussions over the last 1.5 to 2 years on this 
> matter. That's understandable as this wasn't your original 
> area of interest.
> 
> However, if you talk with some folks involved since the 
> beginning, you would realize (and also reading Steve's email 
> on the history, or simply going back to the email archives in 
> both MPLS and CCAMP) that
> (b) IETF never actually started/initiated work to fill these 
> gaps. So a set of individuals who happens to attend IETF, OIF 
> and ITU decided that they would work towards a solution
> (c) This solution was submitted into IETF, OIF, and ITU -- 
> with clear intention of trying to get feedback from the 
> "true" RSVP experts
> (d) I (and Bala) created I-Ds in IETF (Bala actually started 
> this I think sometime in early 2002? -- Bala you can confirm 
> or correct -- while I submitted my I-D in June 2002)
> (e) These documents were never taken seriously (This is the 
> first email I sent: 
> http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00918.html -- 
> but of course no one responded)
> (f) ITU-T requests which were publicly presented in CCAMP 
> meetings by Wesam and Steve (see Steve's email to see how 
> many requests were made) were never taken seriously
> 
> The ITU-T delayed their process by several months in order 
> for RSVP experts (I guess Bob Braden would call folks who's 
> done this work "non-RSVP experts") to review. Of course no 
> comments were ever provided by the "true" RSVP experts.
> 
> Several individuals tried very hard to try and get a good 
> relationship and collaboration going amongst the three 
> organizations. The break-down is not for lack of trying or 
> exposing the work to the RSVP experts.
> 
> As such, although I agree that the original intent of all the 
> individuals who came into this work expecting to collaborate 
> and do the work in IETF CCAMP WG, the actual situation is 
> very much different, and is a result of certain members of 
> the CCAMP WG community deciding not to bother with paying 
> attention to the work. Again I can understand the perception 
> that you get since you weren't involved from the beginning. 
> But a casual perusal of the email archives (too much work for 
> me, if you're interested you should take a look at the 
> history first) would give you a much better and accurate 
> history of the discussions (see 
> http://ops.ietf.org/lists/ccamp for the CCAMP email archive, 
> and 
> http://cell.onecall.net/cell-relay/archives/mpls/mpls.index.html 
> for the MPLS email archive).
> 
> Thanks
> Zhi

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Fri, 24 Jan 2003 10:57:23 -0500

Zhi,

> (e) These documents were never taken seriously (This is the first email I
> sent: http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00918.html -- but of
> course no one responded)

Reminder, I responded to your email on June 18, very shortly after you posted (my email to you is attached below).  That I did this off the list was probably a mistake.   We (you, your co-authors, Adrian and I) then had a prolonged exchange of emails about the draft.  Adrian sent you extensive comments on the draft highlighting concerns, suggesting text, and pointing out nits. That you have a reasonably long list of acknowledgements and contributors suggests that the draft was not ignored.

As I commented in the attached email to you, "Would it be worthwhile to somehow 'package' the needed ASON extensions into a proposed GMPLS upgrade and presented to CCAMP as such?"  I still maintain that this would be the correct way to handle this: bring the requirements to CCAMP as a requirements draft, thrash them out, and get the necessary extensions adopted in CCAMP.  Rather, the ITU has developed protocol extensions for GMPLS, something outside the charter of the ITU I believe.

Jerry

-----Original Message-----
From: Ash, Gerald R (Jerry), ALASO 
Sent: Tuesday, June 18, 2002 12:58 PM
To: 'Zhi-Wei Lin'
Cc: Ash, Gerald R (Jerry), ALASO; 'Adrian Farrel'
Subject: RE: new draft: GMPLS for ASON

Hi Zhi,

> I've uploaded a new draft covering the GMPLS usage and extensions to 
> support the ASON requirements. This document proposes appropriate 
> extensions towards the resolution of additional requirements identified 
> and communicated by the ITU-T in support of ITU's ASON standardization 
> effort, and only provides the extensions for RSVP-TE signaling. Among 
> the major extensions include support for the concept of "call", as well 
> as support for setting up soft permanent connections.
> 
> http://www.ietf.org/internet-drafts/draft-lin-ccamp-gmpls-ason-rsvpte-00.txt

Looks good.  

I've attached some excerpts below from the (unpublished) IETF-54/CCAMP meeting minutes.  These also identify crankback, restart, etc. as 'gaps' needing to be filled.  I guess most of these are being worked on, including restart and crankback http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-03.txt (Adrian is currently providing a significant extension for the 04 version of the crankback draft).

Would it be worthwhile to somehow 'package' the needed ASON extensions into a proposed GMPLS upgrade and presented to CCAMP as such?  

Your comments/suggestions are appreciated.

Thanks,
Regards,
Jerry 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Steve Trowbridge

Outlined a variety of "gaps" in the current work:
  - Call and connection separation
  - Additional error codes/value
  - Restart mechanisms
  - Support for crankback
  - Support for soft permanent connection

See proceedings for details.

Eric Mannie: Referring to slide "Identified Gaps".  Gaps seem to be
very small.  Most of the points are solved, can be easily solved, or
are in the process of being solved.

Trowbridge: This was a preliminary scan.  Further review, might turn up
more issues.  Technologies are similar, so lets identify and minimize
gaps.

Dimitri: ITU requirements precede much of IETF work.  Preliminary
discussions indicate that the current gaps are covered by existing
protocol work.  Areas where additional work will be required are
probably minimal, but need to be looked at.  IETF may gain final
improvements by looking at ITU work.

Yong Xue: ITU is working on v2 ASON document so more things could turn
up as "gaps".  Further communication between ITU and IETF should
continue.

Trowbridge: Technology will evolve within both organizations.  Should
expend effort to make sure that they evolve together.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Osama Aboul-Magd -- draft-aboulmagd-ccamp-call-conn-separation-00.txt.

Draft addresses one of the issues that Tolbridge highlighted in his
talk - call and connection control separation.

Kireeti: There is an explicit statement from ITU requiring this.
There is nothing in the charter about this.  This is good stuff.  Ron
and I will go through a charter revision with Ads and discuss putting
this in the charter.  Also need to address other gaps that were raised
by ITU.

Scott: When you propose to add something to WG, it would be helpful to
state where it fits in the existing charter OR how and why charter
should be extended.

Eva: I think that it fits into the character as a requirement to the
signaling protocols.

Scott: OK - that is a good clean explanation that might save chairs
some time.

Yong: I second Eva's comment.

Kireeti: Need to figure out how to address other issues as well.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 24 Jan 2003 23:47:32 +0100

Yakov... good to see that you read all my postings ;-)

I think you are taking a few things out of context here.
When I was speaking up in the TE-WG, I was speaking up 
because I feel that the WGs under my responsibility would
work MUCH better if we can motivate as many people as
possible to actually read and comment on documents in the
WG. And when new work needs to get done in an IETF WG,
then I feel that we need to have many people to be willing
to contribute (at least read and comment).

I feel that we would also want that when we do an IETF
Last Call for work that originates in the IETF, that is
when we do an IETF Last Call for a document that comes
out of a WG. And in fact, for many IETF originated work
(even out of WGs), very few IETF Last Calls do generate
a lot of feedback. I will admit that in most cases, all of
us on the IESG would want to have lots more comment, also
positive comment in the form "I read it and it is good"
or some of the other forms I posted to the TE-WG mailing 
list.

When we need consensus from the IETF for code point 
assignments in a IANA controlled registry, and when we
need those for work that has been standardized (or is
being standardized elsewhere), so in this case in OIF 
and ITU-T, then I do not see that we really need to
have a lot of positive feedback from the IETF community.
In my view, what we are looking for is to find out if
the other organisation (or person) is not violating
the protocols such that it hurts or does harm.

In fact, several of the things that the drafts under
discussion request assignment for are things that most
of us in the IETF decided we did not want to work on.
ANd part of that was that many IETF-ers did not like
the approach, part of it was that we felt it was not
our competence or the area that we felt needed to be
addressed. So we send those people away, and they
found other places to do their work. 

We still do not have to like it.
But I do not see why we need to block code point assignments
as long as their work does not harm/hurt our own use of
the protocols in which they ask for code points.

Hope this helps and explains.
Bert 

Thanks,
Bert 

> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: vrijdag 24 januari 2003 16:36
> To: Wijnen, Bert (Bert)
> Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]; 
> [email-masked]; Stephen
> Trowbridge; David Charlap; Loa Andersson
> [clipped...]
> > Two points:
> > - the extensions to LDP were found to be in space that requires
> >   IETF Consensus, and so Scott and I asked for an IETF Last Call
> >   on the document. That is an explicit OPEN process
> 
> Quoting from the e-mail you sent recently:
> 
>   If not enough people (and 10 is the absolute minumum, but 
> having seen
>   the attendence of TWEG sessions, I'd expect 25 or more) can speak up
>   to state one of:
>   
>    - I read it and I am positive, it is good stuff
>    - I read it and I see no problems or objections
>    - I read it but I cannot determine if it is bad, but I can see that
>      what has been discussed in the WG is indeed in the document
>    - I read it and I have these nits/objections...
>    - I did not read it cause this is not relevant to my xxx 
> job/work/function
>    - I did not read it cause I think this is nonsense 
>   
>   Then I get the feeling that we're just allowing a small group of
>   people push their petty-project through the process. That seems NOT
>   good to me. We need serious WG participation in reading and 
> commenting
>   in one of these forums above, before we can declare that we have WG
>   consensus on a document to be presented to IESG for approval as RFC
>   (in whatever form).
> 
> Since (as you said) the extensions required IETF consensus, and
> with the above in mind could you please share with the rest of
> us the information on how many people spoke up about the draft
> to state one of:
> 
>    - I read it and I am positive, it is good stuff
>    - I read it and I see no problems or objections
>    - I read it but I cannot determine if it is bad, but I can see that
>      what has been discussed in the WG is indeed in the document
>    - I read it and I have these nits/objections...
>    - I did not read it cause this is not relevant to my xxx 
> job/work/function
>    - I did not read it cause I think this is nonsense
> 
> Yakov.
>

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 24 Jan 2003 16:06:12 +0100

By the way, the author (Aboulmagd) has in the meantime
informed the RFC-Editor that the "no derivitive work"
clause can be removed. So this doc now has the same
provisions as the on Bala adn Lin documents.

Thanks,
Bert 

> From: Scott Bradner [mailto:[email-masked]]
> Sent: vrijdag 24 januari 2003 15:15
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> > However, unless
> > I'm severely confused (which is always possible), the 
> prohibition against
> > derivative works came from the ITU side of the fence,
> 
> the prohibition is more not used all that often - two main cases where
> is is
> 	1/ vendor work publish for the information of the community
> 	2/ republishing a standard from another SDO 
> 
> just like we would not want the ITU "fixing" an IETF standard w/o our
> input it seems a reasonable desire to not have the IETF "fix" an ITU
> (or ETSI etc) standard w/o their involvement
> 
> Scott
>

---

From: John Drake <[email-masked]>
Date: Tue, 28 Jan 2003 05:07:43 -0800

> Sent: Friday, January 24, 2003 2:48 PM
> To: Yakov Rekhter; Wijnen, Bert (Bert)

JD:  Given that these documents don't go through a working
group last call, why is an absence of positive feedback a
an unnecessary (or bad) thing?  What is the mechanism to ensure
that a given document doesn't hurt or harm?

> found other places to do their work. 

JD:  Okay, I guess that's your story and you're sticking to it.  However,
that's not the impression I get from the Yokohama CCAMP minutes: 

"Minute takers were volunteered (Josh Broch and Eric Gray) 

Snipped...

Osama Aboul-Magd presented status on his draft on ASON extensions to CR-LDP.

He asked if the WG would accept this as a WG draft. 

Kireeti pointed out that there is a meta discussion on the issue of
progressing both CR-LDP and RSVP-TE in the MPLS working group tomorrow and
suggested that the discussion should be taken to the mailing list after that
has been addressed. 

Snipped...

Dimitri Papadimitriou discussed work on ASON extensions to RSVP-TE. He asked
if the WG believes this to be valuable work and should eventually be put
forward to the ITU. 

Kireeti talked about the need to work out the relationship with the ITU on
these issues. 

Choy asked why the work does nt include call/connection information. 

Kireeti said that the functional specification should first capture the
solution independent requirements. 

Stephen Trowbridge asked what further information the IETF requires. 

Dimitri and Kireeti answered the question in detail."

> the protocols in which they ask for code points.

JD:  There are still unanswered technical issues.