Subject: Re: FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

From: Zhi-Wei Lin <[email-masked]>
Date: Sun, 2 Mar 2003 11:21:05 -0800 (PST)

Hi John,
I was wondering about the statements you've made below, especially the one about "all of them can be handled with the existing Make Before Break component of RSVP-TE". I'm a little slow, so could you elaborate a little more as to how this is related to the call/connection concept, and how the make-before-break actually handles the call service concept?
Thanks
Zhi
 
 From: John Drake [mailto:[email-masked]]
Sent: Friday, February 28, 2003 4:15 PM
To: [email-masked]'; Varma, Eve L (Eve)
Cc: [email-masked]'; George Newsome; Stephen Trowbridge; Loa
Andersson; [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 

I agree with Eric.

As an example, we have call/connection separation, which has been kicking
around since the early days of ISDN. In discussions as to why it is needed,
the first reason is always "because". Once past that, I have consistently
heard four or five examples cited. What is interesting is that all of them
can be handled with the existing Make Before Break component of RSVP-TE. 

Thanks,

John

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: Friday, February 28, 2003 12:54 PM
> To: Varma, Eve L (Eve)
> Cc: [email-masked]'; George Newsome; Stephen Trowbridge; Loa
> Andersson; [email-masked]
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
> 
> 
> 
> Eve> For individual contributor drafts coming in, it's quite 
> appropriate to
> Eve> evaluate requirements and determine if they are 
> legitimate. It's a
> Eve> different case when another SDO, responsible for a 
> non-IP applications
> Eve> domain, has established a set of requirements related to 
> that domain.
> 
> I'd certainly disagree with that. Many of the 
> "requirements" I see from
> other organizations are not requirements at all, but 
> just dogmatic
> statements of connection-oriented religion. If the IETF 
> were to accept
> requirements from other organizations, it would quickly be 
> inundated with
> "requirements" to make IP behave exactly like ATM. In 
> fact, anyone who
> works in the PWE3 group can testify that such "requirements" 
> come in all the
> time. 
> 
> 
> 

---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, and more

---

From: Stephen Trowbridge <[email-masked]>
Date: Mon, 03 Mar 2003 09:03:02 -0700

Loa,
(I know it is a joke, but if there weren't some element of truth
to this it would not be so funny).

Let me try to explain why the interface between an individual and
IETF, and an the interaction between another SDO and IETF have to
be different:

Differences on the incoming side:
- The ID brought in by an individual represents his/her individual
opinion.
- A liaison statement from another SDO represents an approved consensus
view from that other organization. I don't so much care whether it is
in ASCII or not, but it does represent a consensus view that cannot be
claimed of the individual ID submission.

Differences on the outgoing side:
- The individual discovers the response to their proposal by participating
in the mailing list discussion, looking at the IETF web site, using the ID
tracker, etc.
- The above methods are not realistic or appropriate for other SDOs to
receive information on what is going on in IETF. It is not realistic to
think that I should get 300 people in my study group to subscribe to
ccamp and mpls and decide for themselves what IETF thinks of something
that was sent over from ITU-T. There is no way in a formal organization
like ITU-T for us to take stuff we found on email discussions or web
sites and consider this as input to a study group meeting. It is not
ITU-Ts place to be watching the email lists and judging for ourselves
what the IETF consensus reaction might be to a particular proposal
(in fact, depending on which emails one pays the most attention to, one
can get some widely varying ideas about what IETF "thinks"). It should
be up to IETF to judge the consensus and to tell ITU-T the result.

Liaison statements are a method that is widely used to communicate between
standards groups. IETF has gone for a long time without employing these.
We have had the rare case where an IESG member takes the initiative to
put a response together, but it has not been standard operating procedure
to:
1) Pay attention to incoming liaisons.
2) Make sure that any request (For Action or For Comment) gets a reply
   (Note that SDOs are not compelled do what was asked of them in an incoming
   liaison statement for Action - but whether or not they do what was asked,
   other SDOs nearly always reply and, if not doing what was asked, they
   explain why not or make a counter-proposal).
3) Generate liaison statements to inform other SDOs about work ongoing in
   IETF that the other SDO should consider when doing their work.
4) Use liaison statements to ask for an "official" position about the
   meaning or intent of standards from other organizations (I recall an
   earlier debate where different IETF participants had different
   understandings of how some T1X1/ITU-T standards were to be interpreted.
   It would have been best to cut that discussion short and just ASK
   T1X1/ITU-T what they meant. You can be sure that T1X1 and ITU-T would
   have responded!)

As the importance of IP protocols increases, and the work of IETF becomes
increasingly intertwined with the technologies and standards that are in
the domain of other SDOs, it seems to me to be ESSENTIAL that IETF begin
to incorporate the sending and receiving of liaison statements as part of
its normal operating procedure. 
Regards,
Steve

Loa Andersson wrote:
> 
> Steve,
> 
> Bala said it was a joke! And it wasn't hard to parse with a bit of humor.
> Actuall quite funny :). I guess I could make a very similar flow chart,
> in trying to discuss with some people around mpls.
> 
> But seriously claiming (you are not joking, are you?) that Balas flow
> chart demonstrates that we intend to give work "externally generated"
> a fast track to the trash I find below the level of this discussion.
> 
> The intention of the change process is to create a way for the (g)mpls
> technology area to recieve and handle new requirements and new ideas, the
> exact opposite of you are claiming.
> 
> In fact every time I send a new  ID (draft-andersson-xxxx-foo-00.txt) seen
> from the IETF and the working groups it is in some sense "external".
> What is that
> makes something that originates from "the other SDOs" so special from a
> technical
> point of view. The change process are focused on guaranteeing that new
> (g)mpls technology ideas are  evaluated based on their technical merits.
> 
> /Loa
> 
> Stephen Trowbridge wrote:
> 
> >Curtis,
> >I have no problem to seperate the liaison process from the internal process.
> >In fact, a good liaison process is needed that would have much broader
> >applicability than (G)MPLS protocols.
> >
> >However, I do disagree that we can go forward on one with out the other.
> >As Bala's flowchart shows, the effect of applying this draft to internally
> >and externally initated work alike is to give the externally initiated
> >work a fast track to the trash. Without the liaison process, this draft
> >seems to make what is already a bad problem with how we deal with input
> >from other SDOs even worse.
> >Regards,
> >Steve
> >
> >Curtis Villamizar wrote:
> >
> >
> >>In message <[email-masked]>, Loa Andersson writes:
> >>
> >>
> >>>- I don't think it is agood idea to describe the two process in the same
> >>>  document. the chnage-process is for our internal use, the liasion process
> >>>  is for our commuinication with other SDOs
> >>>
> >>>
> >>If we can agree on this, then we can move forward with your document.
> >>
> >>Curtis
> >>
> >>
> >
> >
> >
> >

---

From: "Varma, Eve L (Eve)" <[email-masked]>
Date: Mon, 3 Mar 2003 11:48:42 -0500

Hi all,

I'm still puzzled regarding how the separation of the liaison
process helps us solve the problem that I thought had
triggered this draft being generated.

I haven't seen any response yet to Steve's email below.

Best regards,
Eve

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Monday, March 03, 2003 9:56 AM
To: George Swallow
Cc: [email-masked]; Loa Andersson; [email-masked]; ccamp
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

All,
Lets try to zero in on what the problem really is.

I think that liaison handling (or the lack thereof) is not just a
problem. It is THE problem. Does anybody really believe that the
reason this draft exists in the first place is that there are a
bunch of individuals going wild trying to change or extend the
(G)MPLS protocols?

What seems to have generated most of the arguments is the handling
(or bungling) of the communications process (or lack of process)
with other SDOs. This is the process we need to fix.
Dealing with requests from individuals to extend or change the
protocols might be good to have a process for, but realistically,
has any individual made such a request yet? Why is this important?

Now, if we can agree that liaisons are THE problem,
there are two ways we can go:
- We can start work on a general purpose liaison process to be
applied across the whole of IETF (revival of one of the POIS*
working groups?).
- We could try to develop a pilot process for sub-IP (which is
where we seem to have a lot of the problems), and take what we
learn from its implementation to feed into a process that would
apply to the whole of IETF.

While I can appreciate that a general problem should usually have
a general solution, there is some appeal to taking the second
approach because (1) we could probably get something underway
faster; and (2) sub-IP seems to be where the lack of such a
process is causing us the most pain.
Regards,
Steve

George Swallow wrote:
> I think they need to be separate because the liaison draft should
> apply across the board to IETF / ITU interactions and this document
> applies only to (G)MPLS.
> 
> ...George
> 
> ==================================================================
> George Swallow       Cisco Systems                  (978) 497-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824

-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
Sent: Monday, March 03, 2003 11:35 AM
To: Stephen Trowbridge; George Swallow
Cc: [email-masked]; Loa Andersson; [email-masked]; ccamp
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

I think we have agreement to do a separate document on the liaison process? (as I'm writing, I see a mail just now from Scott saying this). Loa, not sure if you were volunteering the g-chng proc authors? They are probably the most appropriate. If you need support (either visible/ghosts), Steve (ok, Steve?) can help from the ITU perspective, I can help from the T1X1 side.

Steve, I agree for SDOs, the key problem is the lack of a liaison process. Regardless, for IETF, a change process is needed. The GMPLS work is just going to rfc status and there will be both individual and SDO requests for additions/changes. For the liaison process, I think we need to distinguish the communication protocol (administrative=receive/distribution/transmit) from the processing (administrative and technical) of the liaison request. Both need to be clarified.

Considering we agree to have a separate document for a liaison process, and applying a constructive filter to the mail exchange, Lyndon's mail and my mail have direct comments on the draft, any others?

As I noted previously, to distinguish this process from the liaison process, should either remove external standards bodies from the text or clarify "individuals of external standards bodies".

Agree with Lyndon, "dustbin" should be defined for non-ietf aware, i.e. a note describing the option as non-standards track=informational or experimental rfc.

As Lyndon says, resources in all the standards groups are extremely limited, it's in the industry and our companies interests to collaborate. Let's use this week for specific comments on the draft.

Deborah

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Monday, March 03, 2003 9:56 AM
To: George Swallow
Cc: [email-masked]; Loa Andersson; [email-masked]; ccamp
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

All,
Lets try to zero in on what the problem really is.

I think that liaison handling (or the lack thereof) is not just a
problem. It is THE problem. Does anybody really believe that the
reason this draft exists in the first place is that there are a
bunch of individuals going wild trying to change or extend the
(G)MPLS protocols?

What seems to have generated most of the arguments is the handling
(or bungling) of the communications process (or lack of process)
with other SDOs. This is the process we need to fix.
Dealing with requests from individuals to extend or change the
protocols might be good to have a process for, but realistically,
has any individual made such a request yet? Why is this important?

Now, if we can agree that liaisons are THE problem,
there are two ways we can go:
- We can start work on a general purpose liaison process to be
applied across the whole of IETF (revival of one of the POIS*
working groups?).
- We could try to develop a pilot process for sub-IP (which is
where we seem to have a lot of the problems), and take what we
learn from its implementation to feed into a process that would
apply to the whole of IETF.

While I can appreciate that a general problem should usually have
a general solution, there is some appeal to taking the second
approach because (1) we could probably get something underway
faster; and (2) sub-IP seems to be where the lack of such a
process is causing us the most pain.
Regards,
Steve

George Swallow wrote:
> I think they need to be separate because the liaison draft should
> apply across the board to IETF / ITU interactions and this document
> applies only to (G)MPLS.
> 
> ...George
> 
> ==================================================================
> George Swallow       Cisco Systems                  (978) 497-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824

---

From: John Drake <[email-masked]>
Date: Tue, 4 Mar 2003 10:05:39 -0800

Comments inline
.  
-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Monday, March 03, 2003 6:44 PM
To: John Drake; [email-masked]
Subject: RE: FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Hi John,
 
What you said is probably all true, but then that just gets to the fact that
there are multiple ways to skin a carrot. What you've specified using the
Notify probably works just as well. 
 
============================================================================
============================
JD:  You choose a design approach that is incompatible with GMPLS signalling
when there are other design approaches that are compatible with GMPLS
signalling?
============================================================================
============================  
 
  As for your other comments, as I said keeping a connection alive is not
the only call property, but just one. That doesn't mean it's not a
requirement anymore, just one of them. As for the assertion, you're probably
referring to this statement: "having a single call ID for a call makes
tracking of the service much easier as well". Well, yes it is an assertion I
guess, but I think it's an understandable assertion, no? How many IDs do you
want to be used to represent a single service offered to a customer?
 
As for the virtual concat support, you're right again that G.7713.x does not
support the general case either. This is because not all technical issues
have been resolved. But the call ID provides the method for enabling tying
the different virtual concat connections together as a single call service.
Again there are multiple ways to do this, and we've chosen one. 
  
============================================================================
=============================
JD:  Are you saying that your draft doesn't actually do what you originally
claimed it did?
============================================================================
=============================
 
Thanks for your comments! Definitely helps to identify what different
methods there are to solve the same problem.
 
Zhi

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Monday, March 03, 2003 8:55 PM
To: 'Zhi-Wei Lin'; 'Zhi-Wei Lin'; [email-masked]
Subject: RE: FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Comments in line. 
 
 A general comment is that it occurs to me that MBB and the RSVP path
protection I-D (
<http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-sig
naling-00.txt>
http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-sign
aling-00.txt) both take advantage of the fact that RSVP-TE already has a a
version of call/connection separation.  It might be prudent to examine its
capabilities before inventing a new mechanism
 
Thanks,
 
John
 
-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Monday, March 03, 2003 4:28 PM
To: John Drake; 'Zhi-Wei Lin'; [email-masked]
Subject: RE: FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Hi John,

Thanks for the clarification. Some more comments below...

Keeping a connection alive while attempting to reroute it after outage.
(This is basic RSVP and  MBB allows you to reuse links on the failed path.) 
[Zhi-Wei Lin]  I don't think the intent of the call is simply to allow to
keep connections alive.  

============================================================================
============================

JD:  Are you saying that the above is not a requirement?

============================================================================
============================

 A call is much more related to the concept of providing service to the
end-user. One of the services is the ability to keep a connection alive for,
e.g., billing purposes, and having a single call ID for a call makes
tracking of the service much easier as well. 

============================================================================
============================

JD:  This sounds like an assertion.

============================================================================
============================  

Establishing a new path for an existing connection so that links along its
current path may be taken out of service for maintenance.  (This sounds like
a definition of MBB.)
[Zhi-Wei Lin]  Same comment as above.
 
Keeping track of the circuits in a virtual concatenation group.  (I think
this is covered with the SDH/SONET signalling draft.)
[Zhi-Wei Lin] This is really not covered in full in the SONET/SDH signaling
draft. The current signaling draft puts a limitation on the virtual
concatenation by requiring that all component members of the virtual
concatenated signal travel along the same path. The general virtual
concatenation mechanism allows for each component of the virtual
concatenation group to travel along different paths. This is really where
the call concept comes in handy. Again note that call is not designed
specifially for the virtual concatenation, but it provides a nice way of
supporting the multiple routings for each component virtual concatenated
signal. 
 
============================================================================
============================
JD:  I don't think that multiple connections per call, especially
connections that take different paths, is supported in either G.8080 or
G.7713.x.  Furthermore the existing RSVP-TE mechanisms could be used to
support the general case 
============================================================================
============================
 
The other requirement I've heard is a need to have the ingress and egress
nodes perform a capabilities exchange prior to establishing a connection,
and that sounds like something Notify should be used for.
[Zhi-Wei Lin] Right, but this also means extending the Notify message. So
it's a matter of choosing one method for support versus another. Also using
the Notify to support this is just solving one part of the puzzle. It could
be done, but the call mechanism gives you all the above, plus the "service"
concept (whatever that is... ;-)  
 
============================================================================
=============================
JD:  It is not at all obvious from your draft whether you are:
 
 a) piggybacking a call ID on normal RSVP LSP setup 
 
or
 
 b) using a hacked up version of RSVP LSP setup to instantiate call state in
all of the nodes along a path from ingress node to egress node.
 
If it is the former, then using Notify is better because it allows a
capabilities exchange prior to the allocation of any network resources.  If
it is the latter, then using Notify is better because you are creating
severe interoperability problems with nodes that understand GMPLS signalling
but don't understand this hacked up version of RSVP setup, in support of
something which is supposed to be an ingress/egress node function.    
============================================================================
==============================
 
 For folks who wants to understand call, you can read G.8080 (that ITU-T G.
stuff again! ) or (*gasp!*) some of the ATM documents on call (Q.2981 I
think).  
 
============================================================================
==============================
JD:  As I've said before, during my tenure at the ATM Forum, we could not
get call/connection separation to work in PNNI.
============================================================================
==============================
 
 Of course those of you who still uses your telephone or even your cellphone
are everyday making a "call" (but only always one connection within the call
-- very limited, huh??) 
 
Thanks,
 
John
 
-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Sunday, March 02, 2003 11:21 AM
To: [email-masked]
Cc: John Drake
Subject: Re: FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 

Hi John, 

I was wondering about the statements you've made below, especially the one
about "all of them can be handled with the existing Make Before Break
component of RSVP-TE". I'm a little slow, so could you elaborate a little
more as to how this is related to the call/connection concept, and how the
make-before-break actually handles the call service concept? 

Thanks
Zhi 

I agree with Eric.

Thanks,

John

> works in the PWE3 group can testify that such "requirements" 

  _____  

Do you Yahoo!?
Yahoo!  <http://rd.yahoo.com/finance/mailtagline/*http://taxes.yahoo.com/>
Tax Center - forms, calculators, tips, and more

---

From: [email-masked]
Date: Tue, 4 Mar 2003 16:21:52 -0600

As someone trying to understand the IETF culture, this is probably the 
most enlightening thread I've seen.  Thanks.

I think the best description of the choices before the IETF were stated 
by Steve Trowbridge yesterday.  The processes defined by the IETF to 
accept and respond to liaisons are important to me, but perhaps less of 
a concern than hearing an agreement on the IETF procedures for 
addressing outside extensions to IP based protocols.

Ideally, each contribution can stand on its own merit or "weight."  
However, other organizations who use consensus as their mode of 
operation (using a different definition of consensus) complement that 
with a final voting process to clearly state the position of those 
organizations as a collective body.  The IETF can continue to address 
those contributions (liaisons) along with every other input as an ID, 
but because most every other organization has a clear liaison process, 
the IETF perspective will only be conveyed to those other organizations 
by the IETF drafts and RFCs.  Maybe there is agreement that that is 
sufficient, but it will probably not specifically address all liaison 
topics from outside organizations.

Regardless of the process that the IETF uses to address the 
contributions, network need for extensions, to address applications 
outside the IETF scope, will continue to be identified.  For that 
reason, there will be real network need for those extensions.  As Steve 
Trowbridge stated so clearly yesterday, the IETF must decide how it 
wants to respond to those outside applications.  This isn't necessarily 
a bad thing, but something we must come to accept.  The sooner an 
agreement is reached on the approach going forward, the sooner we can 
all get to work on the right solutions for the industry and get away 
from all this haggling over process and perspective.

Regards,

Mark Loyd Jones
Optical Transport and Networking
Sprint - Wireline Technology Development
913-794-2139

-----Original Message-----
From: zinin [mailto:[email-masked]]
Sent: Tuesday, March 04, 2003 2:39 PM
To: kireeti
Cc: sjtrowbridge; ccamp; mpls
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

<regular ietf'er hat on>

Monday, March 3, 2003, 2:26:06 PM, Kireeti Kompella wrote:
> Hi Steve,

> On Mon, 3 Mar 2003, Stephen Trowbridge wrote:

>> There is no doubt that liaisons CURRENTLY have no more wieght than
>> individual IDs

> This might be a fundamental difference between the IETF and other 
SDOs,
> the ITU in particular.  However, that still doesn't mean that this
> policy of the IETF's is wrong.  I happen to think that taking 
everything
> at its own merit rather than considering where it came from is the 
most
> democratic, equal opportunity means of handling it -- but that's a
> personal philosophy, not necessarily echoed by the IETF.

Bingo!

It seems to me that this is the only way to ensure fairness in the
IETF, actually. Once we start introducing any sorts of preferences or
"weights", it may become a too attractive backdoor around the IETF
process.

Also, what does "weight" of a liaison or an ID really mean in a
_consensus_ based organization? That we should suddenly have a worm
and fuzzy feeling about that doc? And how does this "weight" compare
to, for example, the weight of the consensus within the IETF to not do
what's proposed, if that happens?

Alex

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 05 Mar 2003 10:11:25 -0500

Dave,

>Alex:
>
>You are offering a compelling argument to eliminate crediting of any 
>authors on I-Ds etc.
>We can claim that there is no weight in a consensus based organization, 
>while we struggle to eliminate the practice of 20 plus authors on a draft.

         This is a completely different issue which to my knowledge
has been worked out by the IESG. If there are too many authors,
we put them in a contributors section and have a few editors.
As far as I know, IETF documents are given the same implicit weight no
matter who writes them.

         --Tom

>I would assume I'm not the only one to note this inconsistency.
>
>Cheers
>Dave
>
><snipped>
>
> >
> >Bingo!
> >
> >It seems to me that this is the only way to ensure fairness in the IETF, 
> actually. Once
> >we start introducing any sorts of preferences or "weights", it may 
> become a too
> >attractive backdoor around the IETF process.
>
> _consensus_ based
> >organization? That we should suddenly have a worm and fuzzy feeling 
> about that doc? And
> >how does this "weight" compare to, for example, the weight of the 
> consensus within the
> >IETF to not do what's proposed, if that happens?
>

---

From: Alex Zinin <[email-masked]>
Date: Wed, 5 Mar 2003 11:31:26 -0800

Jonathan,

  When the IETF suddenly loses its interest in one of its protocols
  and another SDO has a concentration of expertise on it, an
  individual IETF submission targeted to STD track will naturally
  receive such fast track processing.

-- 
Alex

Wednesday, March 5, 2003, 9:57:45 AM, Jonathan Sadler wrote:
> Just an observation...

> Its kind of interesting to note that this "equal weight"
> philosophy doesn't seem to extend to the IETF when sending
> things to other organizations.  Witness the recent proposal
> to ISO on IS-IS extensions:

> "IS-IS extensions submitted from the IETF to JTC1 will be
> processed under the JTC1 fast track procedure. To ensure the
> quality of such submissions, IETF SHALL apply to them the
> procedures for Proposed Standard submission according to
> [RFC2026]."

> Wouldn't it be reasonable for other SDOs that have done the
> same sort of quality check prior to sending something to the
> IETF to be given the same courtesy of "fast track"
> review/approval?

> Jonathan Sadler

> Alex Zinin wrote:

>> > This might be a fundamental difference between the IETF and other SDOs,
>> > policy of the IETF's is wrong.  I happen to think that taking everything
>> > at its own merit rather than considering where it came from is the most

> ============================================================
> The information contained in this message may be privileged 
> and confidential and protected from disclosure.  If the 
> reader of this message is not the intended recipient, or an 
> employee or agent responsible for delivering this message to 
> the intended recipient, you are hereby notified that any 
> reproduction, dissemination or distribution of this 
> communication is strictly prohibited. If you have received 
> this communication in error, please notify us immediately by 
> replying to the message and deleting it from your computer.

> Thank you.
> Tellabs
> ============================================================

---

From: Shahram Davari <[email-masked]>
Date: Wed, 5 Mar 2003 12:42:51 -0800

>From: Curtis Villamizar [mailto:[email-masked]]
>Sent: Wednesday, March 05, 2003 3:27 PM
>To: Shahram Davari
>Cc: [email-masked]'; [email-masked]; [email-masked]
>In message 
><[email-masked]
>>, Shahram Davari writes:
>> >reason, there will be real network need for those extensions.  
>> 
>> It might be a good idea to require that all IETF protocols support
>> vendor-specific extensions, so that they could be used by other SDOs
>> and for experiments.
>> 
>> -Shahram
>
>
>How does a committee experiment with a protocol?  AFAIK most SDOs
>don't "experiment" they just write standards without trying them out,
>then try to mandate that everyone implement them still not knowing for
>sure if they actually work.  Its the IETF that experiments first.
>That's the "running code" thing you might have heard about.

I didn't say the SDOs want to experiment. I said the vendor-specific
could be used by both SDOs and those who want to experiment.

>
>All of the protocols support extension mechanisms.  One or more
>vendors often experiment with protocol extensions, label documents
>with TBD for codepoints and pick an unused one temporarily.  Once
>sufficient consensus is achieved that the protocol extension is at
>least worthwhile, which often follows successful limited deployment,
>the TBD is given an IANA assignment while the details are worked out.
>This works just fine.

Who guarantees that the very codepoint they are using will not 
be standardized by IETF for other use, while they are experimenting it?
And why LDP has such extension? 
  
>
>Running code and successful deployment do carry weight in the IETF but
>even that is not absolute as evident by the MPLS/ICMP extensions which
>were successfully deployed but rejected.
>
>If you mean that any committee should be able to try to mandate any
>extension they please, then I don't think its a good idea.

I think IETF should provide vendor-specific extension (like the one in LDP),
and that other SDOs need to be free to use it for any purpose they want. If
their idea is not good, people won't use their extension, period. No harm is done 
to the protocol.

-Shahram

---

From: John Drake <[email-masked]>
Date: Wed, 5 Mar 2003 13:27:41 -0800

> Sent: Wednesday, March 05, 2003 11:56 AM
> To: [email-masked]
> Hi John (also Dimitri),
> Responding to your email and Dimitri's. I did not have a copy of your 
> email (apparently I was "delete button" happy last night and 
> just wiped 
> all email away)...
> 
> I was just wondering whether you've actually read the 
> documents on the 
> ASON extensions.

JD:  Far too many times.  As I have indicated before, given the
dearth of material, it's a little difficult to figure out what
you were thinking.

 For instance, your comments about the compatibility 
> with GMPLS seems a strange comment. If you look at the ASON 
> extensions, 
> you should have noticed that the object-class numbers that was 
> requested and assigned are in the range where any RSVP-aware 
> node that 
> does not understand the ASON objects would simply forward them. From 
> the perspective of the ASON models, the objects are 
> associated with the 
> call controller. Call controllers are not pervasive at every location 
> within the network. Only call controllers need to understand this. If 
> an operator deploys a network with call controllers then that would 
> suggest that the nodes that has to perform call controller function 
> must therefore have this capability. All other nodes may remain GMPLS 
> nodes. From the perspective of the model, the GMPLS nodes 
> that are not-
> ASON extension aware will simply serve as the connection controllers 
> and simply forward the ASON objects forward to the call controllers.

JD:  The issue is that these nodes will assume that a call without
connection is actually a connection and will allocate resources for it.

> 
> Your other comment was about the use of the Notify message 
> for the call 
> purpose. Again, if you've read the document you would notice 
> that there 
> are two call/connection models that need to be supported: one is the 
> call with connection, and one is call without connection. My 
> understanding is that call with connection is the one ITU wants to 
> handle first.

JD:  My reading of G.8080 and G.7713 was that they prioritized call with
connection first was that they thought call without connection was too
hard, but it was what they really wanted. 

 As such the document mainly talks about call with 
> connection. Using the Notify message, the Notify message 
> cannot set up 
> connections. All it can perform by the very nature of the 
> definition of 
> the Notify message is to handle a call.

JD: Correct
  
> This means that the Notify can 
> only be used to support call without connection, and a separate 
> mechanism is needed for call with connection. So here I see that the 
> current method defined for the ASON is actually more flexible and 
> covers both cases.

JD:  Except for the fact that it doesn't work for the case of call without
connection.  I.e., I think you will need two mechanisms. 

> 
> Your other issue about the support for the generic virtual 
> concatenation capability. You're right we don't cover this yet. My 
> understanding is that the ITU is still working out the 
> technical issues 
> of this and the requirements for how things should behave. Once these 
> decisions have been made, I'm assuming the next logical step 
> is to ask 
> IETF RSVP experts for help and feedback. Hopefully this time around, 
> when the request for help comes in, people will not ignore it for 1-2 
> years and then simply make lots of noise at the end saying that they 
> weren't aware of any of this...

JD: Oh now.  Actually, if you use call without connection, I think
a lot of these issues go away.

> 
> Another items just to make people aware so that we don't get 
> into this 
> mess, ITU is currently starting up work to add full 
> protection/restoration and crankback capability to the ASON 
> model. This 
> work is just starting and at the formulating stage, i.e., getting the 
> requirements done. I believe as Kireeti mentioned there were liaisons 
> to this effect sent to the CCAMP. One of the inputs that ITU is 
> expecting is to have someone bring in the existing work that's been 
> done for the restoration/recovery/protection architecture and 
> framework 
> work (part of the design team I believe). I think Dimitri was very 
> aware of this item, and since Dimitri is one of the active 
> contributors/authors for this work, I hope that he will, along with 
> other contributors/authors, be submitting this work to ITU to 
> help with 
> the specification. 
> 
> Let's try and start working based on a more collaborative 
> mode instead 
> of simply making these noise.
> 
> Looking forward to hearing your responses!
> 
> Zhi
> 
> 
>

---

From: [email-masked]
Date: Thu, 6 Mar 2003 09:25:10 -0600

I don't understand how the development of a "major extension" by another 
group would necessarily indicate a "complete breakdown in relationship." 
 If that were the case, then the "veto" of the ITU-T based requirements 
and models have already shown we are in that condition now.  The 
continued discussion between IETF and ITU-T now proves that is not true.

The extensions by other groups only indicates differences in 
applications, models, scope, etc.  The development of "major extensions" 
by outside SDOs will continue unless the IETF decides to accept the 
applications defined in other organizations as serious work items.  As 
long as the IETF scope is focused on supporting and enabling IP, there 
will be broader applications that require those extensions that the IETF 
participants will not be willing to address.

I hope the IETF can find a way to retain ownership of the base protocols 
like GMPLS, while recognizing the fact that other applications will 
require extensions by other groups.  Those extensions should not 
infringe on the IETF application of the protocols as long as the 
applications defined by the IETF are clearly stated.  Only if the 
outside groups decide to address the exact same application as the IETF 
would I concede that we have a "breakdown in relationship."

To work this out, there needs to be a way for the IETF to respond to 
queries by outside groups about whether the IETF will or will not 
address the precise application of concern in another SDO.  Simply not 
agreeing to that application or not acknowledging the requirements in 
not a valid response.  The IETF then will retain control over which 
applications it will work on and which ones it will pass on.  I don't 
know if this is a liaison process or discussion of an ID, but some 
mechanism is needed for other organizations to hear whether they need to 
do their own extensions or whether they can expect the IETF to address 
them.

Mark Loyd Jones

-----Original Message-----
From: Shahram.Davari [mailto:[email-masked]]
Sent: Thursday, March 06, 2003 9:10 AM
To: curtis
Cc: zinin; Mark.Jones; ccamp; mpls
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

>> 1) Is the decision on how to deal with extension requests, an IESG
>> decision or an IETF consensus is required?
>
>If it is published as an informational recommendation by the IESG,
>then no.  The IESG does have veto power over internet-drafts that are
>on the standards track, therefore it might be worth paying attention
>to their recommendations.

Using their veto power against IETF community's consensus, seems "a 
complete breakdown of relationship" between IETF community and IESG.

>
>btw- I should also point out that Scott Bradner does not make this
>stuff up without talking to the other members of the IESG.

I know. but IESG != IETF

>
>> 2) No one can stop other SDOs from extending any IETF protocol
>
>True.
>
>> 3) The draft says:
>> 
>>    "No individual, vendor, SDO or forum should be able 
>create what is viewed
>>    to be a major extension to an IETF protocol on its own and
>>    legitimately be able to claim that implementations that 
>implement the
>>    extension are compliant to the IETF specification."
>> 
>> So if the other SDOs don't claim IETF compliance, rather 
>they claim their
>> respective organizations compliance, there should not be any 
>problem. And if 
>> they mess up nobody would blame IETF for that.
>
>This would represent a complete breakdown of relationships.  I'm not
>making any value judgement, just an observation.

Why? are you saying that if an SDO wants to define a brand new protocol 
(let's say MPLSv2),
but to reuse some parts of an existing IETF protocol, then they 
shouldn't do it because
IETF will get mad at them?

-Shahram

>> >Sent: Wednesday, March 05, 2003 5:34 PM
>> >To: Shahram Davari
>> >Cc: [email-masked]'; Alex Zinin; 
>[email-masked]';
>> >[email-masked]; [email-masked]
>> ><[email-masked]
>> >>, Shahram Davari writes:
>> >> Is IESG=Curtis?
>> >> 
>> >> -Shahram
>> >
>> >
>> >That looks like a cheap shot of some kind.
>> >
>> >IESG == draft-iesg-vendor-extensions-00.txt
>> >
>> >  3.  Recommendation
>> >
>> >   The following principles are the main guiding principles 
>concerning
>> >   extensions to IETF protocol:
>> >
>> >    o All major extensions to IETF protocols should be done 
>with direct
>> >      involvement of the IETF.
>> >
>> >    o The decision on whether an extension is major or 
>minor should be
>> >      done with the direct involvement of the IETF.
>> >
>> >Those words are from the IESG draft.  They are not my words.
>> >
>> >I thought that was obvious enough in my prior reply, but apparently
>> >not.
>> >
>> >Curtis
>> >
>> >
>> >> >Sent: Wednesday, March 05, 2003 4:53 PM
>> >> >To: Alex Zinin
>> >> >Cc: Shahram Davari; [email-masked]'; 
>> >[email-masked];
>> >> >[email-masked]
>> >> >In message <[email-masked]>, Alex 
>Zinin writes:
>> >> >> Wednesday, March 5, 2003, 11:12:10 AM, Shahram Davari wrote:
>> >> >> [...]
>> >> >> Ouch... draft-iesg-vendor-extensions-00.txt
>> >> >> 
>> >> >> Alex
>> >> >
>> >> >
>> >> >Looks like the IESG doesn't agree with Shahram on this.
>> >> >
>> >> >Curtis
>> >> >
>> >> 
>> >
>> 
>

---

From: Shahram Davari <[email-masked]>
Date: Thu, 6 Mar 2003 08:23:11 -0800

Scott,

What is the best mailing list to discuss this draft?

-Shahram

>From: Scott Bradner [mailto:[email-masked]]
>Sent: Thursday, March 06, 2003 10:49 AM
>To: [email-masked]; Shahram Davari
>Cc: [email-masked]; [email-masked]; [email-masked];
>[email-masked]
>> Using their veto power against IETF community's consensus, seems 
>> "a complete breakdown of relationship" between IETF 
>community and IESG.
>
>see the message I posted
>
>Scott
>

---

From: Scott Bradner <[email-masked]>
Date: Thu, 6 Mar 2003 12:21:53 -0500 (EST)

> Is the IETF process for replying to liaison statements (and of
> generating them) written down, say in some RFC?  If so, could you
> send me a pointer?

no (and thus no)

Scott

---

From: Scott Bradner <[email-masked]>
Date: Thu, 6 Mar 2003 12:24:48 -0500 (EST)

> Liaisons can be *generated* anywhere, but should be *sent* through a
> predictable agent. 

see 3356 - in the case of the ITU-T the sending must CC the AD so
that the ITU-T knows that the liaison is legit

Scott

---

From: John Drake <[email-masked]>
Date: Thu, 6 Mar 2003 09:45:31 -0800

Curtis,

Oops, sorry.  I was reading the statement as saying that GMPLS could not be
used for inter-AS (or inter-domain in ASON terminology).

Thanks,

John

> Sent: Thursday, March 06, 2003 7:54 AM
> To: John Drake
> Cc: 'Yangguang Xu'; [email-masked]; Zhi-Wei Lin;
> [email-masked]
> In message <9D42C6E086250248810DCADA39CE7EFC9722BB@nimbus>, 
> John Drake writes:
> > 
> > 
> > > From: Yangguang Xu [mailto:[email-masked]]
> > > Sent: Wednesday, March 05, 2003 2:55 PM
> > > To: [email-masked]; Zhi-Wei Lin
> > > Cc: [email-masked]
> > > Hello,
> > > Some thoughts below, related to both John and Dimitri's response.
> > > 
> > > We need to differentitate end-to-end operation and 
> > > edge-to-edge operation first.
> > > GMPLS deals with edge-to-edge connection, G.7713 extends 
> the scope to
> > > end-to-end.
> > 
> > JD:  Oh really?  Where did you read that limitation on the 
> scope of GMPLS?
> 
> 
> WG charter.
>    
>    The CCAMP working group coordinates the work within the IETF
>    defining a common control plane and a separate common measurement
>    plane for ISP and SP core tunneling technologies.
> 
> and 
> 
>    - Using input from the TE working group, ensure that the signalling
>      and measurement protocols provide both the information and the
>      control functions adequate to support the traffic provisioning
>      and engineering operations of service providers.
> 
> GMPLS is for "core tunneling technologies" and requirements are to
> come from the TE-WG.
> 
> GMPLS is not intended for end to end connections according to the WG
> charter.
> 
> ASON or any end to end connection oriented technology is not accepted
> by the IESG or IETF as a whole as a requirement and therefore there is
> no WG to work on ASON requirements.
> 
> The closest thing to ASON is PWE3 which is definitely not ASON.
> 
> Perhaps the best thing would be for ASON to be considered in a
> requirements WG (like IPO, but separate from IPO) and reviewed, not
> rubber stamped.  This would be consistent with the current process
> which is for an internet-draft to be reviewed by a WG, the IESG, then
> the IETF last call and IESG/IAB decision.  There have been requests
> for requirements in the past that were far enough outside of the IETF
> mainstream to warent a WG to defined the requirements.
> 
> Curtis
>

---

From: [email-masked]
Date: Thu, 6 Mar 2003 18:51:45 -0000

Thanks Mark.....the voice of reason!  I absolutely agree with you that
whilst there is potential merit in bringing L3/2 together (if we can get a
decent specification for MPLS.....and most here are not convinced on that
one yet) there is no case at all to bring it together with L1/0.  We made
the point way back in the Freeland draft (Nov 2000) that we saw no case for
the peer-model and have been consistently ignored ever since....and it's
kind of ironic to see this realisation now dawning on others, ie the move to
the 'overlay' model'....better late than never I guess. 

regards, Neil

> From: [email-masked] [mailto:[email-masked]]
> Sent: 06 March 2003 15:14
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> I agree with the separation of GMPLS into the two 
> applications.  There 
> does not appear to be any significant move to collapse the 
> management or 
> signaling for L3/2 and L1/0 at this time, given the different models 
> that apply for them and the infrastructures in our companies 
> that manage 
> them.  The plan for addressing the two applications need not be the 
> same.
> 
> The L3/2 application is near and dear to the heart of the IETF.  The 
> L1/0 application is of interest to those who wish to collapse the 
> management into a single layer.  In my opinion, the IETF might also 
> address this approach, given the IETF participants are the ones in 
> support of this collapsed management or at least common protocol 
> solution for what is today two signaling layers.  However, as stated 
> before, the collapse approach is not realistic today for a 
> multi-service, multi-protocol network.
> 
> On the other hand, the L1/0 application requirements and models have 
> been defined and are best understood at the ITU-T.  Ideally, the 
> protocol expertise at the IETF would be applied to the ITU-T 
> model and 
> requirements to address the L1/0 application, but attempts to do that 
> have been met with great resistance in the past.  Perhaps that was a 
> result of the fact that GMPLS implementations were not separated out 
> into the two different applications.  However, I don't think it is 
> realistic to expect the IETF experts to be motivated to 
> understand the 
> ITU-T models and requirements, given the application is 
> outside of their 
> primary area of interest.  That said, I believe the IETF 
> should reach an 
> agreement on how to work with outside groups that develop "major 
> extensions" to the protocol.
> 
> Mark Loyd Jones
> From: dwfedyk [mailto:[email-masked]]
> Sent: Thursday, March 06, 2003 7:49 AM
> To: gash
> Cc: mpls; ccamp
> Along the lines of Jerry's comments.
> 
> When we put together GMPLS the first drafts were under specified 
> intentionally to capture the essence of GMPLS. We put aside many 
> arguments saying lets specify at a high level and fill in the details 
> later. The discussions on this thread are in two major veins one 
> attempting to fill the details and the other containing and 
> controlling 
> the changes. GMPLS needs to be specified more accurately and in my 
> opinion it needs to be decomposed to a more layered approach. 
>  I think 
> if we applied GMPLS at at some layers (L3/2), (L1/L0) for example,  
> independently but self similar it would offer a mechanism to move 
> forward where some legacy systems could be specified to be GMPLS 
> friendly. For example signaling for Layer 3/2 can be tunneled through 
> the a lower layer. We already have some work in this direction. 
>  Similarly traffic engineering information for L1/L0 in a TE database 
>  would need different  attributes than a the TE database at L3/2. I 
> don't think you want to burden a L3/L2 system with these 
> attributes in 
> an overlay model. The expertise for these layer is not all 
> contained in 
> the IETF. I think we should put a plan forward to make this happen 
> within the IETF process. After this was accomplished  I think some 
> people are thinking of collapsing layers even more but the logical 
> partitioning of layers may help keep the protocols and databases 
> simpler.   Right now were are treating GMPLS like a big bowl of jelly 
> when it should look more like a layer cake.
> 
> Regards,
> Don
> 
> 
> 
> 
> 
> 
>

---

From: "Varma, Eve L (Eve)" <[email-masked]>
Date: Thu, 6 Mar 2003 15:07:23 -0500

Hi,

I'm somewhat surprised that in the discussion of requirements, there's
been no reference to the ipo wg internet draft

http://www.ietf.org/internet-drafts/draft-ietf-ipo-carrier-requirements-05.txt

Eve

-----Original Message-----
From: Gert Grammel [mailto:[email-masked]]
Sent: Thursday, March 06, 2003 2:21 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]

Mark,

'improving the coordination between the IETF and ITU-T' is one of the things I'd
like to see since years. However in my experience the true barrier between both
groups is not so much the technology as such, but some ignorance about the core
aspects in both organizations. To give a balanced figure here:

  1. You remember the thread about the non-standard SDH/SONET extensions. Here
     some guys active in GMPLS tried to push their ideas about transparency.
     Obviously this was perceived on ITU-T side as a challenge on the purity of
     a standard (G.707). This one was (almost) setteled by moving all
     non-standard features to an informal draft.
  2. Now it is the other way round. Somehow ITU-T extensions got accepted (again
     informational) in IETF which do not comply to the purity of RSVP-TE. Due to
     the fact that this informational RFC was not reviewed in CCAMP before, it
     is perceived as an assault.

So the match is tied up 1:1 but maybe it's now the right time to find a solution
on how to proceed. What I've seen so far was a complete misperception of what is
required on either side and why.

  1. ITU-T basically started by defining user services having in mind layered
     transport platforms like OTH and SDH/SONET. Those services can be
     summarized as 'Bandwidth on Demand' services (BOND). Naturally this led to
     a very strong focus on UNI interfaces and a kind of ignorance of networking
     protocols. You probably remember the discussions on why not using SS7? (For
     those not familar with the issue: SS7 is the signaling protocol between
     PSTN switches)
  2. IETF started with established L2/3 protocols (OSPF, RSVP-TE, ...) and
     extending their scope to L1 technologies namely SDH/SONET and OTH.
     Naturally this led to a very strong focus on protocol consistency and a
     kind of ignorance on service aspects other than those already available in
     MPLS. You may remember here the discussion about whether UNI is useful at
     all some time ago.

So putting everything together means that it is required to keep (IETF) protocol
consistency but adding some (ITU-T) specific extensions to well defined service
points in the network (UNI).
Unfortunately service points tend to exchange messages between themselves and
this would mean that an intermediate protocol would have had to support such
kind of communication. What concerns the IETF community is probably not the fact
that there is a UNI somewhere, but the changes and extensions to etablished
protocols in order to achieve a collaboration between them.

I recall that this was the basic issue with the ITU-T proposal when it was
presented for the first time in Yokohama. The way I've got Kireeti's message
there was: please authors try to let us understand what problem you want to
solve and tell us which kind of information you have to exchange between which
points to achieve it. We'll sort out then in CCAMP what would be the most
appropriate way to implement it, while maintaining consistency in our protocols.

Although it didn't work the first time I still consider Kireeti's suggestion to
be a wise way to move forward and perhaps the key for harmonic collaboration.

Regards

Gert

[email-masked] wrote:

> Gert,
>
> I agreed with the intent in generalizing MPLS for the wide range of
> expected applications.  It was my hope that it would succeed.  At this
> point, one might say that the intent has only been partially achieved.
> The problem that has come to light over the past year is the fact that
> there are finer points of the ITU-T model and requirements that are not
> supported by the current IETF GMPLS RFCs and standards track drafts.
> Those aspects are considered significant enough by many carriers and
> their suppliers to warrant further extensions outside of the IETF.  (My
> apologies for not understanding those points well enough to clarify them
> even in examples, but there are many people on this list would could do
> so if they thought it necessary.  To avoid any misunderstand, all should
> know that Sprint does not yet have a company position on this.)  It is
> my hope that we can come up with ways of improving the coordination
> between the IETF and ITU-T.  This thread of discussion is bringing out
> the issues to make that happen.
>
> Regards,
>
> Mark Loyd Jones
> From: Gert.Grammel [mailto:[email-masked]]
> Sent: Thursday, March 06, 2003 10:17 AM
> To: Mark.Jones
> Cc: dwfedyk; gash; ccamp; mpls
> Mark,
> please don't forget that due to the 'Generalization' of GMPLS you are
> free to do
> the split at any application level you wish. This was always the
> advantage of
> the GMPLS approach compared to the ITU-T model where initially each
> layer had
> its own control plane. So the fact that in theory you could use a single
> control
> plane for all your network means also that you are able to stop where
> you want.
> Nice feature isn't it?
>
> Regards
>
> Gert
>
> [email-masked] wrote:
>
> > I agree with the separation of GMPLS into the two applications.  There
> > does not appear to be any significant move to collapse the management
> or
> > that apply for them and the infrastructures in our companies that
> manage
> > protocol expertise at the IETF would be applied to the ITU-T model and
> > realistic to expect the IETF experts to be motivated to understand the
> > ITU-T models and requirements, given the application is outside of
> their
> > primary area of interest.  That said, I believe the IETF should reach
> an
> > opinion it needs to be decomposed to a more layered approach.  I think
> > don't think you want to burden a L3/L2 system with these attributes in
> > an overlay model. The expertise for these layer is not all contained
> in
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:[email-masked]

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:[email-masked]

---

From: [email-masked]
Date: Thu, 6 Mar 2003 22:48:37 -0000

Thanks Gert....I have tried to answer you below.  regards, Neil

Gert Grammel wrote 06 March 2003 19:57
>   1. I never understood why you were so emotional on overlay 
> models as compared
>      to peer but at the same time advocate to use PNNI (Peer 
> Network to Network
>      Interface) as an alternative.
NH=> The L1/0 networks have multiple clients....so there is no peering with
any of them in the control-plane sense.  For external NNIs to a different
operator within the *same* L1 network one would invariably use static
routings.  This is irrespective of the actual choice of signalling protocol.

>   2. The addressing issue you've raised is related to UNI 
> which was so far
>      (until recently) not part of the CCAMP work. So I don't 
> see here that you
>      were forced to use IPv4 Addresses.
NH=> It would make more sense to introduce V6 here IMO....the point on V4 is
not to start with a limited address space if there is no reason to.

>   3. About RSVP vs. PNNI I am not religious, why not using 
> SS7? In any case I
>      don't think that the IETF is the right place to discuss 
> on PNNI. Honestly I
>      don't know which one is 'better' but I don't believe 
> that it is always the
>      best protocol that will win at the end. If you have one 
> why do you need yet
>      another one (and in IETF we had already two ;-)?
NH=> There is more operational experience of pnni and in the opinion of our
signalling experts its a better choice than RSVP.

>   4. I don't see your point on running a routing protocol on 
> L1/0 why no just
>      using RSVP-TE signaling and omit OSPF?
NH=> You could do this I guess. 

>   5. About the access to centralized databases and management 
> system I believe a
>      solution could be found once the specific aplication and 
> communications
>      requrements are clear. I don't see GMPLS excluding this at all.
NH=> True.  However, hope you understand why we see the NMS as being *the*
overriding reference.
> 
> As an observation I'd like to say that all your arguments are 
> equally valid
> applicable to any Layer technology and not specific to L1/0. 
NH=> They don't apply to a cnls mode.  But I agree many of the aspects could
apply to a co pkt-sw mode.
<snipped to end>

---

From: "Lazer, Monica A, ALABS" <[email-masked]>
Date: Thu, 6 Mar 2003 18:06:44 -0500

Gert,
I think that one of the main drivers of the different needs when going
from L1 to L2 is the fact L1, in SONET is TDM-based, while L2 can be
packet based and have a different paradigm, while when going from HO to
LO one is within the same paradigm. So, point 1 indicates that one
should consider using the same control plane architecture for the
sublayers within L1, but it does not necessarily support the idea that
the same paradigm is best for both L1 and higher layers.  Regarding the
backbone/regional structure, more than only 2 levels may be needed for
global transport networks.

Regards,

Monica A. Lazer
Network Architecture and Reliability
 
908 234 8462
[email-masked]

-----Original Message-----
From: Gert Grammel [mailto:[email-masked]]
Sent: Thursday, March 06, 2003 3:38 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Ash, Gerald R
(Jerry), ALABS; [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Mark,

I am happy to read that we could find some common understanding. About
your
multi-layer issue you've raised, I suggest to figure out more to which
extend
this is an issue for UNI. Some thoughts on that:

  1. Wideband Crossconnects are able to crossconnect low order circuits
(LO),
     and put them into high order circuits (HO). Those Crossconnects are
managed
     by one manager able to control both Layers: LO and HO. I've never
heard
     that an operator let one part of the organization implement HO only
on a
     country wide basis, while another part of the organization is
taking care
     about LO only.
  2. So rather than the pure layering, a kind of regional/backbone
structure is
     in place. Regional NOCs deal with HO and LO whithin the region
while in
     backbone you use HO only because you don't need the finer
granularity
     there. So what appears to be a layering from a management point of
view
     seems to me more a regional kind of separation.

To be clear: I don't want to discuss the fact that there is a layering
in the
network. My point is to highlight that SDH/SONET is in reality not a
single
layer but has at least 4 of them (RS, MS, LO, HO). In theory we should
find in
the network an RS-manager, an MS-Manager, a LO-Manager and a HO-Manager.
Moreover a single Wideband Crossconnect would have had to be managed by
all 4
managers at the same time. Obviously this is not really practical
(immagine: 4
managers, one worker ;-) such that most vendors and carriers decided to
put all
4 layers into one management box - quite similar to what a GMPLS Control
Plane
does with SONET/SDH control.

Just to avoid misunderstandings here: I don't want to start a new thread
on
layering issues. I just want to provide you some food for your own
thoughts
hoping that we can find some common understanding at some point in
future.

Regards

Gert

[email-masked] wrote:

> Gert,
>
> Thanks for outlining the history and your current position for going
> forward.  Mostly, I agree with you.
>
> My major point of disagreement is with your characterization of the
> ITU-T direction.  Though the ITU-T ASON documents might enable
> "'Bandwidth on Demand' services (BOND)" to some degree, that was not
the
> primary focus.  The Optical UNI was a development that came out of the
> OIF and not the ITU-T.  Most carriers have seen the Optical UNI as a
> potential customer interface with far more realistic applications
> internal to networks, i.e. between the L3/L2 elements and the L1/L0
> elements.  Those who have attended the OIF in the past probably
remember
> my unpopular statement on the plenary floor that we were wasting out
> time working on a UNI that had questionable (no?) business advantages
> for the carrier.
>
> I do support the approach you mention (from Kireeti?) that we focus on
> the service points and the information that needs to be exchanged
> between them.  Where most of the services are of the L3/L2 variety,
that
> approach should be successful.  Those items should be fully covered by
> the IETF solutions.
>
> However, that doesn't address the multi-layer issue that we are
> struggling to address, which is one of the root causes of this
conflict
> between the IETF and ITU-T.  The signaling/control for L1/L0 is where
> the ITU-T participants have found the IETF solutions to be inadequate.
> That's not necessarily because the IETF solutions wouldn't work, but
> because they would not satisfy the stringent requirements and models
by
> which we base our management and control for L1/L0.
>
> This whole problem could be blamed on the IP success in the industry.
> If IP had not proven to be so successful, the ITU-T might have chosen
> the optical control plane based on extensions to SS7.  :-)  (Not
meaning
> to ignore the ITU-T alternative solution based on PNNI.)
>
> Regards,
>
> Mark Loyd Jones
> Sent: Thursday, March 06, 2003 1:21 PM
> To: Mark.Jones
> Cc: ccamp; dwfedyk; gash; mpls
> So the match is tied up 1:1 but maybe it's now the right time to find
a
> solution
> on how to proceed. What I've seen so far was a complete misperception
of
> what is
>      summarized as 'Bandwidth on Demand' services (BOND). Naturally
this
> led to
> So putting everything together means that it is required to keep
(IETF)
> protocol
> consistency but adding some (ITU-T) specific extensions to well
defined
> service
> this would mean that an intermediate protocol would have had to
support
> such
> kind of communication. What concerns the IETF community is probably
not
> the fact
> there was: please authors try to let us understand what problem you
want
> to
> solve and tell us which kind of information you have to exchange
between
> which
> management
attributes
> > > an overlay model. The expertise for these layer is not all
contained