Re: Arbitrary concatenation proposals

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

Hi John,


> 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.
> 
> JD:  So your comments last week ("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?" are
> to be considered a momentary aberration?
> 

:-) My use of those colorful (probably less appetizing) analogies was
trying to remind folks that we should not fall into complacency and
simply accept something because it's there, but try to be diligent in
understanding why something was chosen. I did not mean it to imply
"please remove everything because it stinks". 

so if you want to consider it a momentary aberration, that's fine.
Sometimes I do get over-excited... ;-)

> * 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.
> 
> JD:  Why do we need to invent a new methodology for deciding whether to
> include transparency and arbitrary concat?  The existing methodology
> which is, as I understand it, rough consensus, should be sufficient.
> 

I was merely trying to help move things along. With all the discussions
going on, I thought that it would be useful to not only have rough
consensus, but to be able to say why it was chosen to allow other people
to understand the decisions. 

> * 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?
> 
> JD:  What does this have to do with transparency and arbitrary concat?
> There is a section written by Jonathan, which is perpetually not included
> in new revisions of the GMPLS base signalling draft, that describes this.
> 

Nothing with transparency and arbitrary. It was another item that needs
to be considered. Is Jonathan's text available somewhere?

> * 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?
> 
> JD:  As I understand it, we are involved in an iterative process and that
> as operational experience with GMPLS is gained, the protocols may have to
> be updated.
> 

That's fine. But I think in an iterative process, the first step taken
should try to meet certain requirements so that the iteration could be
shorter, or the amount of changes involves could be reduced...

Zhi