[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving right along ...
Hi John,
> JD: If a valid technical issue is raised, the authors of a draft attempt
> to deal with it and their efforts are documented in a subsequent version
> of the draft. If the proposed solution is inadequate or someone has a
> better solution, then the proposed solution is either changed or fixed.
>
> I don't think an exhaustive public discussion of every possible solution
> is particularly useful. And as has been pointed out, we're dealing with
> rough consensus; this means that we don't necessarily need to get your
> approval for everything that we do.
>
<z>I guess I'm giving you the wrong impression again and making you mad
at me again...I didn't mean that it needs my approval or any such
things. I merely bring up a point that some items have not been
resolved, and was not really decided upon by the CCAMP group. Of course
my understanding was that there was some inadequacy, and the explanation
I've been given did not get through my thick skull yet...</z>
> JD: And Fong answered the questions completely.
>
<z>I thinkg Yangguang replied to this, so we can continue the discussion
on that thread instead. :-) </z>
> JD: The authors add it and invite comments and criticism. I have made
> several attempts to explain switching type to you, with no apparent success.
> I haven't had this problem explaining it to anyone else.
>
<z>Yes, and I thank you for explaining to me. It's just that what I
heard seems to say that "this seems like a good thing for multi-service
nodes" without really concrete reason how this makes the protocol better
or what problem it is solving. Maybe I'm been too academic in protocol
design cleanliness???
For example, even the LSP encoding type is really not necessary if you
think about it, since the port or interface that you use has been
discovered as a certain type of signal there. But of course that's not
the issue here...</z>
> JD: The attempt was made to address Juergen's comments. It would be nice
> for him, rather than you, to indicate whether they were adequately
> addressed.
<z>Yes, you're right. I should only care about my own comments and only
reply to my own comments and not use other people's words in my email.</z>
> As for you second point, we'd love to see valid technical issues and good
> technical solutions from you or anyone else. As St Francis said, he would
> accept wisdom regardless of the source.
>
<z>Good quote from St. Francis. I'll have to follow that more often. :-)
As for technical issues, I won't repeat other arguments as they've been
given (I'll let the others speak directly rather than speak for them --
I'm taking your advice!) :-)
But I do have one issue that actually Maarten and Juergen brought up
(since they haven't mentioned it yet in public I will paraphrase them):
For the label value for SONET/SDH or the label description in the
generic draft, the label is defined as directly representing the
"timeslot". Now if I have a control plane controlled transport network
that goes through a ADM that is not control plane controlled, as:
+--------+ +--------+ +--------+
| | ---1--------- | | ----1-------- | |
| | ---2--------- | | ----2-------- | |
| A | ---3--------- | B | ----3-------- | C |
| | ---4--------- | | ----4-------- | |
| | ---5--------- | | ----5-------- | |
+--------+ +--------+ +--------+
Now imagine A and C is part of GMPLS, but B is just a legacy ADM. So at
A you have labels 1,2,3,4,5 (imagine these as in the SUKLM format) and C
has labels 1,2,3,4,5 incoming.
Now imagine that at B, it actually has a fixed cross-connect that
connects A-1 (A's timeslot #1) to C-2 (C's incoming timeslot #2), A-2 to
C-3, A-3 to C-4, A-4 to C-5, A-5 to C-1.
Now when A GMPLS sends a message to C, the label it uses is "1".
However, the connection/LSP associated with timeslot "1" is actually the
label of timeslot "2" at C. </z>
Zhi