Re: Arbitrary concatenation proposals

[Zhi-Wei Lin <zwlin@lucent.com>]

Hi John,

Yes, the draft you referred to contains both arbitrary as well as
transparency. But you need to look at the context for that ID.

The I-D was submitted as a way to "enhance" the existing codepoints. I
did not try to specify what should or should not belong. And as I said
many times now, I am not requesting that these all be moved. I merely
want to know the metrics for including things.

Whether arbitrary/transparency should remain in GMPLS or as a separate
document again is up to the group, but I still like Rob's suggestion.

So let me propose that we try to cut this thread short, and see where we
are:

* I've outlined the features of both arbitrary and virtual in an earlier
email (I think it was technical). Any comments? Should we include that
type of comparison in the document?

* Yes, transparency is in the OIF carrier requirements document. So then
again, as I mentioned many times, if our metric is "more than 2
vendor/carrier" or "more than half of vendor/carrier community" or "it
should be included because", then let's include it. But where would it
be included? In the GMPLS or a separate document? Either way, it will be
captured.

* There has been several discussions/questions about GMPLS handling of
different exception cases. Have that been studied in detail? Is the RSVP
or CR-LDP currently able to handle these? For example, how should the
system behave when a signalling channel fail, but the transport link is
still up? Should we have a single behavior or could the behavior be
provisionable?

* There has been some comments about meeting various requirements. Is
the requirement supposed to come before the protocol is going to last
call, or it doesn't matter (i.e., we'll change the protocol if it
doesn't meet requirements), or requirement is irrelevant?

Zhi



John Drake wrote:
> 
> This is really odd.  Perhaps Eve would enlighten us on Lucent's change of
> heart
> regarding tranparency and arbitrary concatenation?
> 
> I.e., just last week Zhi-Wei Lin was using the phrases "if an idea stinks,
> it doesn't
> matter how many times some idea is presented, it still stinks that many
> times" and
> "if you see a million flies eating feces, would you also eat?" to describe
> them.
> 
> Certainly, he didn't feel that way when he included them in his draft?
> 
> Thanks,
> 
> John
> -----Original Message-----
> From: Mannie, Eric [mailto:Eric.Mannie@ebone.com]
> Sent: Tuesday, May 29, 2001 2:33 PM
> To: ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com; q11/15; t1x1.5
> Cc: 'rcoltun@redback.com'; 'kireeti@juniper.net'; Dimitri Papadimitriou
> (E-mail)
> Subject: Arbitrary concatenation proposals
> 
> Dear All,
> 
> About the industry support for *arbitrary* concatenation, *transparency* and
> *AUG-X, TUG-X, VTG*, I would like to recommend the reading of the following
> draft that was presented at the last IETF meeting:
> 
> http://search.ietf.org/internet-drafts/draft-lin-ccamp-ipo-common-label-requ
> est-00.txt
> 
>       "Common Label and Label Request Specification
>         for Automatic Switched Transport Network"
> 
> Abstract: "This draft completes the [GMPLS-REORG] draft and details
> technology specific issues. It proposes different approach and enhancement
> to [GMPLS-SIG] and [GMPLS-SIGEN]...."
> 
> In this draft the authors proposed signal types that combine the coding of
> the type of signal itself (including AUG-X, TUG-X and VTG), plus
> transparency, plus arbitrary concatenation, etc.
> 
> I would like to know if their products support arbitrary concatenation,
> AUG-X, TUG-X, etc ?
> 
> The authors (all from the same company) requested to incorporate their
> proposal for arbitrary concatenation, transparency, and the "group type" of
> signals into GMPLS. During this meeting, the authors were strongly convinced
> that their proposal should have been merged within GMPLS. This was also
> extensively discussed by e-mails.
> 
> >Again, in terms of metrics, what is considered "interesting for the
> >industry"? By the vendor community or the carrier community? I just want
> >us to be clear...no more, no less....
> 
> Well, I hope this helps, at least this vendor considered these features
> sufficiently important to write a draft of 16 pages, to present it and to
> defend it.
> 
> Of course, Errera Humanum Est (or something like that :-)
> 
> Kind regards,
> 
> Eric
> 
> Eric Mannie
> Technology & Standards Strategy Manager
> Network Engineering Strategy
> EBONE
> 
> Terhulpsesteenweg 6A
> 1560 Hoeilaart - Belgium
> 
> Tel:    +32 2 658 56 52
> Mobile: +32 496 58 56 52
> Fax:    +32 2 658 51 18
> E-mail: eric.mannie@ebone.com