From owner-mpls@UU.NET  Sat Mar  1 08:15:51 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04310
	for <mpls-archive@lists.ietf.org>; Sat, 1 Mar 2003 08:15:51 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoedh08979
	for <mpls-archive@lists.ietf.org>; Sat, 1 Mar 2003 13:17:48 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoedh07939;
	Sat, 1 Mar 2003 13:17:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoedh20487
	for mpls-outgoing; Sat, 1 Mar 2003 13:17:06 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoedh20482
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 1 Mar 2003 13:16:56 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoedh03764
	for <mpls@UU.NET>; Sat, 1 Mar 2003 13:16:46 GMT
From: neil.2.harrison@bt.com
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoedh00391
	for <mpls@UU.NET>; Sat, 1 Mar 2003 13:16:46 GMT
Received: from cbibipnt08.hc.bt.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: saturn.bt.com [193.113.57.20])
	id QQoedh00383
	for <mpls@UU.NET>; Sat, 1 Mar 2003 13:16:45 GMT
Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89)
	id <FWV530XV>; Sat, 1 Mar 2003 13:16:57 -0000
Message-ID: <0536FC9B908BEC4597EE721BE6A35389014D0034@i2km07-ukbr.domain1.systemhost.net>
To: erosen@cisco.com, evarma@lucent.com
Cc: curtis@fictitious.org, gnewsome@ieee.org, sjtrowbridge@lucent.com,
        loa@pi.se, mpls@UU.NET
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
Date: Sat, 1 Mar 2003 13:16:41 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Although the BT view is to ignore this stuff I feel some operator
observations are in order at this point.  So please see below.  regards,
Neil

Eric Rosen wrote 28 February 2003 20:54
> 
> 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. 

'Connection-oriented religion'?  I fail to understand how anyone could make
such a remark when IETF are working on SDH and OTNs....which are about as
connection-oriented as you can get!  MPLS also uses connection-oriented
*fowarding mode*.....this is obvious from using link-connection identifiers
which are only link-unique.  I know many pretend its not like this.....but
really, do you think we operators are all so very stupid?

Here are a few of our requirements for networks....you can take take them or
leave them:

1	Operators need all 3 networks modes, viz:  cnls, co pkt-sw and co
cct-sw.  If anyone honestly thinks we can provide all the services we need,
and run our networks efficiently, without all these modes then they do not
understand the operator business at all.  

2	The technical and commercial drivers/constraints for each of these
modes means that you cannot functionally converge them.......as was the
original intent of the so-called GMPLS 'peer-model'.  This has been our
consistent position from day-1, and it seems this is slowly being understood
by the wider community.  However, whilst I clearly cannot speak for other
operators I can tell you that we have analysed this one to death, and we are
very sure of our requirements here.

3	The principle functions that networks must have to work/scale are:
addressing, routing (however executed), signalling (if co mode), OAM,
performance metrics/objectives, traffic descriptors.  As noted above, there
are compelling (to us at least) technical and commercial reason why
crunching all these functions across all the network modes, and maybe into
some 'god-box' say, is a non-starter.  What we do want however, is
functional convergence of all the technologies *within* each networking
mode.  The reason for this is to avoid stovepipes (ie 'technology=>service')
and/or complex/costly functional gateways, eg to interwork different
signalling types.  And as noted above, we also want a properly specified
common core co pkt-sw mode.  

4	We also want the ability to *choose* best-of-breed functional
components for each networking mode.  This is largely not allowed in G/MPLS
(ie all functions come as a job-lot), and this is not acceptable to us
either.

But all of the above are not a problem providing we have the choice to go
elsewhere for our stds when the solutions provided by IETF don't (or can't,
for whatever reason) match these.

regards, Neil


From owner-mpls@UU.NET  Sat Mar  1 10:40:12 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09016
	for <mpls-archive@lists.ietf.org>; Sat, 1 Mar 2003 10:40:11 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoedq03564
	for <mpls-archive@lists.ietf.org>; Sat, 1 Mar 2003 15:42:07 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoedq02497;
	Sat, 1 Mar 2003 15:41:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoedq07226
	for mpls-outgoing; Sat, 1 Mar 2003 15:41:07 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoedq07068
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 1 Mar 2003 15:40:58 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoedq01563
	for <mpls@UU.NET>; Sat, 1 Mar 2003 15:40:45 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoedq18184
	for <mpls@UU.NET>; Sat, 1 Mar 2003 15:40:44 GMT
Received: from maild.telia.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: maild.telia.com [194.22.190.101])
	id QQoedq18174
	for <mpls@UU.NET>; Sat, 1 Mar 2003 15:40:43 GMT
Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241])
	by maild.telia.com (8.12.5/8.12.5) with ESMTP id h21FeeQT005394;
	Sat, 1 Mar 2003 16:40:40 +0100 (CET)
X-Original-Recipient: mpls@UU.NET
Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45])
	by d1o888.telia.com (8.10.2/8.10.1) with ESMTP id h21Fee215902;
	Sat, 1 Mar 2003 16:40:40 +0100 (CET)
Message-ID: <3E60D367.8070709@pi.se>
Date: Sat, 01 Mar 2003 16:36:07 +0100
From: Loa Andersson <loa@pi.se>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Ong, Lyndon" <LyOng@ciena.com>
CC: mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <2135200C183FD5119588009027DE572302836D71@webdev-owa.oni.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Lyndon,

thanks - it looks like we are making progress - some questions/inline.

Ong, Lyndon wrote:

>Hi Folks,
>
>I support the request to stick to constructive comments.
>
>Of course that means avoiding statements like "The
>ITU has stepped out of bounds (again).  They deserve to be ignored."
>(Last I heard, SDH/OTN networks were within bounds of ITU ;o)
>
>Or "dogmatic statements of connection-oriented  religion" (these
>are, for gmpls, connection-oriented networks we're talking about ;0)
>
>Seriously, though, I do have some comments on the draft:
>
>-- the figure shows the only path outside of the IETF process to
>be a dustbin.  Hopefully that's not intentional, although a lot
>of folks on the list probably believe this ;o)
>
could you specify which path(s)

>
>
>-- there's some text mixed up in 2.2.1 regarding which mailing list
>should be used.
>
specific please - I intended to say the area list of the wg that 
specified the protocol,
can't see the mix up

>
>
>-- we should incorporate Deborah's suggestion for 2.2.2 about having
>the decision posted to the mailing list within a specified period  (the
>posting of a decision could apply to liaisons, and might have helped
>avoid the confusion with the ITU liaison)
>
I clearly sympatize with this, but since all decisions in the change
process are taken by I*, with the exception of the initial of being
where ADs and wg chairs, decides on whether to request chartiering the
req evaluation, are controlled by the I*, I think it is outside scope of
draft to specify how and when. It has been my assumption that this is
within the I* domain

>
>
>-- in 2.2.4, the paragraph after item (2) seems a little premature - 
>the recommendation by the rewg presumably must be approved by IESG/IAB
>before a decision is made.
>
OK, can see this - would this be feasible

   If IESG/IAB approves of a recommendation according to cases 1 & 2 the 
   IETF will not publish an RFC that attempts to get around the decision.

I complicates the flow chart a bit, but will be manageable, I can always
ask Bala to help ;)

>
>
>-- there is a bit of a loophole in that the problem could be accepted
>and farmed off to a WG but there's no check to see if anything is ever
>done, and items could easily fall through a crack given the large 
>numbers of work items usually in CCAMP and MPLS.  There could be a 
>procedure to revisit the decision in case no progress is being made
>within some specified timeframe.
>
no I htink tht this is not a loop hole - there is no way ever where you can
"farm a problem out" and expect the wg to do your job for you,  ti requires
youra active participation, IETF  is a community of co-workers not an
agency that takes assignments - every time you bring something in to the
IETF youd don't say "Here is something YOU should do while I go about 
minding
my own business", instead you should say "Here is something I think WE 
should do".

>
>
>-- in general, I hope people keep in mind that the scope of interest
>and the resources available in IETF are limited, and should not become a
>bottleneck - if work can be or is already being done in other bodies and 
>there is a process for IETF to review this work and identify potential
>problems or simpler/more general ways to do the desired function,
>this should be viewed as a generally positive thing.
>

agreed - that is why all the 4 bullets were insluded, and yes I agree as
long as the architecural issues and the safe guarding of opertional aspects
the Inernet are respected, but on the other hand bringing something to the
IETF and not being prepared to work on it is likely to create a "bottleneck"

>
>
>Cheers,
>
>Lyndon
>
>
>




From owner-mpls@UU.NET  Sat Mar  1 13:18:43 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14257
	for <mpls-archive@lists.ietf.org>; Sat, 1 Mar 2003 13:18:43 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeeb11399
	for <mpls-archive@lists.ietf.org>; Sat, 1 Mar 2003 18:20:39 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeeb10690;
	Sat, 1 Mar 2003 18:20:18 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeeb13758
	for mpls-outgoing; Sat, 1 Mar 2003 18:20:00 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoeeb13753
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 1 Mar 2003 18:19:54 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoeeb27279
	for <mpls@UU.NET>; Sat, 1 Mar 2003 18:19:35 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeeb17925
	for <mpls@UU.NET>; Sat, 1 Mar 2003 18:19:35 GMT
Received: from bt0g2p.god.bel.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alc136.alcatel.be [195.207.101.136])
	id QQoeeb17910
	for <mpls@UU.NET>; Sat, 1 Mar 2003 18:19:34 GMT
Received: from bemail05.net.alcatel.be (relay3 [127.0.0.1])
	by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id h21IJUN08867
	for <mpls@UU.NET>; Sat, 1 Mar 2003 19:19:34 +0100
Received: from alcatel.be ([138.203.137.2])
          by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11)
          with ESMTP id 2003030119192813:1263 ;
          Sat, 1 Mar 2003 19:19:28 +0100 
Message-ID: <3E60F972.298A80A5@alcatel.be>
Date: Sat, 01 Mar 2003 19:18:26 +0100
From: Dimitri.Papadimitriou@alcatel.be
Organization: optical network architecture (nta - antwerpen)
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Loa Andersson <loa@pi.se>
Cc: "Ong, Lyndon" <LyOng@ciena.com>, mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <2135200C183FD5119588009027DE572302836D71@webdev-owa.oni.com> <3E60D367.8070709@pi.se>
X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 03/01/2003 19:19:28,
	Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 03/01/2003 19:19:33,
	Serialize complete at 03/01/2003 19:19:33
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

all,

some additional comments and input:

1) on 2.2.1. Initiating changes or extensions to
(G)MPLS protocols

imho it would be helpful that the requesting i-d 
provides a clear demarcation about the complexity
handling (in a sense this will help in evaluating
in case of interesting topic is this can be handled
in a timely manner) and would also avoid over-
engineering (gmpls doesn't mean "universal" mpls) 

2) what about the use of the summay I-d as proposed
two years ago see also:

ftp://subip.ietf.org/pub/lists/2001/idsummary.0105

i think that a re-use of this template may help in
the global process (in particular if this might be
used as first section of such a document, it may 
also happen that the topic may cross several working 
groups or even areas, wouldn't be thus useful to 
have an overview of the impact(ed) protocol wrt 
(g)mpls and related

3) this step should also include a clear evaluation 
of the impact on the global internet architecture -
and founder principles

imho the security issues (see 2.2.1) should be part 
of this (this would imho help in having responsible
ietf'ers and avoid the i-d dropping syndrom)

4) on 2.2.4 Point 1 might be useful for the requestor
to have a bit more insight here (not more than just
using a list of references)

5) when it is said 2.2.4 Point 2 "not a general 
enough one" what this "general" word means is it
in the "common" ccamp sense (so "generalized") or
is it in the sense "not widely used" for instance
or even both for instance using the above termino
"mp2mp" is a general problem not widely used (as
per today)

thanks,
- dimitri.

---

Loa Andersson wrote:
> 
> Lyndon,
> 
> thanks - it looks like we are making progress - some questions/inline.
> 
> Ong, Lyndon wrote:
> 
> >Hi Folks,
> >
> >I support the request to stick to constructive comments.
> >
> >Of course that means avoiding statements like "The
> >ITU has stepped out of bounds (again).  They deserve to be ignored."
> >(Last I heard, SDH/OTN networks were within bounds of ITU ;o)
> >
> >Or "dogmatic statements of connection-oriented  religion" (these
> >are, for gmpls, connection-oriented networks we're talking about ;0)
> >
> >Seriously, though, I do have some comments on the draft:
> >
> >-- the figure shows the only path outside of the IETF process to
> >be a dustbin.  Hopefully that's not intentional, although a lot
> >of folks on the list probably believe this ;o)
> >
> could you specify which path(s)
> 
> >
> >
> >-- there's some text mixed up in 2.2.1 regarding which mailing list
> >should be used.
> >
> specific please - I intended to say the area list of the wg that
> specified the protocol,
> can't see the mix up
> 
> >
> >
> >-- we should incorporate Deborah's suggestion for 2.2.2 about having
> >the decision posted to the mailing list within a specified period  (the
> >posting of a decision could apply to liaisons, and might have helped
> >avoid the confusion with the ITU liaison)
> >
> I clearly sympatize with this, but since all decisions in the change
> process are taken by I*, with the exception of the initial of being
> where ADs and wg chairs, decides on whether to request chartiering the
> req evaluation, are controlled by the I*, I think it is outside scope of
> draft to specify how and when. It has been my assumption that this is
> within the I* domain
> 
> >
> >
> >-- in 2.2.4, the paragraph after item (2) seems a little premature -
> >the recommendation by the rewg presumably must be approved by IESG/IAB
> >before a decision is made.
> >
> OK, can see this - would this be feasible
> 
>    If IESG/IAB approves of a recommendation according to cases 1 & 2 the
>    IETF will not publish an RFC that attempts to get around the decision.
> 
> I complicates the flow chart a bit, but will be manageable, I can always
> ask Bala to help ;)
> 
> >
> >
> >-- there is a bit of a loophole in that the problem could be accepted
> >and farmed off to a WG but there's no check to see if anything is ever
> >done, and items could easily fall through a crack given the large
> >numbers of work items usually in CCAMP and MPLS.  There could be a
> >procedure to revisit the decision in case no progress is being made
> >within some specified timeframe.
> >
> no I htink tht this is not a loop hole - there is no way ever where you can
> "farm a problem out" and expect the wg to do your job for you,  ti requires
> youra active participation, IETF  is a community of co-workers not an
> agency that takes assignments - every time you bring something in to the
> IETF youd don't say "Here is something YOU should do while I go about
> minding
> my own business", instead you should say "Here is something I think WE
> should do".
> 
> >
> >
> >-- in general, I hope people keep in mind that the scope of interest
> >and the resources available in IETF are limited, and should not become a
> >bottleneck - if work can be or is already being done in other bodies and
> >there is a process for IETF to review this work and identify potential
> >problems or simpler/more general ways to do the desired function,
> >this should be viewed as a generally positive thing.
> >
> 
> agreed - that is why all the 4 bullets were insluded, and yes I agree as
> long as the architecural issues and the safe guarding of opertional aspects
> the Inernet are respected, but on the other hand bringing something to the
> IETF and not being prepared to work on it is likely to create a "bottleneck"
> 
> >
> >
> >Cheers,
> >
> >Lyndon
> >
> >
> >

-- 
Papadimitriou Dimitri 
E-mail : dimitri.papadimitriou@alcatel.be 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491


From owner-mpls@UU.NET  Sat Mar  1 15:54:15 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17351
	for <mpls-archive@lists.ietf.org>; Sat, 1 Mar 2003 15:54:15 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeel00505
	for <mpls-archive@lists.ietf.org>; Sat, 1 Mar 2003 20:56:11 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeel29965;
	Sat, 1 Mar 2003 20:55:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeel01651
	for mpls-outgoing; Sat, 1 Mar 2003 20:55:41 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoeel01637
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 1 Mar 2003 20:55:36 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoeel28670
	for <mpls@UU.NET>; Sat, 1 Mar 2003 20:54:52 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeel18696
	for <mpls@UU.NET>; Sat, 1 Mar 2003 20:54:52 GMT
Received: from maild.telia.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: maild.telia.com [194.22.190.101])
	id QQoeel18686
	for <mpls@UU.NET>; Sat, 1 Mar 2003 20:54:51 GMT
Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241])
	by maild.telia.com (8.12.5/8.12.5) with ESMTP id h21KsMQT011847;
	Sat, 1 Mar 2003 21:54:22 +0100 (CET)
X-Original-Recipient: mpls@UU.NET
Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45])
	by d1o888.telia.com (8.10.2/8.10.1) with ESMTP id h21KsL229662;
	Sat, 1 Mar 2003 21:54:21 +0100 (CET)
Message-ID: <3E611CF0.7020307@pi.se>
Date: Sat, 01 Mar 2003 21:49:52 +0100
From: Loa Andersson <loa@pi.se>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: neil.2.harrison@bt.com
CC: erosen@cisco.com, evarma@lucent.com, curtis@fictitious.org,
        gnewsome@ieee.org, sjtrowbridge@lucent.com, mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <0536FC9B908BEC4597EE721BE6A35389014D0034@i2km07-ukbr.domain1.systemhost.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

All,

this begs a couple of interersting questions - like if pwe3 are make
IP behaving like ATM - but this is not what we are discussing here, if
you need to "preach" please do so under a separate subject line

/Loa

neil.2.harrison@bt.com wrote:

>Although the BT view is to ignore this stuff I feel some operator
>observations are in order at this point.  So please see below.  regards,
>Neil
>
>Eric Rosen wrote 28 February 2003 20:54
>  
>
>>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. 
>>    
>>
>
>'Connection-oriented religion'?  I fail to understand how anyone could make
>such a remark when IETF are working on SDH and OTNs....which are about as
>connection-oriented as you can get!  MPLS also uses connection-oriented
>*fowarding mode*.....this is obvious from using link-connection identifiers
>which are only link-unique.  I know many pretend its not like this.....but
>really, do you think we operators are all so very stupid?
>
>Here are a few of our requirements for networks....you can take take them or
>leave them:
>
>1	Operators need all 3 networks modes, viz:  cnls, co pkt-sw and co
>cct-sw.  If anyone honestly thinks we can provide all the services we need,
>and run our networks efficiently, without all these modes then they do not
>understand the operator business at all.  
>
>2	The technical and commercial drivers/constraints for each of these
>modes means that you cannot functionally converge them.......as was the
>original intent of the so-called GMPLS 'peer-model'.  This has been our
>consistent position from day-1, and it seems this is slowly being understood
>by the wider community.  However, whilst I clearly cannot speak for other
>operators I can tell you that we have analysed this one to death, and we are
>very sure of our requirements here.
>
>3	The principle functions that networks must have to work/scale are:
>addressing, routing (however executed), signalling (if co mode), OAM,
>performance metrics/objectives, traffic descriptors.  As noted above, there
>are compelling (to us at least) technical and commercial reason why
>crunching all these functions across all the network modes, and maybe into
>some 'god-box' say, is a non-starter.  What we do want however, is
>functional convergence of all the technologies *within* each networking
>mode.  The reason for this is to avoid stovepipes (ie 'technology=>service')
>and/or complex/costly functional gateways, eg to interwork different
>signalling types.  And as noted above, we also want a properly specified
>common core co pkt-sw mode.  
>
>4	We also want the ability to *choose* best-of-breed functional
>components for each networking mode.  This is largely not allowed in G/MPLS
>(ie all functions come as a job-lot), and this is not acceptable to us
>either.
>
>But all of the above are not a problem providing we have the choice to go
>elsewhere for our stds when the solutions provided by IETF don't (or can't,
>for whatever reason) match these.
>
>regards, Neil
>
>
>  
>




From owner-mpls@UU.NET  Sat Mar  1 21:01:55 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22544
	for <mpls-archive@lists.ietf.org>; Sat, 1 Mar 2003 21:01:55 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoefg06777
	for <mpls-archive@lists.ietf.org>; Sun, 2 Mar 2003 02:03:46 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoefg06490;
	Sun, 2 Mar 2003 02:03:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoefg11323
	for mpls-outgoing; Sun, 2 Mar 2003 02:03:01 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoefg09397
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 2 Mar 2003 02:02:45 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoeff25583
	for <mpls@uu.net>; Sun, 2 Mar 2003 01:59:20 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeff04772
	for <mpls@uu.net>; Sun, 2 Mar 2003 01:59:20 GMT
Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQoeff04747
	for <mpls@uu.net>; Sun, 2 Mar 2003 01:59:19 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h221xBS13041;
	Sat, 1 Mar 2003 17:59:11 -0800 (PST)
	(envelope-from kireeti@juniper.net)
Received: from localhost (kireeti@localhost)
	by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h221xAY43658;
	Sat, 1 Mar 2003 17:59:11 -0800 (PST)
	(envelope-from kireeti@juniper.net)
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
Date: Sat, 1 Mar 2003 17:59:10 -0800 (PST)
From: Kireeti Kompella <kireeti@juniper.net>
To: ccamp@ops.ietf.org, "" <mpls@UU.NET>, "" <nsis@ietf.org>,
        "" <tsvwg@ietf.org>, "" <rsvp@isi.edu>
Subject: RSVP change document
Message-ID: <20030301174430.O43585@kummer.juniper.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi All,

The current venue for discussing draft-kompella-rsvp-change-00.txt
(IANA Considerations and change process for RSVP) will be in the
TSVWG (Thu 13:00-15:00 -- if not, I hope either the TSV ADs will
correct me.

For now, let's limit the discussion to the tsvwg mailing list.

Kireeti.


From owner-mpls@UU.NET  Sat Mar  1 21:08:54 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22881
	for <mpls-archive@lists.ietf.org>; Sat, 1 Mar 2003 21:08:54 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoefg20675
	for <mpls-archive@lists.ietf.org>; Sun, 2 Mar 2003 02:10:54 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoefg12226;
	Sun, 2 Mar 2003 02:06:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoefg12699
	for mpls-outgoing; Sun, 2 Mar 2003 02:05:19 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoefg12658
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 2 Mar 2003 02:05:10 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoefg06869
	for <mpls@uu.net>; Sun, 2 Mar 2003 02:04:57 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoefg15474
	for <mpls@uu.net>; Sun, 2 Mar 2003 02:04:54 GMT
Received: from newdev.harvard.edu by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: newdev.eecs.harvard.edu [140.247.60.212])
	id QQoefg15420
	for <mpls@uu.net>; Sun, 2 Mar 2003 02:04:51 GMT
Received: (from sob@localhost)
	by newdev.harvard.edu (8.12.6/8.12.2) id h2224RSe010090;
	Sat, 1 Mar 2003 21:04:27 -0500 (EST)
Date: Sat, 1 Mar 2003 21:04:27 -0500 (EST)
From: Scott  Bradner <sob@harvard.edu>
Message-Id: <200303020204.h2224RSe010090@newdev.harvard.edu>
To: ccamp@ops.ietf.org, kireeti@juniper.net, mpls@UU.NET, nsis@ietf.org,
        rsvp@ISI.EDU, tsvwg@ietf.org
Subject: Re: [Rsvp] RSVP change document
Cc: Jon.peterson@neustar.com, mankin@psg.com
In-Reply-To: <20030301174430.O43585@kummer.juniper.net>
Sender: owner-mpls@UU.NET
Precedence: bulk

the tsvwg list will be the main venue 

I will talk with Allison to see if there is time in teh tsvwg meeting
to start the dicussion

Scott


---

From rsvp-admin@mailman.isi.edu  Sat Mar  1 21:00:42 2003
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
From: Kireeti Kompella <kireeti@juniper.net>
To: ccamp@ops.ietf.org, "" <mpls@uu.net>, "" <nsis@ietf.org>,
   "" <tsvwg@ietf.org>, "" <rsvp@ISI.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [Rsvp] RSVP change document
Sender: rsvp-admin@mailman.isi.edu
Errors-To: rsvp-admin@mailman.isi.edu
X-BeenThere: rsvp@mailman.isi.edu
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:rsvp-request@mailman.isi.edu?subject=help>
List-Archive: <http://mailman.isi.edu/pipermail/rsvp/>
Date: Sat, 1 Mar 2003 17:59:10 -0800 (PST)

Hi All,

The current venue for discussing draft-kompella-rsvp-change-00.txt
(IANA Considerations and change process for RSVP) will be in the
TSVWG (Thu 13:00-15:00 -- if not, I hope either the TSV ADs will
correct me.

For now, let's limit the discussion to the tsvwg mailing list.

Kireeti.
_______________________________________________
Rsvp mailing list
Rsvp@mailman.isi.edu
http://mailman.isi.edu/mailman/listinfo/rsvp



From owner-mpls@UU.NET  Sun Mar  2 09:55:25 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11756
	for <mpls-archive@lists.ietf.org>; Sun, 2 Mar 2003 09:55:24 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoehf29147
	for <mpls-archive@lists.ietf.org>; Sun, 2 Mar 2003 14:57:21 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoehf28237;
	Sun, 2 Mar 2003 14:56:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoehf18976
	for mpls-outgoing; Sun, 2 Mar 2003 14:56:28 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoehf18970
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 2 Mar 2003 14:56:22 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoehf09745
	for <mpls@UU.NET>; Sun, 2 Mar 2003 14:55:29 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoehf21863
	for <mpls@UU.NET>; Sun, 2 Mar 2003 14:55:28 GMT
Received: from relay2.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alc239.alcatel.be [195.207.101.239])
	id QQoehf21845
	for <mpls@UU.NET>; Sun, 2 Mar 2003 14:55:27 GMT
Received: from bemail05.net.alcatel.be (localhost [127.0.0.1])
	by relay2.alcatel.be (8.10.1/8.11.4) with ESMTP id h22Et3E21776;
	Sun, 2 Mar 2003 15:55:07 +0100 (MET)
Received: from alcatel.be ([138.203.137.2])
          by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11)
          with ESMTP id 2003030215550139:1718 ;
          Sun, 2 Mar 2003 15:55:01 +0100 
Message-ID: <3E621AFD.8D2B5DB3@alcatel.be>
Date: Sun, 02 Mar 2003 15:53:49 +0100
From: Dimitri.Papadimitriou@alcatel.be
Organization: optical network architecture (nta - antwerpen)
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: velev@panasonic.de
Cc: Heiles Juergen <juergen.heiles@siemens.com>, mpls@UU.NET,
        ccamp@ops.ietf.org
Subject: Re: draft-kawakami-mpls-lsp-vlan-00.txt
References: <NGBBJEAONDNLBFPCDEPPMEACCGAA.velev@panasonic.de> <3E5FC411.FAF850FF@alcatel.be>
X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 03/02/2003 15:55:01,
	Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 03/02/2003 15:55:07
Content-Type: text/plain; charset=iso-8859-1
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id JAA11756

all,

would like to add something here in the context
of this i-d, the following RFC

http://www.ietf.org/rfc/rfc3468.txt

aka "The Multiprotocol Label Switching (MPLS) Working 
Group decision on MPLS signaling protocols" clearly
states that "the MPLS working group consensus to not
undertake any new work related to RFC 3212 [RFC3212],"
(aka "CR-LDP"), see also Section 6 of this RFC 3468

thus i am bit surprised this i-d proposes the use
of cr-ldp, for instance:

"  Control plane: 
   The VLAN-LSP setting and management is done in the control plane by 
   the control component of VLAN-LSR. The VLAN-LSP setting can be 
   achieved in two ways: explicit path for traffic engineering, (using 
   Constraint-based Routing LDP, CR-LDP) [...]"

or

"  The edge VLAN-LSR uses CR-LDP signalling protocol to send Label 
   Request Message to the VLAN-LSR having the next IP address in the 
   Explicit Route TLV (ER-TLV)."

would it possible to "review" this i-d wrt to the wg
consensus otherwise i don't see how this i-d can gain
the consensus of the above mentioned working group ?

thanks,
- dimitri.

Dimitri.Papadimitriou@alcatel.be wrote:
> 
> hi,
> 
> per gmpls, Layer-2 Switch Capable (L2SC) interfaces are
> defined:
> 
>    Interfaces that recognize frame/cell boundaries and can forward data
>    based on the content of the frame/cell header. Examples include
>    interfaces on Ethernet bridges that forward data based on the
>    content of the MAC header and interfaces on ATM-LSRs that forward
>    data based on the ATM VPI/VCI.
> 
> i agree with juergen, this i-d should be discussed at
> the ccamp working group
> 
> thanks,
> - dimitri.
> 
> Genadi Velev wrote:
> >
> > Hi Juergen,
> >
> > thanks for the feedback! This was (and seems to be still) a hot topic. The
> > decision where to present the draft has been already a subject of
> > discussions with the chairmen of MPLS, PWE3 and PPVPN WGs. The reason to let
> > this draft for submission in the MPLS WG was that the basic intention is to
> > propose a new LDP extension ("VLAN label TLV") and MPLS WG is in charge of
> > the LDP protocol.
> >
> > It's true that the transport plane in our proposal is based on VLAN-aware
> > Ethernet switches. Compared to the GMPLS classification of interfaces
> > (RFC3471), VLAN tag switching belongs (I'd say so) to the Packet-Switch
> > Capable (PSC) interfaces, and thus, extensions regarding these interfaces
> > should be a subject of the MPLS WG.
> >
> > This is my personal opinion. However, since I'm not a long-experienced
> > person in the IETF's MPLS related work, I'd like to hear also another
> > opinions on this issue.
> >
> > regards,
> > Genadi
> >
> > > -----Original Message-----
> > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Heiles
> > > Juergen
> > > Sent: Friday, February 28, 2003 12:17 PM
> > > To: 'velev@panasonic.de'; mpls@UU.NET; ccamp@ops.ietf.org
> > > Cc: vlan-mpls@panasonic.de
> > > Subject: AW: draft-kawakami-mpls-lsp-vlan-00.txt
> > >
> > >
> > > Genadi,
> > >
> > > the draft proposes to use the MPLS control plane protocols for a
> > > different transport plane (Ethernet VLAN).
> > > This is excatly what GMPLS is about. So I think it would be
> > > better to have the ID and dicussion in ccamp under the GMPLS work.
> > >
> > > Regards
> > >
> > > Juergen
> > >
> > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Genadi Velev [mailto:velev@panasonic.de]
> > > > Gesendet: Donnerstag, 27. Februar 2003 17:53
> > > > An: mpls@UU.NET
> > > > Cc: vlan-mpls@panasonic.de
> > > > Betreff: draft-kawakami-mpls-lsp-vlan-00.txt
> > > >
> > > >
> > > > [ Mail was delivered through VPN PEL->MEI/AVCDC! ]
> > > > [ Mail was delivered through VPN PEL->MEI/AVCDC! ]
> > > > [ Mail was delivered through VPN PEL->MEI/AVCDC! ]
> > > > [ Mail was delivered through VPN PEL->MEI/AVCDC! ]
> > > >
> > > > Hi all,
> > > >
> > > > A new draft was published today (please see below).
> > > >
> > > > Any feedback and comments are welcome, especially from those
> > > > of you who are
> > > > dealing with packet transport over wide area Ethernet networks.
> > > >
> > > > thanks,
> > > > Genadi
> > > >
> > > > > -----Original Message-----
> > > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
> > > > > Internet-Drafts@ietf.org
> > > > > Sent: Thursday, February 27, 2003 1:44 PM
> > > > > To: IETF-Announce:
> > > > > Cc: mpls@UU.NET
> > > > > Subject: I-D ACTION:draft-kawakami-mpls-lsp-vlan-00.txt
> > > > >
> > > > >
> > > > > A New Internet-Draft is available from the on-line
> > > > > Internet-Drafts directories.
> > > > >
> > > > >
> > > > >   Title           : Method to Setup LSP using VLAN Tag Switching
> > > > >   Author(s)       : T. Kawakami et al.
> > > > >   Filename        : draft-kawakami-mpls-lsp-vlan-00.txt
> > > > >   Pages           : 15
> > > > >   Date            : 2003-2-26
> > > > >
> > > > > This document describes a method to setup a Layer 2 tunnel over
> > > > > networks based on Ethernet technology. For this purpose,
> > > > the ports of
> > > > > an Ethernet switch are configured to forward VLAN
> > > > tag-labeled packets
> > > > > incoming from a certain port to another unambiguous port by using
> > > > > VLAN tag information. The Ethernet switches themselves are a part of
> > > > > the Label Switching Routers (LSRs), which distribute the VLAN tags
> > > > > using Label Distribution Protocol (LDP). To enable LDP to
> > > > fulfil this
> > > > > function, an LDP extension is proposed. The introduced method
> > > > > simplifies the transport of Ethernet frames over wide area Ethernet
> > > > > networks.
> > > > >
> > > > > A URL for this Internet-Draft is:
> > > > >
> > > http://www.ietf.org/internet-drafts/draft-kawakami-mpls-lsp-vlan-00.txt
> > > >
> > > > To remove yourself from the IETF Announcement list, send a message to
> > > > ietf-announce-request with the word unsubscribe in the body of
> > > > the message.
> > > >
> > > > Internet-Drafts are also available by anonymous FTP. Login with
> > > > the username
> > > > "anonymous" and a password of your e-mail address. After logging in,
> > > > type "cd internet-drafts" and then
> > > >     "get draft-kawakami-mpls-lsp-vlan-00.txt".
> > > >
> > > > A list of Internet-Drafts directories can be found in
> > > > http://www.ietf.org/shadow.html
> > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > >
> > > >
> > > > Internet-Drafts can also be obtained by e-mail.
> > > >
> > > > Send a message to:
> > > >     mailserv@ietf.org.
> > > > In the body type:
> > > >     "FILE /internet-drafts/draft-kawakami-mpls-lsp-vlan-00.txt".
> > > >
> > > > NOTE:       The mail server at ietf.org can return the document in
> > > >     MIME-encoded form by using the "mpack" utility.  To use this
> > > >     feature, insert the command "ENCODING mime" before the "FILE"
> > > >     command.  To decode the response(s), you will need "munpack" or
> > > >     a MIME-compliant mail reader.  Different MIME-compliant mail readers
> > > >     exhibit different behavior, especially when dealing with
> > > >     "multipart" MIME messages (i.e. documents which have been split
> > > >     up into multiple messages), so check your local documentation on
> > > >     how to manipulate these messages.
> > > >
> > > >
> > > > Below is the data which will enable a MIME compliant mail reader
> > > > implementation to automatically retrieve the ASCII version of the
> > > > Internet-Draft.
> > > >
> 
> --
> Papadimitriou Dimitri
> E-mail : dimitri.papadimitriou@alcatel.be
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : dpapadimitriou@psg.com
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : +32 3 240-8491

-- 
Papadimitriou Dimitri 
E-mail : dimitri.papadimitriou@alcatel.be 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491


From owner-mpls@UU.NET  Sun Mar  2 12:16:51 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14682
	for <mpls-archive@lists.ietf.org>; Sun, 2 Mar 2003 12:16:51 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoehp00749
	for <mpls-archive@lists.ietf.org>; Sun, 2 Mar 2003 17:18:48 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoehp00345;
	Sun, 2 Mar 2003 17:18:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoehp24433
	for mpls-outgoing; Sun, 2 Mar 2003 17:18:12 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoehp24427
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 2 Mar 2003 17:18:01 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoehp24561
	for <mpls@UU.NET>; Sun, 2 Mar 2003 17:16:35 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoehp22774
	for <mpls@UU.NET>; Sun, 2 Mar 2003 17:16:34 GMT
Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQoehp22770
	for <mpls@UU.NET>; Sun, 2 Mar 2003 17:16:33 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h22HGUS39170;
	Sun, 2 Mar 2003 09:16:31 -0800 (PST)
	(envelope-from kireeti@juniper.net)
Received: from localhost (kireeti@localhost)
	by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h22HGTJ45826;
	Sun, 2 Mar 2003 09:16:29 -0800 (PST)
	(envelope-from kireeti@juniper.net)
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
Date: Sun, 2 Mar 2003 09:16:29 -0800 (PST)
From: Kireeti Kompella <kireeti@juniper.net>
To: Dimitri.Papadimitriou@alcatel.be
cc: velev@panasonic.de, Heiles Juergen <juergen.heiles@siemens.com>,
        "" <mpls@UU.NET>, "" <ccamp@ops.ietf.org>
Subject: Re: draft-kawakami-mpls-lsp-vlan-00.txt
In-Reply-To: <3E621AFD.8D2B5DB3@alcatel.be>
Message-ID: <20030302091036.J45816@kummer.juniper.net>
References: <NGBBJEAONDNLBFPCDEPPMEACCGAA.velev@panasonic.de>
 <3E5FC411.FAF850FF@alcatel.be> <3E621AFD.8D2B5DB3@alcatel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi All,

One high-level comment, and one addressing the issue that Dimitri
raised;

The CCAMP WG deals (mostly) with protocol extensions that are *common*
across a variety of technologies, such as GMPLS signaling and routing,
and LMP.  There are cases of doing specific technology work, such as
SDH, only because there is no WG for that work.  The WG chairs would
have to consult with their ADs to figure out the right home for this
work that seems to me to be specific.

> thus i am bit surprised this i-d proposes the use
> of cr-ldp, for instance:

Any i-d can propose anything :-)  If it is to be a WG doc, then
the CR-LDP parts will have to be reviewed.  If it is to be Standards
Track, the CR-LDP parts will have to be removed -- if they stay in,
the doc will at best be put on Info track.

Kireeti.


From owner-mpls@UU.NET  Mon Mar  3 08:57:02 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25798
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 08:57:01 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoekt13723
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 13:59:00 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoekt13259;
	Mon, 3 Mar 2003 13:58:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoekt29836
	for mpls-outgoing; Mon, 3 Mar 2003 13:58:22 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoekt29831
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 13:58:17 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoekt08737
	for <mpls@UU.NET>; Mon, 3 Mar 2003 13:57:57 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoekt12697
	for <mpls@UU.NET>; Mon, 3 Mar 2003 13:57:56 GMT
Received: from mail.pel.panasonic.de by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.pel.panasonic.de [194.162.191.12])
	id QQoekt12690
	for <mpls@UU.NET>; Mon, 3 Mar 2003 13:57:56 GMT
Received: from mcomvelg (vw1.pel.panasonic.de [10.78.238.55])
 by mail.pel.panasonic.de (__________PEL__Mail-Server__________)
 with SMTP id <0HB600J61EQDY0@panasonic.de> for mpls@UU.NET; Mon,
 3 Mar 2003 14:56:38 +0100 (MET)
Date: Mon, 03 Mar 2003 14:56:38 +0100
From: Genadi Velev <velev@panasonic.de>
Subject: RE: draft-kawakami-mpls-lsp-vlan-00.txt
In-reply-to: <20030302091036.J45816@kummer.juniper.net>
To: Kireeti Kompella <kireeti@juniper.net>, Dimitri.Papadimitriou@alcatel.be,
        Heiles Juergen <juergen.heiles@siemens.com>
Cc: mpls@UU.NET, ccamp@ops.ietf.org
Reply-to: velev@panasonic.de
Message-id: <NGBBJEAONDNLBFPCDEPPEEBFCGAA.velev@panasonic.de>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi all,

as I can see, 2 different issues raised regarding this draft. (please see
inline...)

1) proper WG for this draft

> One high-level comment, and one addressing the issue that Dimitri
> raised;
>
> The CCAMP WG deals (mostly) with protocol extensions that are *common*
> across a variety of technologies, such as GMPLS signaling and routing,
> and LMP.  There are cases of doing specific technology work, such as
> SDH, only because there is no WG for that work.  The WG chairs would
> have to consult with their ADs to figure out the right home for this
> work that seems to me to be specific.
>
Kireeti,
thanks for your clarification. You are right that this technology is a
specific one, but OTOH as Dimitri pointed out it fits perfectly to the group
of Layer-2 Switch Capable (L2SC) interfaces.
I would like to ask you and Loa/George to help us to find the proper WG for
the draft!

2) employment of CR-LDP

> > thus i am bit surprised this i-d proposes the use
> > of cr-ldp, for instance:
>
> Any i-d can propose anything :-)  If it is to be a WG doc, then
> the CR-LDP parts will have to be reviewed.  If it is to be Standards
> Track, the CR-LDP parts will have to be removed -- if they stay in,
> the doc will at best be put on Info track.
>
Kireeti and Dimitri,
I didn't know about the existence of MPLS WG's consensus and RFC 3468. Now,
after your valuable comments, I realize that we - the authors of the ID -
should reconsider the employment of CR-LDP. Since 2 protocols are proposed
to setup LSP (LDP and CR-LDP), it would be possible in a future version of
the ID to specify the use of LDP only.

Our initial intention of the ID was, if the ID is accepted as WG doc, that
it can become an informational RFC, not a standard one.

thanks,
Genadi



From owner-mpls@UU.NET  Mon Mar  3 09:22:42 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26573
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 09:22:41 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoekv03147
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 14:24:43 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoekv02810;
	Mon, 3 Mar 2003 14:24:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoekv20211
	for mpls-outgoing; Mon, 3 Mar 2003 14:24:21 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoekv20205
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 14:24:16 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoekv26375
	for <mpls@uu.net>; Mon, 3 Mar 2003 14:23:18 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoekv07795
	for <mpls@uu.net>; Mon, 3 Mar 2003 14:23:17 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoekv07785
	for <mpls@uu.net>; Mon, 3 Mar 2003 14:23:16 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h23ENENh024395
	for <mpls@uu.net>; Mon, 3 Mar 2003 09:23:14 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA03779 for <mpls@uu.net>; Mon, 3 Mar 2003 09:23:14 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h23ENDK21007 for mpls@uu.net; Mon, 3 Mar 2003 09:23:13 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoehx10024
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 2 Mar 2003 19:21:26 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoehx26398
	for <mpls@uu.net>; Sun, 2 Mar 2003 19:21:07 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoehx09853
	for <mpls@uu.net>; Sun, 2 Mar 2003 19:21:06 GMT
Received: from web12804.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web12804.mail.yahoo.com [216.136.174.39])
	id QQoehx09839
	for <mpls@uu.net>; Sun, 2 Mar 2003 19:21:06 GMT
Message-ID: <20030302192105.68081.qmail@web12804.mail.yahoo.com>
Received: from [68.36.136.113] by web12804.mail.yahoo.com via HTTP; Sun, 02 Mar 2003 11:21:05 PST
Date: Sun, 2 Mar 2003 11:21:05 -0800 (PST)
From: Zhi-Wei Lin <zhiweilin@yahoo.com>
Subject: Re: FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
To: mpls@UU.NET
Cc: jdrake@calient.net
In-Reply-To: <61B49BC6DA0DDE40957FB499E1835E3705FA8397@nj7460exch010u.ho.lucent.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1310248298-1046632865=:66086"
Sender: owner-mpls@UU.NET
Precedence: bulk

--0-1310248298-1046632865=:66086
Content-Type: text/plain; charset=us-ascii


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:jdrake@calient.net]
Sent: Friday, February 28, 2003 4:15 PM
To: 'erosen@cisco.com'; Varma, Eve L (Eve)
Cc: 'curtis@fictitious.org'; George Newsome; Stephen Trowbridge; Loa
Andersson; mpls@UU.NET
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:erosen@cisco.com]
> Sent: Friday, February 28, 2003 12:54 PM
> To: Varma, Eve L (Eve)
> Cc: 'curtis@fictitious.org'; George Newsome; Stephen Trowbridge; Loa
> Andersson; mpls@UU.NET
> 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
--0-1310248298-1046632865=:66086
Content-Type: text/html; charset=us-ascii

<P>Hi John,
<P>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?
<P>Thanks<BR>Zhi
<P>&nbsp;
<P>&nbsp;From: John Drake [mailto:jdrake@calient.net]<BR>Sent: Friday, February 28, 2003 4:15 PM<BR>To: 'erosen@cisco.com'; Varma, Eve L (Eve)<BR>Cc: 'curtis@fictitious.org'; George Newsome; Stephen Trowbridge; Loa<BR>Andersson; mpls@UU.NET<BR>Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt <BR><BR><BR>I agree with Eric.<BR><BR>As an example, we have call/connection separation, which has been kicking<BR>around since the early days of ISDN. In discussions as to why it is needed,<BR>the first reason is always "because". Once past that, I have consistently<BR>heard four or five examples cited. What is interesting is that all of them<BR>can be handled with the existing Make Before Break component of RSVP-TE. <BR><BR>Thanks,<BR><BR>John<BR><BR>&gt; -----Original Message-----<BR>&gt; From: Eric Rosen [mailto:erosen@cisco.com]<BR>&gt; Sent: Friday, February 28, 2003 12:54 PM<BR>&gt; To: Varma, Eve L (Eve)<BR>&gt; Cc: 'curtis@fictitious.org'; George Newsome; Stephen !
Tr!
!
!
!
!
!
owbridge; Loa<BR>&gt; Andersson; mpls@UU.NET<BR>&gt; Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt <BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; Eve&gt; For individual contributor drafts coming in, it's quite <BR>&gt; appropriate to<BR>&gt; Eve&gt; evaluate requirements and determine if they are <BR>&gt; legitimate. It's a<BR>&gt; Eve&gt; different case when another SDO, responsible for a <BR>&gt; non-IP applications<BR>&gt; Eve&gt; domain, has established a set of requirements related to <BR>&gt; that domain.<BR>&gt; <BR>&gt; I'd certainly disagree with that. Many of the <BR>&gt; "requirements" I see from<BR>&gt; other organizations are not requirements at all, but <BR>&gt; just dogmatic<BR>&gt; statements of connection-oriented religion. If the IETF <BR>&gt; were to accept<BR>&gt; requirements from other organizations, it would quickly be <BR>&gt; inundated with<BR>&gt; "requirements" to make IP behave exactly like ATM. In <BR>&gt; fact, anyone who<BR>&gt; works in!
 t!
!
!
!
!
!
he PWE3 group can testify that such "requirements" <BR>&gt; come in all the<BR>&gt; time. <BR>&gt; <BR>&gt; <BR>&gt; </P><p><br><hr size=1>Do you Yahoo!?<br>
<a href="http://rd.yahoo.com/finance/mailtagline/*http://taxes.yahoo.com/">Yahoo! Tax Center</a> - forms, calculators, tips, and more
--0-1310248298-1046632865=:66086--



From owner-mpls@UU.NET  Mon Mar  3 09:55:50 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27642
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 09:55:50 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoekx06036
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 14:57:47 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoekx05412;
	Mon, 3 Mar 2003 14:57:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoekx23005
	for mpls-outgoing; Mon, 3 Mar 2003 14:57:02 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoekx23000
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 14:57:00 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoekx29351
	for <mpls@UU.NET>; Mon, 3 Mar 2003 14:56:35 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoekx04228
	for <mpls@UU.NET>; Mon, 3 Mar 2003 14:56:35 GMT
Received: from hoemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail1.lucent.com [192.11.226.161])
	id QQoekx04224
	for <mpls@UU.NET>; Mon, 3 Mar 2003 14:56:35 GMT
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h23EuUf03968;
	Mon, 3 Mar 2003 09:56:30 -0500 (EST)
Received: from lucent.com (sjtrowbridge-1.dr.lucent.com [135.4.20.16]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id IAA12277; Mon, 3 Mar 2003 08:56:28 -0600 (CST)
Message-ID: <3E636D1C.456EC406@lucent.com>
Date: Mon, 03 Mar 2003 07:56:28 -0700
From: Stephen Trowbridge <sjtrowbridge@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5  (Windows NT 5.0; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: George Swallow <swallow@cisco.com>
CC: curtis@fictitious.org, Loa Andersson <loa@pi.se>, mpls@UU.NET,
        ccamp <ccamp@ops.ietf.org>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <200302281703.MAA00661@bifocal.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

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:
> 
> > In message <3E5F8A25.8030201@pi.se>, 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.
> 
> 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 owner-mpls@UU.NET  Mon Mar  3 10:52:18 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00476
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 10:52:17 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelb14497
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 15:54:16 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoelb13712;
	Mon, 3 Mar 2003 15:53:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoelb15648
	for mpls-outgoing; Mon, 3 Mar 2003 15:53:41 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoelb15641
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 15:53:32 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoelb04270
	for <mpls@UU.NET>; Mon, 3 Mar 2003 15:53:09 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelb12703
	for <mpls@UU.NET>; Mon, 3 Mar 2003 15:53:08 GMT
Received: from newdev.harvard.edu by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: newdev.eecs.harvard.edu [140.247.60.212])
	id QQoelb12692
	for <mpls@UU.NET>; Mon, 3 Mar 2003 15:53:08 GMT
Received: (from sob@localhost)
	by newdev.harvard.edu (8.12.6/8.12.2) id h23Fpm7K003460;
	Mon, 3 Mar 2003 10:51:48 -0500 (EST)
Date: Mon, 3 Mar 2003 10:51:48 -0500 (EST)
From: Scott  Bradner <sob@harvard.edu>
Message-Id: <200303031551.h23Fpm7K003460@newdev.harvard.edu>
To: sjtrowbridge@lucent.com, swallow@cisco.com
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Cc: ccamp@ops.ietf.org, curtis@fictitious.org, loa@pi.se, mpls@UU.NET
In-Reply-To: <3E636D1C.456EC406@lucent.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

I think that we (the IETF) do need to work on the "liaison problem"
but I do not think that a perfect liaison process would reduce the
requirement for the IETF to be sure that the extension process for
IETF protocols is clearly documented.

We have been trying to be clear in new protoocls by including 
an IANA Considerations section that says how to extend the technology.  But
many IETF protocols come from a time before we started doing that and
I think it is vital that the process gets defined for those protocols
(one example is RFC 2780, another is RFC 3427)

I expect that we will have to have a quite formal dicussion
on the "liaison problem" and think it needs to be added to the
problems list (and have been told that it will be noted in the
next version of the ID)

Scot


From owner-mpls@UU.NET  Mon Mar  3 11:03:25 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00943
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 11:03:25 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelc03950
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 16:05:25 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoelc03086;
	Mon, 3 Mar 2003 16:05:03 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoelc03990
	for mpls-outgoing; Mon, 3 Mar 2003 16:04:34 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoelc03985
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 16:04:27 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoelc17162
	for <mpls@UU.NET>; Mon, 3 Mar 2003 16:03:08 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelc20875
	for <mpls@UU.NET>; Mon, 3 Mar 2003 16:03:08 GMT
Received: from auemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: auemail1.lucent.com [192.11.223.161])
	id QQoelc20864
	for <mpls@UU.NET>; Mon, 3 Mar 2003 16:03:07 GMT
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h23G35C03719;
	Mon, 3 Mar 2003 11:03:05 -0500 (EST)
Received: from lucent.com (sjtrowbridge-1.dr.lucent.com [135.4.20.16]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id KAA16984; Mon, 3 Mar 2003 10:03:03 -0600 (CST)
Message-ID: <3E637CB6.AD6A52F8@lucent.com>
Date: Mon, 03 Mar 2003 09:03:02 -0700
From: Stephen Trowbridge <sjtrowbridge@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5  (Windows NT 5.0; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: Loa Andersson <loa@pi.se>
CC: mpls@UU.NET, ccamp <ccamp@ops.ietf.org>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <200302281650.LAA43484@workhorse.fictitious.org> <3E5F993C.27CFAB0D@lucent.com> <3E5FDFB7.2070305@pi.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

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 <3E5F8A25.8030201@pi.se>, 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 owner-mpls@UU.NET  Mon Mar  3 11:30:41 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01896
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 11:30:41 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoele09230
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 16:32:37 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoele06673;
	Mon, 3 Mar 2003 16:31:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoele07088
	for mpls-outgoing; Mon, 3 Mar 2003 16:31:03 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoele07005
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 16:30:43 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoele03140
	for <mpls@UU.NET>; Mon, 3 Mar 2003 16:30:34 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoele05669
	for <mpls@UU.NET>; Mon, 3 Mar 2003 16:30:34 GMT
Received: from auemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: auemail1.lucent.com [192.11.223.161])
	id QQoele05665
	for <mpls@UU.NET>; Mon, 3 Mar 2003 16:30:34 GMT
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h23GUVC20236;
	Mon, 3 Mar 2003 11:30:31 -0500 (EST)
Received: from lucent.com (sjtrowbridge-1.dr.lucent.com [135.4.20.16]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id KAA00993; Mon, 3 Mar 2003 10:30:30 -0600 (CST)
Message-ID: <3E638325.D254FF0F@lucent.com>
Date: Mon, 03 Mar 2003 09:30:29 -0700
From: Stephen Trowbridge <sjtrowbridge@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5  (Windows NT 5.0; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: Loa Andersson <loa@pi.se>
CC: curtis@fictitious.org, "Varma, Eve L (Eve)" <evarma@lucent.com>,
        George Newsome <gnewsome@ieee.org>, mpls@UU.NET,
        ccamp <ccamp@ops.ietf.org>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <200302282107.QAA46282@workhorse.fictitious.org> <3E5FE263.9050809@pi.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Loa,
(snip)
> I don't discus liasions, simply because it
> was and is
> my opinion that they are not in the picture then it comes to handling
> changes to the
> (g)mpls protocols.
So, if another SDO thinks that an IETF protocol (possibly with extensions)
would be a good solution to their problem, they would ask for this how?
Regards,
Steve


From owner-mpls@UU.NET  Mon Mar  3 11:36:10 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02082
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 11:36:10 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoele12357
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 16:38:10 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoele10008;
	Mon, 3 Mar 2003 16:36:59 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoele07593
	for mpls-outgoing; Mon, 3 Mar 2003 16:36:43 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoele07588
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 16:36:35 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoele13011
	for <mpls@UU.NET>; Mon, 3 Mar 2003 16:36:21 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoele09372
	for <mpls@UU.NET>; Mon, 3 Mar 2003 16:36:21 GMT
Received: from almso2.proxy.att.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: almso2.att.com [192.128.166.71])
	id QQoele09360
	for <mpls@UU.NET>; Mon, 3 Mar 2003 16:36:20 GMT
Received: from attrh1i.attrh.att.com ([135.71.62.10])
	by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h23F9kZZ022717
	for <mpls@UU.NET>; Mon, 3 Mar 2003 11:36:09 -0500 (EST)
Received: from OCCLUST02EVS1.ugd.att.com (135.71.164.8) by attrh1i.attrh.att.com (6.5.019)
        id 3E61B55100019D9A; Mon, 3 Mar 2003 11:34:52 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Mon, 3 Mar 2003 11:34:51 -0500
Message-ID: <2FEC2C81634CDB4C9F191943ACCDC624079AA622@OCCLUST02EVS1.ugd.att.com>
Thread-Topic: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Thread-Index: AcLhlZJX8hn6F5iIQCat/fvnLfHJhAAAfErA
From: "Brungard, Deborah A, ALABS" <dbrungard@att.com>
To: "Stephen Trowbridge" <sjtrowbridge@lucent.com>,
        "George Swallow" <swallow@cisco.com>
Cc: <curtis@fictitious.org>, "Loa Andersson" <loa@pi.se>, <mpls@UU.NET>,
        "ccamp" <ccamp@ops.ietf.org>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA02082

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:sjtrowbridge@lucent.com]
Sent: Monday, March 03, 2003 9:56 AM
To: George Swallow
Cc: curtis@fictitious.org; Loa Andersson; mpls@UU.NET; 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:
> 
> > In message <3E5F8A25.8030201@pi.se>, 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.
> 
> 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 owner-mpls@UU.NET  Mon Mar  3 11:48:54 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02578
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 11:48:53 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelf29337
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 16:50:48 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoelf26074;
	Mon, 3 Mar 2003 16:49:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoelf08799
	for mpls-outgoing; Mon, 3 Mar 2003 16:49:02 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoelf08794
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 16:48:58 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoelf03160
	for <mpls@UU.NET>; Mon, 3 Mar 2003 16:48:51 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelf16112
	for <mpls@UU.NET>; Mon, 3 Mar 2003 16:48:51 GMT
Received: from hoemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail1.lucent.com [192.11.226.161])
	id QQoelf16103
	for <mpls@UU.NET>; Mon, 3 Mar 2003 16:48:50 GMT
Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35])
	by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h23Gmnf25332
	for <mpls@UU.NET>; Mon, 3 Mar 2003 11:48:49 -0500 (EST)
Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19)
	id <1HW0F563>; Mon, 3 Mar 2003 11:48:48 -0500
Message-ID: <61B49BC6DA0DDE40957FB499E1835E3705FA83B1@nj7460exch010u.ho.lucent.com>
From: "Varma, Eve L (Eve)" <evarma@lucent.com>
To: "'Brungard, Deborah A, ALABS'" <dbrungard@att.com>,
        Stephen Trowbridge
	 <sjtrowbridge@lucent.com>,
        George Swallow <swallow@cisco.com>
Cc: curtis@fictitious.org, Loa Andersson <loa@pi.se>, mpls@UU.NET,
        ccamp
	 <ccamp@ops.ietf.org>
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Mon, 3 Mar 2003 11:48:42 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

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:sjtrowbridge@lucent.com]
Sent: Monday, March 03, 2003 9:56 AM
To: George Swallow
Cc: curtis@fictitious.org; Loa Andersson; mpls@UU.NET; 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:
> 
> > In message <3E5F8A25.8030201@pi.se>, 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.
> 
> 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:dbrungard@att.com]
Sent: Monday, March 03, 2003 11:35 AM
To: Stephen Trowbridge; George Swallow
Cc: curtis@fictitious.org; Loa Andersson; mpls@UU.NET; 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:sjtrowbridge@lucent.com]
Sent: Monday, March 03, 2003 9:56 AM
To: George Swallow
Cc: curtis@fictitious.org; Loa Andersson; mpls@UU.NET; 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:
> 
> > In message <3E5F8A25.8030201@pi.se>, 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.
> 
> 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 owner-mpls@UU.NET  Mon Mar  3 11:52:40 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02726
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 11:52:40 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelf26678
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 16:54:37 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoelf18726;
	Mon, 3 Mar 2003 16:51:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoelf08911
	for mpls-outgoing; Mon, 3 Mar 2003 16:50:42 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoelf08903
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 16:50:29 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoelf00764
	for <mpls@UU.NET>; Mon, 3 Mar 2003 16:50:00 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelf17140
	for <mpls@UU.NET>; Mon, 3 Mar 2003 16:49:59 GMT
Received: from newdev.harvard.edu by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: newdev.eecs.harvard.edu [140.247.60.212])
	id QQoelf17125
	for <mpls@UU.NET>; Mon, 3 Mar 2003 16:49:59 GMT
Received: (from sob@localhost)
	by newdev.harvard.edu (8.12.6/8.12.2) id h23GmwJO003841;
	Mon, 3 Mar 2003 11:48:58 -0500 (EST)
Date: Mon, 3 Mar 2003 11:48:58 -0500 (EST)
From: Scott  Bradner <sob@harvard.edu>
Message-Id: <200303031648.h23GmwJO003841@newdev.harvard.edu>
To: loa@pi.se, sjtrowbridge@lucent.com
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Cc: ccamp@ops.ietf.org, curtis@fictitious.org, evarma@lucent.com,
        gnewsome@ieee.org, mpls@UU.NET
In-Reply-To: <3E638325.D254FF0F@lucent.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Steve,
	Note that Loa is correct as to the impact of liasions, I-Ds
or presentations by folk representing otehr SDOs within the IETF
standards process - they carry just as much weight as the statemnts
of any individual and there is currently no reason to have them
treated as having some special status in the change-process ID.
(see RFC 3356 sec 3.2.2 & RFC 2418 sec 1))  That said, I do think it would be 
good to mention that the use of liasion statements is common in other
SDOs and that such statements should be not ignored when directed to
IETF working groups.

	There are strong arguments that maybe the current assumptions
should change butthis mailing list is not the place to discuss it - I 
would suggest that this dicussion be redirected to the problem-statement 
mailing list.

Scott


From owner-mpls@UU.NET  Mon Mar  3 12:00:27 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03071
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 12:00:27 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelg13886
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 17:02:25 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoelg12312;
	Mon, 3 Mar 2003 17:01:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoelg19582
	for mpls-outgoing; Mon, 3 Mar 2003 17:01:28 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoelg19040
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 17:01:23 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoelg13847
	for <mpls@UU.NET>; Mon, 3 Mar 2003 17:00:05 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelg09891
	for <mpls@UU.NET>; Mon, 3 Mar 2003 17:00:05 GMT
Received: from kcmso2.proxy.att.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: kcmso2.att.com [192.128.134.71])
	id QQoelg09866
	for <mpls@UU.NET>; Mon, 3 Mar 2003 17:00:04 GMT
Received: from attrh1i.attrh.att.com ([135.71.62.10])
	by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h23GsEGH022445
	for <mpls@UU.NET>; Mon, 3 Mar 2003 11:00:02 -0600 (CST)
Received: from OCCLUST02EVS1.ugd.att.com (135.71.164.8) by attrh1i.attrh.att.com (6.5.019)
        id 3E61B5510001A886; Mon, 3 Mar 2003 11:59:54 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: liaisons
Date: Mon, 3 Mar 2003 11:59:54 -0500
Message-ID: <2FEC2C81634CDB4C9F191943ACCDC624079AA623@OCCLUST02EVS1.ugd.att.com>
Thread-Topic: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Thread-Index: AcLhopgLCbbet/t0SjuTuKGyZpqOoQAAAQZA
From: "Brungard, Deborah A, ALABS" <dbrungard@att.com>
To: "Stephen Trowbridge" <sjtrowbridge@lucent.com>,
        "Loa Andersson" <loa@pi.se>
Cc: <curtis@fictitious.org>, "Varma, Eve L (Eve)" <evarma@lucent.com>,
        "George Newsome" <gnewsome@ieee.org>, <mpls@UU.NET>,
        "ccamp" <ccamp@ops.ietf.org>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA03071

I changed the email thread as Loa, Scott, etc have clarified this draft was not intended as a liaison process. (and again, before I can finish typing, I see Scott has sent an email requesting the use of the problem statement list, this will be my last here)

I thought Loa (or someone) clarified - another SDO has two choices: (1)choose to go IETF standards track or (2) non-standards track (informational, experimental).

If the choice is standards track, they can initiate contact via a liaison.

The IETF Liaison process will provide guidelines on receiving/distribution/sending. And processing of the content. Depending on the request, varies actions may be appropriate, and can be clarified in the liaison process.

Deborah

-----Original Message-----
From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
Sent: Monday, March 03, 2003 11:30 AM
To: Loa Andersson
Cc: curtis@fictitious.org; Varma, Eve L (Eve); George Newsome;
mpls@UU.NET; ccamp
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt


Loa,
(snip)
> I don't discus liasions, simply because it
> was and is
> my opinion that they are not in the picture then it comes to handling
> changes to the
> (g)mpls protocols.
So, if another SDO thinks that an IETF protocol (possibly with extensions)
would be a good solution to their problem, they would ask for this how?
Regards,
Steve



From owner-mpls@UU.NET  Mon Mar  3 12:11:04 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03368
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 12:11:04 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelg02320
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 17:13:02 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoelg00852;
	Mon, 3 Mar 2003 17:12:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoelg29300
	for mpls-outgoing; Mon, 3 Mar 2003 17:12:08 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoelg29294
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 17:11:57 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoelg01447
	for <mpls@UU.NET>; Mon, 3 Mar 2003 17:10:52 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelg22085
	for <mpls@UU.NET>; Mon, 3 Mar 2003 17:10:51 GMT
Received: from mailb.telia.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailb.telia.com [194.22.194.6])
	id QQoelg22056
	for <mpls@UU.NET>; Mon, 3 Mar 2003 17:10:50 GMT
Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241])
	by mailb.telia.com (8.12.5/8.12.5) with ESMTP id h23HAkLU005075;
	Mon, 3 Mar 2003 18:10:46 +0100 (CET)
X-Original-Recipient: mpls@UU.NET
Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45])
	by d1o888.telia.com (8.10.2/8.10.1) with ESMTP id h23HAk227484;
	Mon, 3 Mar 2003 18:10:46 +0100 (CET)
Message-ID: <3E638B84.6080406@pi.se>
Date: Mon, 03 Mar 2003 18:06:12 +0100
From: Loa Andersson <loa@pi.se>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stephen Trowbridge <sjtrowbridge@lucent.com>
CC: mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <200302281703.MAA00661@bifocal.cisco.com> <3E636D1C.456EC406@lucent.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Steve,

you are right that the liasion process are a problem - if anyone thinks 
it will
do any good (AD's nod or shake your heads) I'm of course willing to help 
sort that
out. And it might be that we can make Sub-IP a pilot (again nods or 
shakes from
AD's). My tentative view is that this should be done as part of the 
problem statement
work.

BUT - it is far from the only problem, in fact the very draft that we 
ougth to be
discussing here was written with the liasion process very low on the 
horizion, it
was definitely not triggered by getting liasion carried requirments form 
other SDOs,
but it was triggered because, we seen more and more solutions coming in for
undocumented or poorly understood problems. We have an increasing 
concern over the
(g)mpls coherence and architecture in relation to these "solutions".

For the moment I'm not aware of any mpls related liasions hanging 
un-answered, there
are a set of them for ccamp, but Kireeti and Bert, have acknowledged 
that, and I
sincerly hope they won't try to use the change process to answer those 
liasions,
the process was not designed to do that.

There is something in this discussion that makes me think that there is 
a drive for
trying to take the origin of an requirement and make that an criterium 
when evaluating
the requirment. Kind of giving a group requirment precedence over an 
individula
requirment. I sincerly object to this, since I think ti is the technical 
merit
that is the evaluation point.


/Loa

Stephen Trowbridge wrote:

>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:
>  
>
>>>In message <3E5F8A25.8030201@pi.se>, 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.
>>>      
>>>
>>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 owner-mpls@UU.NET  Mon Mar  3 12:12:09 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03397
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 12:12:08 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelg26967
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 17:14:07 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoelg25832;
	Mon, 3 Mar 2003 17:13:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoelg29324
	for mpls-outgoing; Mon, 3 Mar 2003 17:13:09 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoelg29312
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 17:12:53 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoelg05138
	for <mpls@UU.NET>; Mon, 3 Mar 2003 17:10:51 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelg22055
	for <mpls@UU.NET>; Mon, 3 Mar 2003 17:10:50 GMT
Received: from ihemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ihemail1.lucent.com [192.11.222.161])
	id QQoelg22046
	for <mpls@UU.NET>; Mon, 3 Mar 2003 17:10:49 GMT
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h23HAmF11323;
	Mon, 3 Mar 2003 12:10:48 -0500 (EST)
Received: from lucent.com (sjtrowbridge-1.dr.lucent.com [135.4.20.16]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id LAA19887; Mon, 3 Mar 2003 11:10:46 -0600 (CST)
Message-ID: <3E638C95.167731F8@lucent.com>
Date: Mon, 03 Mar 2003 10:10:45 -0700
From: Stephen Trowbridge <sjtrowbridge@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5  (Windows NT 5.0; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: Scott Bradner <sob@harvard.edu>
CC: loa@pi.se, ccamp@ops.ietf.org, curtis@fictitious.org, evarma@lucent.com,
        gnewsome@ieee.org, mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <200303031648.h23GmwJO003841@newdev.harvard.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Scott,
There is no doubt that liaisons CURRENTLY have no more wieght than
individual IDs (perhaps even less - by the Bala flowchart, the fact
that an idea arrives via liaion may even work to the detriment of
a proposal (yes Loa, I know this is a joke!)).
But it is my opinion that the lack of a liaison process is really
the ROOT CAUSE of difficulties like what we saw in January.

There are some on this thread who seem to feel that the root cause
of the problem is that ITU-T is permitted to use or apply the IETF
protocol to their problem at all.

But I daresay that if we had had a good back-and-forth discussion
between the groups (with liaisons not only being considered seriously,
but responded to), that people would have understood far better what
the ITU-T was trying to do, and that there would not have been the
last minute arguments about whether ITU-T should be able to do it.

I have remarked on this before: some of our members (in ITU-T) are
interested in using the PNNI protcol to implement ASON instead of
the GMPLS protocols. The PNNI protocol also required extensions - it
did not meet the ASON requirements as-is.

I think that the primary reason that the job was so much easier with
PNNI and the ATM forum is not so much that PNNI is any better suited
to solving the problem, but that ATM forum took the liaison statements
seriously. They tried to understand the ITU-T problem and actively
tried to help solve it in the best way with their protocol.

If IETF ccamp had done the same (all the way back to Oct. 2001), the
arguments of January would never have happened.
Regards,
Steve

Scott Bradner wrote:
> 
> Steve,
>         Note that Loa is correct as to the impact of liasions, I-Ds
> or presentations by folk representing otehr SDOs within the IETF
> standards process - they carry just as much weight as the statemnts
> of any individual and there is currently no reason to have them
> treated as having some special status in the change-process ID.
> (see RFC 3356 sec 3.2.2 & RFC 2418 sec 1))  That said, I do think it would be
> good to mention that the use of liasion statements is common in other
> SDOs and that such statements should be not ignored when directed to
> IETF working groups.
> 
>         There are strong arguments that maybe the current assumptions
> should change butthis mailing list is not the place to discuss it - I
> would suggest that this dicussion be redirected to the problem-statement
> mailing list.
> 
> Scott


From owner-mpls@UU.NET  Mon Mar  3 12:18:02 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03644
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 12:18:02 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelh11750
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 17:19:57 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoelh09390;
	Mon, 3 Mar 2003 17:18:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoelh29968
	for mpls-outgoing; Mon, 3 Mar 2003 17:18:16 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoelh29945
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 17:18:00 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoelh26735
	for <mpls@uu.net>; Mon, 3 Mar 2003 17:17:00 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelh03066
	for <mpls@uu.net>; Mon, 3 Mar 2003 17:16:51 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoelh29199
	for <mpls@uu.net>; Mon, 3 Mar 2003 17:15:08 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h23HF4Nh005149
	for <mpls@uu.net>; Mon, 3 Mar 2003 12:15:04 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA17526 for <mpls@uu.net>; Mon, 3 Mar 2003 12:15:04 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h23HF4p05480 for mpls@uu.net; Mon, 3 Mar 2003 12:15:04 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoelg29310
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 17:12:51 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoelg07176
	for <mpls@UU.NET>; Mon, 3 Mar 2003 17:11:29 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelg29255
	for <mpls@UU.NET>; Mon, 3 Mar 2003 17:11:28 GMT
Received: from sj-msg-core-3.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-3.cisco.com [171.70.157.152])
	id QQoelg29238
	for <mpls@UU.NET>; Mon, 3 Mar 2003 17:11:27 GMT
Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h23HAoP7003701;
	Mon, 3 Mar 2003 09:10:50 -0800 (PST)
Received: from cisco.com (sjc-vpn3-502.cisco.com [10.21.65.246])
	by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA)
	with SMTP id AEM03149;
	Mon, 3 Mar 2003 08:53:42 -0800 (PST)
Received: by cisco.com (sSMTP sendmail emulation); Mon, 3 Mar 2003 12:11:01 -0500
Date: Mon, 3 Mar 2003 12:11:01 -0500
From: Scott W Brim <sbrim@cisco.com>
To: Scott Bradner <sob@harvard.edu>
Cc: loa@pi.se, sjtrowbridge@lucent.com, ccamp@ops.ietf.org,
        curtis@fictitious.org, evarma@lucent.com, gnewsome@ieee.org,
        mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Message-ID: <20030303171101.GN2408@sbrim-w2k>
Mail-Followup-To: Scott W Brim <sbrim@cisco.com>,
	Scott Bradner <sob@harvard.edu>, loa@pi.se, sjtrowbridge@lucent.com,
	ccamp@ops.ietf.org, curtis@fictitious.org, evarma@lucent.com,
	gnewsome@ieee.org, mpls@UU.NET
References: <3E638325.D254FF0F@lucent.com> <200303031648.h23GmwJO003841@newdev.harvard.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200303031648.h23GmwJO003841@newdev.harvard.edu>
User-Agent: Mutt/1.4i
Sender: owner-mpls@UU.NET
Precedence: bulk

On Mon, Mar 03, 2003 11:48:58AM -0500, Scott Bradner allegedly wrote:
> 	There are strong arguments that maybe the current assumptions
> should change butthis mailing list is not the place to discuss it - I 
> would suggest that this dicussion be redirected to the problem-statement 
> mailing list.

Or a new one (I hope).  Problem-statement deserves not to be de-focused.



From owner-mpls@UU.NET  Mon Mar  3 12:25:37 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03936
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 12:25:36 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelh23813
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 17:27:21 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoelh20243;
	Mon, 3 Mar 2003 17:25:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoelh00557
	for mpls-outgoing; Mon, 3 Mar 2003 17:25:26 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoelh00539
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 17:25:21 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoelh01731
	for <mpls@UU.NET>; Mon, 3 Mar 2003 17:25:07 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelh19046
	for <mpls@UU.NET>; Mon, 3 Mar 2003 17:25:06 GMT
Received: from w2ksjexg01.ciena.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [12.7.169.25])
	id QQoelh19028
	for <mpls@UU.NET>; Mon, 3 Mar 2003 17:25:06 GMT
Received: from wntcsdexg01.csd.ciena.com ([10.34.31.31]) by w2ksjexg01.ciena.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id FN3672PX; Mon, 3 Mar 2003 09:24:47 -0800
Received: by webdev-llnt.oni.com with Internet Mail Service (5.5.2653.19)
	id <Y5W9NG77>; Mon, 3 Mar 2003 09:25:04 -0800
Message-ID: <2135200C183FD5119588009027DE572302836D78@webdev-owa.oni.com>
From: "Ong, Lyndon" <LyOng@ciena.com>
To: "'Loa Andersson'" <loa@pi.se>
Cc: mpls@UU.NET
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Mon, 3 Mar 2003 09:24:55 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Loa,

Sorry my comments were not as clear as could have been:

-- on the diagram, there should be a path leading away from
IETF activity (and perhaps looping back) when it is decided
that the work should be done outside IETF.  Figure this is
different from "dustbin" :o)

-- on the mailing lists, the current text is ambiguous as
to what specific group is addressed:
  "The mailing list to use should be the Area
   mailing list for the area that the working group that has specified
   the protocol being changed and that will likely be the requirement
   evaluation working group."

I wonder in fact if it should be the mailing list for the group 
dealing with the affected protocol, since that's where you'll
get people's attention.

-- on the "loophole", my thought was that if someone or group brings
in a proposal, a WG may volunteer to address it but not actually 
have time on its agenda, and thought there should be some way to
appeal or raise the issue if nothing is getting done. Since the 
procedure otherwise is designed to limit the alternatives once it
has been assigned within IETF, some counterbalance seems needed.

Thanks,

Lyndon


-----Original Message-----
From: Loa Andersson [mailto:loa@pi.se]
Sent: Saturday, March 01, 2003 7:36 AM
To: Ong, Lyndon
Cc: mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt


Lyndon,

thanks - it looks like we are making progress - some questions/inline.

Ong, Lyndon wrote:

>Hi Folks,
>
>I support the request to stick to constructive comments.
>
>Of course that means avoiding statements like "The
>ITU has stepped out of bounds (again).  They deserve to be ignored."
>(Last I heard, SDH/OTN networks were within bounds of ITU ;o)
>
>Or "dogmatic statements of connection-oriented  religion" (these
>are, for gmpls, connection-oriented networks we're talking about ;0)
>
>Seriously, though, I do have some comments on the draft:
>
>-- the figure shows the only path outside of the IETF process to
>be a dustbin.  Hopefully that's not intentional, although a lot
>of folks on the list probably believe this ;o)
>
could you specify which path(s)

>
>
>-- there's some text mixed up in 2.2.1 regarding which mailing list
>should be used.
>
specific please - I intended to say the area list of the wg that 
specified the protocol,
can't see the mix up

>
>
>-- we should incorporate Deborah's suggestion for 2.2.2 about having
>the decision posted to the mailing list within a specified period  (the
>posting of a decision could apply to liaisons, and might have helped
>avoid the confusion with the ITU liaison)
>
I clearly sympatize with this, but since all decisions in the change
process are taken by I*, with the exception of the initial of being
where ADs and wg chairs, decides on whether to request chartiering the
req evaluation, are controlled by the I*, I think it is outside scope of
draft to specify how and when. It has been my assumption that this is
within the I* domain

>
>
>-- in 2.2.4, the paragraph after item (2) seems a little premature - 
>the recommendation by the rewg presumably must be approved by IESG/IAB
>before a decision is made.
>
OK, can see this - would this be feasible

   If IESG/IAB approves of a recommendation according to cases 1 & 2 the 
   IETF will not publish an RFC that attempts to get around the decision.

I complicates the flow chart a bit, but will be manageable, I can always
ask Bala to help ;)

>
>
>-- there is a bit of a loophole in that the problem could be accepted
>and farmed off to a WG but there's no check to see if anything is ever
>done, and items could easily fall through a crack given the large 
>numbers of work items usually in CCAMP and MPLS.  There could be a 
>procedure to revisit the decision in case no progress is being made
>within some specified timeframe.
>
no I htink tht this is not a loop hole - there is no way ever where you can
"farm a problem out" and expect the wg to do your job for you,  ti requires
youra active participation, IETF  is a community of co-workers not an
agency that takes assignments - every time you bring something in to the
IETF youd don't say "Here is something YOU should do while I go about 
minding
my own business", instead you should say "Here is something I think WE 
should do".

>
>
>-- in general, I hope people keep in mind that the scope of interest
>and the resources available in IETF are limited, and should not become a
>bottleneck - if work can be or is already being done in other bodies and 
>there is a process for IETF to review this work and identify potential
>problems or simpler/more general ways to do the desired function,
>this should be viewed as a generally positive thing.
>

agreed - that is why all the 4 bullets were insluded, and yes I agree as
long as the architecural issues and the safe guarding of opertional aspects
the Inernet are respected, but on the other hand bringing something to the
IETF and not being prepared to work on it is likely to create a "bottleneck"

>
>
>Cheers,
>
>Lyndon
>
>
>




From owner-mpls@UU.NET  Mon Mar  3 12:47:38 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04723
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 12:47:38 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelj28687
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 17:49:36 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoelj25235;
	Mon, 3 Mar 2003 17:48:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoelj01727
	for mpls-outgoing; Mon, 3 Mar 2003 17:47:42 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoelj01722
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 17:47:35 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoelj12193
	for <mpls@UU.NET>; Mon, 3 Mar 2003 17:47:00 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelj20981
	for <mpls@UU.NET>; Mon, 3 Mar 2003 17:47:00 GMT
Received: from mailc.telia.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailc.telia.com [194.22.190.4])
	id QQoelj20965
	for <mpls@UU.NET>; Mon, 3 Mar 2003 17:46:59 GMT
Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241])
	by mailc.telia.com (8.12.5/8.12.5) with ESMTP id h23HksbZ017476;
	Mon, 3 Mar 2003 18:46:54 +0100 (CET)
X-Original-Recipient: mpls@UU.NET
Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45])
	by d1o888.telia.com (8.10.2/8.10.1) with ESMTP id h23Hks210608;
	Mon, 3 Mar 2003 18:46:54 +0100 (CET)
Message-ID: <3E6393FC.4090007@pi.se>
Date: Mon, 03 Mar 2003 18:42:20 +0100
From: Loa Andersson <loa@pi.se>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Brungard, Deborah A, ALABS" <dbrungard@att.com>
CC: mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <2FEC2C81634CDB4C9F191943ACCDC624079AA622@OCCLUST02EVS1.ugd.att.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Deborah,

I think there could be an agreement along those lines

- one draft that specifies the change-process
- one draft that specifies the liasion process

both are needed for different reasons, both to be progressed indepentdently
on their own merits. If there are interdenpendencies, we'll update the 
docs as
needed.

I did volunteer myself, not the chagne-process authors, that is not 
something
I can do, but I would certainly welcome them if they wanted to participate.
The key here for is to understand if the liasion process is within the 
problem
statement work, and if so it has been addressed there or if any plans exists
to do so.

/Loa

Brungard, Deborah A, ALABS wrote:

>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:sjtrowbridge@lucent.com]
>Sent: Monday, March 03, 2003 9:56 AM
>To: George Swallow
>Cc: curtis@fictitious.org; Loa Andersson; mpls@UU.NET; 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:
>  
>
>>>In message <3E5F8A25.8030201@pi.se>, 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.
>>>      
>>>
>>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 owner-mpls@UU.NET  Mon Mar  3 12:51:27 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04855
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 12:51:26 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelj07069
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 17:53:21 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoelj04584;
	Mon, 3 Mar 2003 17:52:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoelj01921
	for mpls-outgoing; Mon, 3 Mar 2003 17:51:49 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoelj01914
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 17:51:33 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoelj25079
	for <mpls@UU.NET>; Mon, 3 Mar 2003 17:51:14 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelj00871
	for <mpls@UU.NET>; Mon, 3 Mar 2003 17:51:11 GMT
Received: from hoemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail2.lucent.com [192.11.226.163])
	id QQoelj00759
	for <mpls@UU.NET>; Mon, 3 Mar 2003 17:51:08 GMT
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h23Hp4i15860;
	Mon, 3 Mar 2003 12:51:04 -0500 (EST)
Received: from lucent.com (sjtrowbridge-1.dr.lucent.com [135.4.20.16]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id LAA06273; Mon, 3 Mar 2003 11:51:03 -0600 (CST)
Message-ID: <3E639606.FBF85345@lucent.com>
Date: Mon, 03 Mar 2003 10:51:02 -0700
From: Stephen Trowbridge <sjtrowbridge@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5  (Windows NT 5.0; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: Loa Andersson <loa@pi.se>
CC: mpls@UU.NET, ccamp <ccamp@ops.ietf.org>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <200302281703.MAA00661@bifocal.cisco.com> <3E636D1C.456EC406@lucent.com> <3E638B84.6080406@pi.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Loa,
Can you give me some examples of things you consider to be solutions
being proposed (by individuals) for undocumented or poorly understood
problems? I admit to following mpls only peripherally, but in ccamp
it seems like the bulk of proposals (if not ALL of the proposals)
originate from attempts to solve problems raised by other SDOs.
If I could see examples of this sort for mpls, I perhaps could
understand better why this kind of change control procedure would
be necessary.

Here is the sense in which the evaluation of the requirement must take
into consideration the source:
Evaluation of a requirement by an IETF WG (or any other body to which
a requirement is proposed) is a subjective process. The IETF WG will
interpret the requirement in the context of their charter and the kinds
of networks and technologies they are most familiar with.

Another SDO may come up with requirements related to THEIR charter and
the kinds of networks and technologies they are familiar with. These
requirements may be exceedingly critical within the application domain
for the other SDO, but may seem irrelevant or unimportant for the
application domain of the IETF WG.

So an IETF WG which is trying to maintain sanity over a protocol that
is applied by different SDOs to different application spaces DOES need
to consider requirements from different SDOs in a different way from
internal requirements. When evaluating an internal requirement, people
should understand why that requirement is important in the context of
the charter of the IETF WG. When evaluating a requirement, for example,
from ITU-T, the question should be, not why this is an important
requirement within the context of the WG charter, but to understand
why (or accept that) it is an important requirement for ITU-T and
their application space.

Regards,
Steve


Loa Andersson wrote:
> 
> Steve,
> 
> you are right that the liasion process are a problem - if anyone thinks
> it will
> do any good (AD's nod or shake your heads) I'm of course willing to help
> sort that
> out. And it might be that we can make Sub-IP a pilot (again nods or
> shakes from
> AD's). My tentative view is that this should be done as part of the
> problem statement
> work.
> 
> BUT - it is far from the only problem, in fact the very draft that we
> ougth to be
> discussing here was written with the liasion process very low on the
> horizion, it
> was definitely not triggered by getting liasion carried requirments form
> other SDOs,
> but it was triggered because, we seen more and more solutions coming in for
> undocumented or poorly understood problems. We have an increasing
> concern over the
> (g)mpls coherence and architecture in relation to these "solutions".
> 
> For the moment I'm not aware of any mpls related liasions hanging
> un-answered, there
> are a set of them for ccamp, but Kireeti and Bert, have acknowledged
> that, and I
> sincerly hope they won't try to use the change process to answer those
> liasions,
> the process was not designed to do that.
> 
> There is something in this discussion that makes me think that there is
> a drive for
> trying to take the origin of an requirement and make that an criterium
> when evaluating
> the requirment. Kind of giving a group requirment precedence over an
> individula
> requirment. I sincerly object to this, since I think ti is the technical
> merit
> that is the evaluation point.
> 
> /Loa
> 
> Stephen Trowbridge wrote:
> 
> >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:
> >
> >
> >>>In message <3E5F8A25.8030201@pi.se>, 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.
> >>>
> >>>
> >>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 owner-mpls@UU.NET  Mon Mar  3 12:58:10 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05266
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 12:58:10 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelk12526
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 18:00:10 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoelj11828;
	Mon, 3 Mar 2003 17:59:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoelj02317
	for mpls-outgoing; Mon, 3 Mar 2003 17:59:28 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoelj02310
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 17:59:21 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoelj04036
	for <mpls@UU.NET>; Mon, 3 Mar 2003 17:59:05 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelj19244
	for <mpls@UU.NET>; Mon, 3 Mar 2003 17:59:04 GMT
Received: from newdev.harvard.edu by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: newdev.eecs.harvard.edu [140.247.60.212])
	id QQoelj19223
	for <mpls@UU.NET>; Mon, 3 Mar 2003 17:59:03 GMT
Received: (from sob@localhost)
	by newdev.harvard.edu (8.12.6/8.12.2) id h23HwuI9004544;
	Mon, 3 Mar 2003 12:58:56 -0500 (EST)
Date: Mon, 3 Mar 2003 12:58:56 -0500 (EST)
From: Scott  Bradner <sob@harvard.edu>
Message-Id: <200303031758.h23HwuI9004544@newdev.harvard.edu>
To: dbrungard@att.com, loa@pi.se
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Cc: mpls@UU.NET
In-Reply-To: <3E6393FC.4090007@pi.se>
Sender: owner-mpls@UU.NET
Precedence: bulk

> I think there could be an agreement along those lines
> 
> - one draft that specifies the change-process
> - one draft that specifies the liasion process

note that the liasion process discussion is not SUB-IP specific,
the same issues come up in transport and elsewhere - so that doc
needs more thinking

it is a topic that I'm quite interested in and would be wiling to
work on if others thought it would help

Scott


From owner-mpls@UU.NET  Mon Mar  3 13:46:34 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07172
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 13:46:34 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeln23398
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 18:48:21 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoelm12187;
	Mon, 3 Mar 2003 18:42:18 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoelm23408
	for mpls-outgoing; Mon, 3 Mar 2003 18:41:49 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoelm23401
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 18:41:32 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoelm23344
	for <mpls@UU.NET>; Mon, 3 Mar 2003 18:40:58 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelm08127
	for <mpls@UU.NET>; Mon, 3 Mar 2003 18:40:58 GMT
Received: from znsgs01r.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: h6s128a211n47.user.nortelnetworks.com [47.211.128.6])
	id QQoelm08119
	for <mpls@UU.NET>; Mon, 3 Mar 2003 18:40:57 GMT
Received: from znsgy0k8.europe.nortel.com (europem01.nt.com [47.165.24.67])
	by znsgs01r.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h23IeUm17586;
	Mon, 3 Mar 2003 18:40:30 GMT
Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id FS3M3WM8; Mon, 3 Mar 2003 18:40:30 -0000
Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19)
	id <FS39X7SK>; Mon, 3 Mar 2003 18:39:41 -0000
Message-ID: <4103264BC8D3D51180B7002048400C4501623329@zhard0jd.europe.nortel.com>
X-Sybari-Space: 00000000 00000000 00000000
From: "Elwyn Davies" <elwynd@nortelnetworks.com>
To: "'Loa Andersson'" <loa@pi.se>,
        "Brungard, Deborah A, ALABS"
	 <dbrungard@att.com>
Cc: mpls@UU.NET, "IETF problem (E-mail)" <problem-statement@alvestrand.no>
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Mon, 3 Mar 2003 18:39:35 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2E1B4.3D0A6710"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2E1B4.3D0A6710
Content-Type: text/plain;
	charset="iso-8859-1"

Hi.

The problem-statement WG is only (nearly) chartered to document the
perceived problems and attempt to find a set of root causes if possible.  We
have published a first cut at the problems list
(draft-ietf-problem-issue-statement-00, now available on the I-D site).  

Although there are a number of problems relating to external perception of
the IETF, the liaison issue was not much talked about, possibly because the
contributors were more focused on the internal problems. Accordingly it
didn't have much of an effect on the root cause problem list - what is
discussed is the IETF's problem with not clearly setting out its mission,
and in particular the degree to which it wishes to emulate a more
conventional SDO.  The problems with liaisons can be seen as a subsidiary
symptom of this.

Anyway, the liaison problem (and the rest of the SDO relationships) has been
forcibly brought to our attention and it looks like it should feature more
prominently in the root cause problems.

As regards starting to solve it, Loa believes (G)MPLS needs a solution RSN;
on the other hand, 'how to solve the general liaison problem' needs to be
part of the direction which the 'solutions process' piece of our work will
consider shortly, and it needs to be considerd in the general light of the
IETF mission (whatever that turns out to be).

Regards,
Elwyn Davies
(editor of draft-ietf-problem-issue-statement)



> -----Original Message-----
> From: Loa Andersson [mailto:loa@pi.se]
> Sent: 03 March 2003 17:42
> To: Brungard, Deborah A, ALABS
> Cc: mpls@UU.NET
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> Deborah,
> 
> I think there could be an agreement along those lines
> 
> - one draft that specifies the change-process
> - one draft that specifies the liasion process
> 
> both are needed for different reasons, both to be progressed 
> indepentdently
> on their own merits. If there are interdenpendencies, we'll 
> update the 
> docs as
> needed.
> 
> I did volunteer myself, not the chagne-process authors, that is not 
> something
> I can do, but I would certainly welcome them if they wanted 
> to participate.
> The key here for is to understand if the liasion process is 
> within the 
> problem
> statement work, and if so it has been addressed there or if 
> any plans exists
> to do so.
> 
> /Loa
> 
> Brungard, Deborah A, ALABS wrote:
> 
> >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:sjtrowbridge@lucent.com]
> >Sent: Monday, March 03, 2003 9:56 AM
> >To: George Swallow
> >Cc: curtis@fictitious.org; Loa Andersson; mpls@UU.NET; 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:
> >  
> >
> >>>In message <3E5F8A25.8030201@pi.se>, 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.
> >>>      
> >>>
> >>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
> >>    
> >>
> >
> >
> >
> >
> >  
> >
> 
> 
> 

------_=_NextPart_001_01C2E1B4.3D0A6710
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi.</FONT>
</P>

<P><FONT SIZE=3D2>The problem-statement WG is only (nearly) chartered =
to document the perceived problems and attempt to find a set of root =
causes if possible.&nbsp; We have published a first cut at the problems =
list (draft-ietf-problem-issue-statement-00, now available on the I-D =
site).&nbsp; </FONT></P>

<P><FONT SIZE=3D2>Although there are a number of problems relating to =
external perception of the IETF, the liaison issue was not much talked =
about, possibly because the contributors were more focused on the =
internal problems. Accordingly it didn't have much of an effect on the =
root cause problem list - what is discussed is the IETF's problem with =
not clearly setting out its mission, and in particular the degree to =
which it wishes to emulate a more conventional SDO.&nbsp; The problems =
with liaisons can be seen as a subsidiary symptom of this.</FONT></P>

<P><FONT SIZE=3D2>Anyway, the liaison problem (and the rest of the SDO =
relationships) has been forcibly brought to our attention and it looks =
like it should feature more prominently in the root cause =
problems.</FONT></P>

<P><FONT SIZE=3D2>As regards starting to solve it, Loa believes (G)MPLS =
needs a solution RSN; on the other hand, 'how to solve the general =
liaison problem' needs to be part of the direction which the 'solutions =
process' piece of our work will consider shortly, and it needs to be =
considerd in the general light of the IETF mission (whatever that turns =
out to be).</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Elwyn Davies</FONT>
<BR><FONT SIZE=3D2>(editor of =
draft-ietf-problem-issue-statement)</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Loa Andersson [<A =
HREF=3D"mailto:loa@pi.se">mailto:loa@pi.se</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: 03 March 2003 17:42</FONT>
<BR><FONT SIZE=3D2>&gt; To: Brungard, Deborah A, ALABS</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: mpls@UU.NET</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: I-D =
ACTION:draft-andersson-mpls-g-chng-proc-00.txt</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Deborah,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I think there could be an agreement along those =
lines</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; - one draft that specifies the =
change-process</FONT>
<BR><FONT SIZE=3D2>&gt; - one draft that specifies the liasion =
process</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; both are needed for different reasons, both to =
be progressed </FONT>
<BR><FONT SIZE=3D2>&gt; indepentdently</FONT>
<BR><FONT SIZE=3D2>&gt; on their own merits. If there are =
interdenpendencies, we'll </FONT>
<BR><FONT SIZE=3D2>&gt; update the </FONT>
<BR><FONT SIZE=3D2>&gt; docs as</FONT>
<BR><FONT SIZE=3D2>&gt; needed.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I did volunteer myself, not the chagne-process =
authors, that is not </FONT>
<BR><FONT SIZE=3D2>&gt; something</FONT>
<BR><FONT SIZE=3D2>&gt; I can do, but I would certainly welcome them if =
they wanted </FONT>
<BR><FONT SIZE=3D2>&gt; to participate.</FONT>
<BR><FONT SIZE=3D2>&gt; The key here for is to understand if the =
liasion process is </FONT>
<BR><FONT SIZE=3D2>&gt; within the </FONT>
<BR><FONT SIZE=3D2>&gt; problem</FONT>
<BR><FONT SIZE=3D2>&gt; statement work, and if so it has been addressed =
there or if </FONT>
<BR><FONT SIZE=3D2>&gt; any plans exists</FONT>
<BR><FONT SIZE=3D2>&gt; to do so.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; /Loa</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Brungard, Deborah A, ALABS wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;I think we have agreement to do a separate =
document on the </FONT>
<BR><FONT SIZE=3D2>&gt; liaison process? (as I'm writing, I see a mail =
just now from </FONT>
<BR><FONT SIZE=3D2>&gt; Scott saying this). Loa, not sure if you were =
volunteering </FONT>
<BR><FONT SIZE=3D2>&gt; the g-chng proc authors? They are probably the =
most </FONT>
<BR><FONT SIZE=3D2>&gt; appropriate. If you need support (either =
visible/ghosts), </FONT>
<BR><FONT SIZE=3D2>&gt; Steve (ok, Steve?) can help from the ITU =
perspective, I can </FONT>
<BR><FONT SIZE=3D2>&gt; help from the T1X1 side.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Steve, I agree for SDOs, the key problem is =
the lack of a </FONT>
<BR><FONT SIZE=3D2>&gt; liaison process. Regardless, for IETF, a change =
process is </FONT>
<BR><FONT SIZE=3D2>&gt; needed. The GMPLS work is just going to rfc =
status and there </FONT>
<BR><FONT SIZE=3D2>&gt; will be both individual and SDO requests for =
</FONT>
<BR><FONT SIZE=3D2>&gt; additions/changes. For the liaison process, I =
think we need </FONT>
<BR><FONT SIZE=3D2>&gt; to distinguish the communication protocol =
</FONT>
<BR><FONT SIZE=3D2>&gt; =
(administrative=3Dreceive/distribution/transmit) from the </FONT>
<BR><FONT SIZE=3D2>&gt; processing (administrative and technical) of =
the liaison </FONT>
<BR><FONT SIZE=3D2>&gt; request. Both need to be clarified.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Considering we agree to have a separate =
document for a </FONT>
<BR><FONT SIZE=3D2>&gt; liaison process, and applying a constructive =
filter to the </FONT>
<BR><FONT SIZE=3D2>&gt; mail exchange, Lyndon's mail and my mail have =
direct comments </FONT>
<BR><FONT SIZE=3D2>&gt; on the draft, any others?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;As I noted previously, to distinguish this =
process from the </FONT>
<BR><FONT SIZE=3D2>&gt; liaison process, should either remove external =
standards </FONT>
<BR><FONT SIZE=3D2>&gt; bodies from the text or clarify =
&quot;individuals of external </FONT>
<BR><FONT SIZE=3D2>&gt; standards bodies&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Agree with Lyndon, &quot;dustbin&quot; =
should be defined for non-ietf </FONT>
<BR><FONT SIZE=3D2>&gt; aware, i.e. a note describing the option as =
non-standards </FONT>
<BR><FONT SIZE=3D2>&gt; track=3Dinformational or experimental =
rfc.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;As Lyndon says, resources in all the =
standards groups are </FONT>
<BR><FONT SIZE=3D2>&gt; extremely limited, it's in the industry and our =
companies </FONT>
<BR><FONT SIZE=3D2>&gt; interests to collaborate. Let's use this week =
for specific </FONT>
<BR><FONT SIZE=3D2>&gt; comments on the draft.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Deborah</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;From: Stephen Trowbridge [<A =
HREF=3D"mailto:sjtrowbridge@lucent.com">mailto:sjtrowbridge@lucent.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Sent: Monday, March 03, 2003 9:56 AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;To: George Swallow</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Cc: curtis@fictitious.org; Loa Andersson; =
mpls@UU.NET; ccamp</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Subject: Re: I-D =
ACTION:draft-andersson-mpls-g-chng-proc-00.txt</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;All,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Lets try to zero in on what the problem =
really is.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;I think that liaison handling (or the lack =
thereof) is not just a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;problem. It is THE problem. Does anybody =
really believe that the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;reason this draft exists in the first place =
is that there are a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;bunch of individuals going wild trying to =
change or extend the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;(G)MPLS protocols?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;What seems to have generated most of the =
arguments is the handling</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;(or bungling) of the communications process =
(or lack of process)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;with other SDOs. This is the process we =
need to fix.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Dealing with requests from individuals to =
extend or change the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;protocols might be good to have a process =
for, but realistically,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;has any individual made such a request yet? =
Why is this important?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Now, if we can agree that liaisons are THE =
problem,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;there are two ways we can go:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;- We can start work on a general purpose =
liaison process to be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;applied across the whole of IETF (revival =
of one of the POIS*</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;working groups?).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;- We could try to develop a pilot process =
for sub-IP (which is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;where we seem to have a lot of the =
problems), and take what we</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;learn from its implementation to feed into =
a process that would</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;apply to the whole of IETF.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;While I can appreciate that a general =
problem should usually have</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;a general solution, there is some appeal to =
taking the second</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;approach because (1) we could probably get =
something underway</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;faster; and (2) sub-IP seems to be where =
the lack of such a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;process is causing us the most pain.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Steve</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;George Swallow wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;&gt;In message =
&lt;3E5F8A25.8030201@pi.se&gt;, Loa Andersson writes:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;&gt;&gt;- I don't think it is agood =
idea to describe the two </FONT>
<BR><FONT SIZE=3D2>&gt; process in the same</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;&gt;&gt;&nbsp; document. the =
chnage-process is for our internal use, </FONT>
<BR><FONT SIZE=3D2>&gt; the liasion process</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;&gt;&gt;&nbsp; is for our =
commuinication with other SDOs</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;&gt;If we can agree on this, then we =
can move forward with </FONT>
<BR><FONT SIZE=3D2>&gt; your document.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;I think they need to be separate =
because the liaison draft should</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;apply across the board to IETF / ITU =
interactions and this document</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;applies only to (G)MPLS.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;...George</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&gt;=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;George =
Swallow&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Cisco =
Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (978) 497-8143</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 250 Apollo =
Drive</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Chelmsford, Ma =
01824</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2E1B4.3D0A6710--


From owner-mpls@UU.NET  Mon Mar  3 13:52:58 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07462
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 13:52:58 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeln01641
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 18:54:49 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeln29215;
	Mon, 3 Mar 2003 18:53:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeln24742
	for mpls-outgoing; Mon, 3 Mar 2003 18:53:22 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoeln24737
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 18:53:16 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoeln19845
	for <mpls@uu.net>; Mon, 3 Mar 2003 18:53:05 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeln00883
	for <mpls@uu.net>; Mon, 3 Mar 2003 18:53:05 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoeln00871
	for <mpls@uu.net>; Mon, 3 Mar 2003 18:53:04 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h23Ir2Nh010754
	for <mpls@uu.net>; Mon, 3 Mar 2003 13:53:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA25589 for <mpls@uu.net>; Mon, 3 Mar 2003 13:53:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h23Ir2U15464 for mpls@uu.net; Mon, 3 Mar 2003 13:53:02 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoeln24676
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 18:51:28 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoeln10580
	for <mpls@UU.NET>; Mon, 3 Mar 2003 18:51:05 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeln19417
	for <mpls@UU.NET>; Mon, 3 Mar 2003 18:51:04 GMT
Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoeln19388
	for <mpls@UU.NET>; Mon, 3 Mar 2003 18:51:03 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id NAA79846;
	Mon, 3 Mar 2003 13:49:02 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303031849.NAA79846@workhorse.fictitious.org>
To: Stephen Trowbridge <sjtrowbridge@lucent.com>
cc: Loa Andersson <loa@pi.se>, curtis@fictitious.org,
        "Varma,
    Eve L (Eve)" <evarma@lucent.com>,
        George Newsome <gnewsome@ieee.org>, mpls@UU.NET,
        ccamp <ccamp@ops.ietf.org>
Reply-To: curtis@fictitious.org
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
In-reply-to: Your message of "Mon, 03 Mar 2003 09:30:29 MST."
             <3E638325.D254FF0F@lucent.com> 
Date: Mon, 03 Mar 2003 13:49:02 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <3E638325.D254FF0F@lucent.com>, Stephen Trowbridge writes:
> Loa,
> (snip)
> > I don't discus liasions, simply because it
> > was and is
> > my opinion that they are not in the picture then it comes to handling
> > changes to the
> > (g)mpls protocols.
> So, if another SDO thinks that an IETF protocol (possibly with extensions)
> would be a good solution to their problem, they would ask for this how?
> Regards,
> Steve


Steve,

They would bring the topic up on the appropriate WG mailing list and
submit an internet-draft.

Your prior example of ASON is analogous IETF creating document that
change the underlying SONET model and creating extensions to SONET
outside of ITU (for example: using the loosely defined or undefined
portion of the SONET overhead) specificly to support IP and then
claiming that it was for IP so ITU should just accept it without
questioning it.  There is no reason for the IETF to accept ASON as a
requirement for MPLS/GMPLS.

Curtis



From owner-mpls@UU.NET  Mon Mar  3 14:10:02 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08164
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 14:10:01 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelo00826
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 19:11:55 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoelo28108;
	Mon, 3 Mar 2003 19:10:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoelo14431
	for mpls-outgoing; Mon, 3 Mar 2003 19:10:22 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoelo14412
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 19:10:19 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoelo24873
	for <mpls@uu.net>; Mon, 3 Mar 2003 19:10:08 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelo26787
	for <mpls@uu.net>; Mon, 3 Mar 2003 19:10:07 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoelo26758
	for <mpls@uu.net>; Mon, 3 Mar 2003 19:10:06 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h23JA4JR008706
	for <mpls@uu.net>; Mon, 3 Mar 2003 14:10:04 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA27219 for <mpls@uu.net>; Mon, 3 Mar 2003 14:10:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h23JA3a18027 for mpls@uu.net; Mon, 3 Mar 2003 14:10:03 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoelo14202
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 19:09:10 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoelo20744
	for <mpls@UU.NET>; Mon, 3 Mar 2003 19:08:47 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelo14811
	for <mpls@UU.NET>; Mon, 3 Mar 2003 19:08:47 GMT
Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoelo14776
	for <mpls@UU.NET>; Mon, 3 Mar 2003 19:08:46 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA80054;
	Mon, 3 Mar 2003 14:06:53 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303031906.OAA80054@workhorse.fictitious.org>
To: "Ong, Lyndon" <LyOng@ciena.com>
cc: "'Loa Andersson'" <loa@pi.se>, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
In-reply-to: Your message of "Mon, 03 Mar 2003 09:24:55 PST."
             <2135200C183FD5119588009027DE572302836D78@webdev-owa.oni.com> 
Date: Mon, 03 Mar 2003 14:06:53 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <2135200C183FD5119588009027DE572302836D78@webdev-owa.oni.com>, "Ong,
 Lyndon" writes:
> Hi Loa,
> 
> Sorry my comments were not as clear as could have been:
> 
> -- on the diagram, there should be a path leading away from
> IETF activity (and perhaps looping back) when it is decided
> that the work should be done outside IETF.  Figure this is
> different from "dustbin" :o)
> 
> -- on the mailing lists, the current text is ambiguous as
> to what specific group is addressed:
>   "The mailing list to use should be the Area
>    mailing list for the area that the working group that has specified
>    the protocol being changed and that will likely be the requirement
>    evaluation working group."
> 
> I wonder in fact if it should be the mailing list for the group 
> dealing with the affected protocol, since that's where you'll
> get people's attention.
> 
> -- on the "loophole", my thought was that if someone or group brings
> in a proposal, a WG may volunteer to address it but not actually 
> have time on its agenda, and thought there should be some way to
> appeal or raise the issue if nothing is getting done. Since the 
> procedure otherwise is designed to limit the alternatives once it
> has been assigned within IETF, some counterbalance seems needed.
> 
> Thanks,
> 
> Lyndon


We should also add?

   +-------------+
   |  Is this a  |
   |  good idea? | --- YES --->  IETF process
   +-------------+
          |
         NO!
          |
          V
     Send it to the another
     standard body to reduce
     mailing list noise

That would be closer to current practice.  :-)

Curtis



From owner-mpls@UU.NET  Mon Mar  3 14:23:53 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08629
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 14:23:53 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelp27871
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 19:25:49 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoelp25496;
	Mon, 3 Mar 2003 19:24:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoelp16064
	for mpls-outgoing; Mon, 3 Mar 2003 19:24:27 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoelp16059
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 19:24:24 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoelp04257
	for <mpls@UU.NET>; Mon, 3 Mar 2003 19:24:06 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelp12638
	for <mpls@UU.NET>; Mon, 3 Mar 2003 19:24:06 GMT
Received: from ihemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ihemail2.lucent.com [192.11.222.163])
	id QQoelp12625
	for <mpls@UU.NET>; Mon, 3 Mar 2003 19:24:06 GMT
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h23JO3N01297;
	Mon, 3 Mar 2003 14:24:03 -0500 (EST)
Received: from lucent.com (sjtrowbridge-1.dr.lucent.com [135.4.20.16]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id NAA21505; Mon, 3 Mar 2003 13:24:02 -0600 (CST)
Message-ID: <3E63ABD0.89B8FAA4@lucent.com>
Date: Mon, 03 Mar 2003 12:24:00 -0700
From: Stephen Trowbridge <sjtrowbridge@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5  (Windows NT 5.0; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: curtis@fictitious.org
CC: Loa Andersson <loa@pi.se>, "Varma, Eve L (Eve)" <evarma@lucent.com>,
        George Newsome <gnewsome@ieee.org>, mpls@UU.NET,
        ccamp <ccamp@ops.ietf.org>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <200303031849.NAA79846@workhorse.fictitious.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Curtis,
I think you are missing my point.

IETF has one set of requirements for the kinds of networks that they
envision and are within their charter. They develop an architecture and
protocol solutions to support those requirements.
ITU-T has an (overlapping but different) set of requirements for the
kinds of networks they envision (including lots of TDM & WDM traffic
that doesn't necessarily carry IP, etc.).
Nobody says that the additional ITU-T requirements are valid for
the IETF application, or that IETF must solve the ITU-T requirements
with IETF developed protocols (they can choose to, but there is no obligation).

When the ITU-T brings these requirements to the IETF's attention, there
are a variety of perfectly reasonable responses:
- The IETF can say "That requirement is important for us also, let's work
  toward a common solution".
- The IETF can say "That requirement is not important for the IETF scope
  of work, but we can see how it is important for yours. From our
  experience with the protocol and our desire for sanity in the protocol
  and all of its extensions, we can offer you the following advice about
  how the protocol can best solve your problem ..."
- The IETF can say "That requirement is not important for the IETF scope
  of work and we are not particularly interested in helping with a solution -
  you are on your own, but please assign any protocol codepoints through
  IANA and document your extensions as an info RFC so that we can prevent
  any conflict with other extensions.
They could EVEN say "We think you might have misunderstood the requirements:
do you think that the following restatement of the problem would allow your
needs to be met with the current protocols: ..."

But the answer that I would have trouble with would be the IETF saying "That
requirement is not important for the IETF scope of work, and therefore no
solution should be developed for your problem AT ALL. After all, if it is not
important for IETF, it must be irrelevant for everybody."

Of course, without a liaison process, I don't know how we get any of these
responses. Incoming liaisons seem to hit the dustbin before they get serious
consideration regarding which of the above response types might be most
appropriate.
Regards,
Steve

Curtis Villamizar wrote:
> 
> In message <3E638325.D254FF0F@lucent.com>, Stephen Trowbridge writes:
> > Loa,
> > (snip)
> > > I don't discus liasions, simply because it
> > > was and is
> > > my opinion that they are not in the picture then it comes to handling
> > > changes to the
> > > (g)mpls protocols.
> > So, if another SDO thinks that an IETF protocol (possibly with extensions)
> > would be a good solution to their problem, they would ask for this how?
> > Regards,
> > Steve
> 
> Steve,
> 
> They would bring the topic up on the appropriate WG mailing list and
> submit an internet-draft.
> 
> Your prior example of ASON is analogous IETF creating document that
> change the underlying SONET model and creating extensions to SONET
> outside of ITU (for example: using the loosely defined or undefined
> portion of the SONET overhead) specificly to support IP and then
> claiming that it was for IP so ITU should just accept it without
> questioning it.  There is no reason for the IETF to accept ASON as a
> requirement for MPLS/GMPLS.
> 
> Curtis


From owner-mpls@UU.NET  Mon Mar  3 14:35:46 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09243
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 14:35:46 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelq11115
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 19:37:44 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoelq09899;
	Mon, 3 Mar 2003 19:37:15 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoelq16596
	for mpls-outgoing; Mon, 3 Mar 2003 19:36:47 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoelq16580
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 19:36:32 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoelq11117
	for <mpls@UU.NET>; Mon, 3 Mar 2003 19:35:46 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelq07058
	for <mpls@UU.NET>; Mon, 3 Mar 2003 19:35:45 GMT
Received: from ihemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ihemail2.lucent.com [192.11.222.163])
	id QQoelq07041
	for <mpls@UU.NET>; Mon, 3 Mar 2003 19:35:45 GMT
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h23JZiN06958;
	Mon, 3 Mar 2003 14:35:44 -0500 (EST)
Received: from lucent.com (sjtrowbridge-1.dr.lucent.com [135.4.20.16]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id NAA06852; Mon, 3 Mar 2003 13:35:39 -0600 (CST)
Message-ID: <3E63AE89.42EFCFEB@lucent.com>
Date: Mon, 03 Mar 2003 12:35:37 -0700
From: Stephen Trowbridge <sjtrowbridge@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5  (Windows NT 5.0; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: curtis@fictitious.org
CC: "Ong, Lyndon" <LyOng@ciena.com>, "'Loa Andersson'" <loa@pi.se>,
        mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <200303031906.OAA80054@workhorse.fictitious.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Curtis,
I think that adding the branch is a big improvement, but I
don't like the value judgement implied by "Is this a good
idea?". Maybe a better phrase would be "Is this a good idea
within IETF's scope of work?". Other standards bodies don't work on
bad ideas either, but they do have different scopes of work that
they address. World Peace is a wonderful idea, but not really
within IETF's scope of work so we should send it to the UN instead.
Along the same lines, the target of the branch should be labeled
as "Send it to an SDO with a more appropriate scope", (and drop
the stuff about noise - noise for you may be signal within
somebody else's spectrum).
Regards,
Steve


Curtis Villamizar wrote:

> We should also add?
> 
>    +-------------+
>    |  Is this a  |
>    |  good idea? | --- YES --->  IETF process
>    +-------------+
>           |
>          NO!
>           |
>           V
>      Send it to the another
>      standard body to reduce
>      mailing list noise
> 
> That would be closer to current practice.  :-)
> 
> Curtis


From owner-mpls@UU.NET  Mon Mar  3 14:47:35 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09648
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 14:47:35 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelr05969
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 19:48:22 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoelr02883;
	Mon, 3 Mar 2003 19:46:59 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoelr17714
	for mpls-outgoing; Mon, 3 Mar 2003 19:46:32 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoelr17709
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 19:46:31 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoelr27319
	for <mpls@uu.net>; Mon, 3 Mar 2003 19:45:22 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelr05177
	for <mpls@uu.net>; Mon, 3 Mar 2003 19:45:21 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoelr05166
	for <mpls@uu.net>; Mon, 3 Mar 2003 19:45:21 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h23JjIJR011261
	for <mpls@uu.net>; Mon, 3 Mar 2003 14:45:19 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA00490 for <mpls@uu.net>; Mon, 3 Mar 2003 14:45:18 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h23JjIh22529 for mpls@uu.net; Mon, 3 Mar 2003 14:45:18 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoelq17132
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 19:43:01 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoelq08231
	for <mpls@UU.NET>; Mon, 3 Mar 2003 19:42:48 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelq01542
	for <mpls@UU.NET>; Mon, 3 Mar 2003 19:42:48 GMT
Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoelq01528
	for <mpls@UU.NET>; Mon, 3 Mar 2003 19:42:47 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA80247;
	Mon, 3 Mar 2003 14:40:49 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303031940.OAA80247@workhorse.fictitious.org>
To: "Elwyn Davies" <elwynd@nortelnetworks.com>
cc: "'Loa Andersson'" <loa@pi.se>,
        "Brungard, Deborah A,
    ALABS" <dbrungard@att.com>, mpls@UU.NET,
        "IETF problem (E-mail)" <problem-statement@alvestrand.no>
Reply-To: curtis@fictitious.org
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
In-reply-to: Your message of "Mon, 03 Mar 2003 18:39:35 GMT."
             <4103264BC8D3D51180B7002048400C4501623329@zhard0jd.europe.nortel.com> 
Date: Mon, 03 Mar 2003 14:40:49 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <4103264BC8D3D51180B7002048400C4501623329@zhard0jd.europe.nortel.com
>, "Elwyn Davies" writes:
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
> 
> ------_=_NextPart_001_01C2E1B4.3D0A6710
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> 
> Hi.
> 
> The problem-statement WG is only (nearly) chartered to document the
> perceived problems and attempt to find a set of root causes if possible.  We
> have published a first cut at the problems list
> (draft-ietf-problem-issue-statement-00, now available on the I-D site).  
> 
> Although there are a number of problems relating to external perception of
> the IETF, the liaison issue was not much talked about, possibly because the
> contributors were more focused on the internal problems. Accordingly it
> didn't have much of an effect on the root cause problem list - what is
> discussed is the IETF's problem with not clearly setting out its mission,
> and in particular the degree to which it wishes to emulate a more
> conventional SDO.  The problems with liaisons can be seen as a subsidiary
> symptom of this.
> 
> Anyway, the liaison problem (and the rest of the SDO relationships) has been
> forcibly brought to our attention and it looks like it should feature more
> prominently in the root cause problems.
> 
> As regards starting to solve it, Loa believes (G)MPLS needs a solution RSN;
> on the other hand, 'how to solve the general liaison problem' needs to be
> part of the direction which the 'solutions process' piece of our work will
> consider shortly, and it needs to be considerd in the general light of the
> IETF mission (whatever that turns out to be).
> 
> Regards,
> Elwyn Davies
> (editor of draft-ietf-problem-issue-statement)



By all means, move the liason discussion to whatever WG is discussing
problem-issue-statement or form a new WG and discuss the liason issue
there.  Discussion of changes in procedure that would transform the
IETF into something else definitely require a separate WG.

Curtis



From owner-mpls@UU.NET  Mon Mar  3 15:09:31 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10855
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 15:09:30 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoels10630
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 20:11:27 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoels08951;
	Mon, 3 Mar 2003 20:10:33 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoels09363
	for mpls-outgoing; Mon, 3 Mar 2003 20:10:09 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoels09218
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 20:09:55 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoels07802
	for <mpls@uu.net>; Mon, 3 Mar 2003 20:09:09 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoels15480
	for <mpls@uu.net>; Mon, 3 Mar 2003 20:09:07 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoels15471
	for <mpls@uu.net>; Mon, 3 Mar 2003 20:09:06 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h23K94JR013060
	for <mpls@uu.net>; Mon, 3 Mar 2003 15:09:04 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA02857 for <mpls@uu.net>; Mon, 3 Mar 2003 15:09:04 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h23K93t25910 for mpls@uu.net; Mon, 3 Mar 2003 15:09:03 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoels08895
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 20:07:54 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoels25778
	for <mpls@UU.NET>; Mon, 3 Mar 2003 20:07:30 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoels03596
	for <mpls@UU.NET>; Mon, 3 Mar 2003 20:07:30 GMT
Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoels03564
	for <mpls@UU.NET>; Mon, 3 Mar 2003 20:07:29 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA80585;
	Mon, 3 Mar 2003 15:05:19 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303032005.PAA80585@workhorse.fictitious.org>
To: Stephen Trowbridge <sjtrowbridge@lucent.com>
cc: curtis@fictitious.org, Loa Andersson <loa@pi.se>,
        "Varma,
    Eve L (Eve)" <evarma@lucent.com>,
        George Newsome <gnewsome@ieee.org>, mpls@UU.NET,
        ccamp <ccamp@ops.ietf.org>
Reply-To: curtis@fictitious.org
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
In-reply-to: Your message of "Mon, 03 Mar 2003 12:24:00 MST."
             <3E63ABD0.89B8FAA4@lucent.com> 
Date: Mon, 03 Mar 2003 15:05:19 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <3E63ABD0.89B8FAA4@lucent.com>, Stephen Trowbridge writes:
> Curtis,
> I think you are missing my point.
> 
> IETF has one set of requirements for the kinds of networks that they
> envision and are within their charter. They develop an architecture and
> protocol solutions to support those requirements.
> ITU-T has an (overlapping but different) set of requirements for the
> kinds of networks they envision (including lots of TDM & WDM traffic
> that doesn't necessarily carry IP, etc.).
> Nobody says that the additional ITU-T requirements are valid for
> the IETF application, or that IETF must solve the ITU-T requirements
> with IETF developed protocols (they can choose to, but there is no obligation
> ).
> 
> When the ITU-T brings these requirements to the IETF's attention, there
> are a variety of perfectly reasonable responses:
> - The IETF can say "That requirement is important for us also, let's work
>   toward a common solution".
> - The IETF can say "That requirement is not important for the IETF scope
>   of work, but we can see how it is important for yours. From our
>   experience with the protocol and our desire for sanity in the protocol
>   and all of its extensions, we can offer you the following advice about
>   how the protocol can best solve your problem ..."
> - The IETF can say "That requirement is not important for the IETF scope
>   of work and we are not particularly interested in helping with a solution -
>   you are on your own, but please assign any protocol codepoints through
>   IANA and document your extensions as an info RFC so that we can prevent
>   any conflict with other extensions.
> They could EVEN say "We think you might have misunderstood the requirements:
> do you think that the following restatement of the problem would allow your
> needs to be met with the current protocols: ..."
> 
> But the answer that I would have trouble with would be the IETF saying "That
> requirement is not important for the IETF scope of work, and therefore no
> solution should be developed for your problem AT ALL. After all, if it is not
> important for IETF, it must be irrelevant for everybody."
> 
> Of course, without a liaison process, I don't know how we get any of these
> responses. Incoming liaisons seem to hit the dustbin before they get serious
> consideration regarding which of the above response types might be most
> appropriate.
> Regards,
> Steve



Steve,

Lets consider what the IETF should do if it were 1985-1995 again and
the ITU or ATM Forum (1993 on) or Telco research personnel came to the
IETF and told them that connectionless protocols will never be
successful because there is no way to charge for them on a per packet
basis.  Should the IETF have changed the underlying IP model to be a
stateful connection oriented network and provide the AAA that ITU et
al insisted were absolute requirements.

Lets also consider what the IETF did do.  The IETF quietly ignored
those "outside requirements".  No official response came out of the
IESG or IETF.  No liason statement was sent to ITU.  The IETF simply
continued to go about their business ignoring an ITU requirement that
they collectively felt had no merit.

The IETF did not undertake a "connection oriented extension or
alternate transport to IP" in the 1990s.

I believe the same treatment would be appropriate for ASON today.  The
response "we do not agree with those requirements" would have been
entirely appropriate in the mid 1990s and is entirely appropriate now.

Curtis



From owner-mpls@UU.NET  Mon Mar  3 15:12:07 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11156
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 15:12:07 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoels23741
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 20:14:05 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoels20624;
	Mon, 3 Mar 2003 20:12:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoels10065
	for mpls-outgoing; Mon, 3 Mar 2003 20:11:59 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoels09950
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 20:11:39 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoels14440
	for <mpls@uu.net>; Mon, 3 Mar 2003 20:11:06 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoels14808
	for <mpls@uu.net>; Mon, 3 Mar 2003 20:11:05 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoels14796
	for <mpls@uu.net>; Mon, 3 Mar 2003 20:11:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h23KB3JR013254
	for <mpls@uu.net>; Mon, 3 Mar 2003 15:11:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA03085 for <mpls@uu.net>; Mon, 3 Mar 2003 15:11:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h23KB2u26017 for mpls@uu.net; Mon, 3 Mar 2003 15:11:02 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoels09217
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 20:09:52 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoels09510
	for <mpls@UU.NET>; Mon, 3 Mar 2003 20:09:31 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoels12508
	for <mpls@UU.NET>; Mon, 3 Mar 2003 20:09:30 GMT
Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoels12481
	for <mpls@UU.NET>; Mon, 3 Mar 2003 20:09:29 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA80708;
	Mon, 3 Mar 2003 15:07:35 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303032007.PAA80708@workhorse.fictitious.org>
To: Stephen Trowbridge <sjtrowbridge@lucent.com>
cc: curtis@fictitious.org, "Ong, Lyndon" <LyOng@ciena.com>,
        "'Loa Andersson'" <loa@pi.se>, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
In-reply-to: Your message of "Mon, 03 Mar 2003 12:35:37 MST."
             <3E63AE89.42EFCFEB@lucent.com> 
Date: Mon, 03 Mar 2003 15:07:35 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <3E63AE89.42EFCFEB@lucent.com>, Stephen Trowbridge writes:
> Curtis,
> I think that adding the branch is a big improvement, but I
> don't like the value judgement implied by "Is this a good
> idea?". Maybe a better phrase would be "Is this a good idea
> within IETF's scope of work?". Other standards bodies don't work on
> bad ideas either, but they do have different scopes of work that
> they address. World Peace is a wonderful idea, but not really
> within IETF's scope of work so we should send it to the UN instead.
> Along the same lines, the target of the branch should be labeled
> as "Send it to an SDO with a more appropriate scope", (and drop
> the stuff about noise - noise for you may be signal within
> somebody else's spectrum).
> Regards,
> Steve


I guess you never realized that "out of scope" was often a euphemism
for "bad idea", as in "That work was been determined to be 'out of scope'
therefore [form a new WG, go somewhere else, etc]."

Anyway, it is closer to current practice.  Authors also take their
work elsewhere when they are faced with objections in IETF, then try
to bring it back in with a liason statement.  Example: MPLS-OAM.

Curtis


> Curtis Villamizar wrote:
> 
> > We should also add?
> > 
> >    +-------------+
> >    |  Is this a  |
> >    |  good idea? | --- YES --->  IETF process
> >    +-------------+
> >           |
> >          NO!
> >           |
> >           V
> >      Send it to the another
> >      standard body to reduce
> >      mailing list noise
> > 
> > That would be closer to current practice.  :-)
> > 
> > Curtis



From owner-mpls@UU.NET  Mon Mar  3 16:55:55 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14360
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 16:55:55 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelz06451
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 21:57:55 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoelz05125;
	Mon, 3 Mar 2003 21:57:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoelz11391
	for mpls-outgoing; Mon, 3 Mar 2003 21:56:55 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoelz11374
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 21:56:35 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoelz07528
	for <mpls@UU.NET>; Mon, 3 Mar 2003 21:55:52 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoelz25981
	for <mpls@UU.NET>; Mon, 3 Mar 2003 21:55:51 GMT
Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQoelz25959
	for <mpls@UU.NET>; Mon, 3 Mar 2003 21:55:51 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h23LtoS17411;
	Mon, 3 Mar 2003 13:55:50 -0800 (PST)
	(envelope-from kireeti@juniper.net)
Received: from localhost (kireeti@localhost)
	by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h23LtnA51521;
	Mon, 3 Mar 2003 13:55:50 -0800 (PST)
	(envelope-from kireeti@juniper.net)
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
Date: Mon, 3 Mar 2003 13:55:49 -0800 (PST)
From: Kireeti Kompella <kireeti@juniper.net>
To: Genadi Velev <velev@panasonic.de>
cc: mpls@UU.NET, "" <ccamp@ops.ietf.org>
Subject: RE: draft-kawakami-mpls-lsp-vlan-00.txt
In-Reply-To: <NGBBJEAONDNLBFPCDEPPEEBFCGAA.velev@panasonic.de>
Message-ID: <20030303134655.Y51425@kummer.juniper.net>
References: <NGBBJEAONDNLBFPCDEPPEEBFCGAA.velev@panasonic.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Ganadi,

On Mon, 3 Mar 2003, Genadi Velev wrote:

> thanks for your clarification. You are right that this technology is a
> specific one, but OTOH as Dimitri pointed out it fits perfectly to the group
> of Layer-2 Switch Capable (L2SC) interfaces.

I agree that this applies to L2SC interfaces.  But CCAMP doesn't deal
with L2SC interfaces (it's not in the charter).

> I would like to ask you and Loa/George to help us to find the proper WG for
> the draft!

We'll talk to the ADs and let you know.

I understand that this may not be the answer you want; however,  In the
end, the IESG/IAB must decide what work items a particular WG can work
on.  Here, you are in the unfortunate position that there is no WG that
is chartered to do this work.

If you are going for an Informational document, things may be a bit
easier.

Kireeti.


From owner-mpls@UU.NET  Mon Mar  3 17:01:40 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14529
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 17:01:40 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoema20054
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 22:03:38 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoema18594;
	Mon, 3 Mar 2003 22:03:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoema24423
	for mpls-outgoing; Mon, 3 Mar 2003 22:02:35 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoema24351
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 22:02:34 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoema03785
	for <mpls@UU.NET>; Mon, 3 Mar 2003 22:02:24 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoema14539
	for <mpls@UU.NET>; Mon, 3 Mar 2003 22:02:23 GMT
Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQoema14521
	for <mpls@UU.NET>; Mon, 3 Mar 2003 22:02:22 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h23M2LS18083;
	Mon, 3 Mar 2003 14:02:21 -0800 (PST)
	(envelope-from kireeti@juniper.net)
Received: from localhost (kireeti@localhost)
	by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h23M2Ll51565;
	Mon, 3 Mar 2003 14:02:21 -0800 (PST)
	(envelope-from kireeti@juniper.net)
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
Date: Mon, 3 Mar 2003 14:02:21 -0800 (PST)
From: Kireeti Kompella <kireeti@juniper.net>
To: Stephen Trowbridge <sjtrowbridge@lucent.com>
cc: mpls@UU.NET, ccamp <ccamp@ops.ietf.org>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
In-Reply-To: <3E636D1C.456EC406@lucent.com>
Message-ID: <20030303135600.D51425@kummer.juniper.net>
References: <200302281703.MAA00661@bifocal.cisco.com> <3E636D1C.456EC406@lucent.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Steve,

On Mon, 3 Mar 2003, Stephen Trowbridge wrote:

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

Good idea.

> I think that liaison handling (or the lack thereof) is not just a
> problem. It is THE problem.

I disagree.  I think there are two problems, and both are important.

> 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?

Yes, actually, I do.  Maybe not "going wild", but the necessary
review is not always done to make sure the changes are needed and
in concert with the architecture of the 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.

No argument here.

> 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?

Every ID is a request from an individual.  Every ID is important
(until proven otherwise).

> Now, if we can agree that liaisons are THE problem,

We agree to disagree on that :-)

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

We (you and I) can do little (except write IDs :-)).  The ADs should
give us guidance on how to proceed.  And, from my reading, the
guidance is that the liaison problem should be solved holistically
(not piecemeal in Sub-IP) and in *some other WG*, like the problem
statement WG.

Kireeti.


From owner-mpls@UU.NET  Mon Mar  3 17:06:36 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14654
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 17:06:35 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoema01154
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 22:08:36 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoema29654;
	Mon, 3 Mar 2003 22:08:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoema00397
	for mpls-outgoing; Mon, 3 Mar 2003 22:07:32 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoema00379
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 22:07:25 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoema23601
	for <mpls@UU.NET>; Mon, 3 Mar 2003 22:07:15 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoema27918
	for <mpls@UU.NET>; Mon, 3 Mar 2003 22:07:01 GMT
Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQoema27855
	for <mpls@UU.NET>; Mon, 3 Mar 2003 22:07:00 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h23M6wS18369;
	Mon, 3 Mar 2003 14:06:58 -0800 (PST)
	(envelope-from kireeti@juniper.net)
Received: from localhost (kireeti@localhost)
	by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h23M6vT51584;
	Mon, 3 Mar 2003 14:06:57 -0800 (PST)
	(envelope-from kireeti@juniper.net)
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
Date: Mon, 3 Mar 2003 14:06:57 -0800 (PST)
From: Kireeti Kompella <kireeti@juniper.net>
To: "Brungard, Deborah A, ALABS" <dbrungard@att.com>
cc: Stephen Trowbridge <sjtrowbridge@lucent.com>,
        George Swallow <swallow@cisco.com>, "" <curtis@fictitious.org>,
        Loa Andersson <loa@pi.se>, "" <mpls@UU.NET>,
        ccamp <ccamp@ops.ietf.org>
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
In-Reply-To: <2FEC2C81634CDB4C9F191943ACCDC624079AA622@OCCLUST02EVS1.ugd.att.com>
Message-ID: <20030303140306.E51425@kummer.juniper.net>
References: <2FEC2C81634CDB4C9F191943ACCDC624079AA622@OCCLUST02EVS1.ugd.att.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Deborah,

On Mon, 3 Mar 2003, Brungard, Deborah A, ALABS wrote:

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

I didn't know that :-)  But nonetheless, it's a good idea -- it's a
starting point, and should give the IESG/IAB some fodder.

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

I'd be happy to help, and to work with Deborah, Steve and others.  One
thing I would request is to submit this ID to the problem statement WG,
and let them (or the IESG) redirect this as needed.

Kireeti.


From owner-mpls@UU.NET  Mon Mar  3 17:38:40 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15659
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 17:38:40 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemc14198
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 22:40:41 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoemc12526;
	Mon, 3 Mar 2003 22:40:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoemc03406
	for mpls-outgoing; Mon, 3 Mar 2003 22:39:37 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoemc03396
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 22:39:25 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoemc27860
	for <mpls@UU.NET>; Mon, 3 Mar 2003 22:38:29 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemc24515
	for <mpls@UU.NET>; Mon, 3 Mar 2003 22:38:29 GMT
Received: from zcars04f.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57])
	id QQoemc24508
	for <mpls@UU.NET>; Mon, 3 Mar 2003 22:38:28 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h23McDU04544;
	Mon, 3 Mar 2003 17:38:13 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <GDF4SLZY>; Mon, 3 Mar 2003 17:38:14 -0500
Message-ID: <710197BD5AF9D4119E4400508BCFA1360438152F@zcard04u.ca.nortel.com>
From: "Malcolm Betts" <betts01@nortelnetworks.com>
To: "'Kireeti Kompella'" <kireeti@juniper.net>,
        Stephen Trowbridge
	 <sjtrowbridge@lucent.com>
Cc: mpls@UU.NET, ccamp <ccamp@ops.ietf.org>
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Mon, 3 Mar 2003 17:38:12 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2E1D3.B6CDA638"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2E1D3.B6CDA638
Content-Type: text/plain

Kireeti, if we can agree that we have two problems and from the perspective
of an external SDO they are closely coupled.  One way of moving forward
would be to develop two IDs in parallel.  The first based on the existing
anderson-mpls-g-change-proc, modified to state explicitly that requests for
changes by external SDOs are exempt from this process.  The second draft
would address the liaison process.  The key issue with changes requested by
external SDOs is that in general they will be based on the desire to apply
(G)MPLS protocols to connection management of connection oriented circuit
switched (COCS) networks for the benefit of COCS clients - i.e. to
applications that are well outside the "normal" IETF problem space. To keep
the activity  focussed (as suggested in some earlier emails) perhaps we
could limit the scope to the sub ip area only (at least initially).  I think
that Steve Trowbridge in an earlier email (copy below) provided a good
summary of the objectives of the liaison process.


-----Original Message-----
From: Kireeti Kompella [mailto:kireeti@juniper.net] 
Sent: Monday, March 03, 2003 5:02 PM
To: Stephen Trowbridge
Cc: mpls@UU.NET; ccamp
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt


Hi Steve,

On Mon, 3 Mar 2003, Stephen Trowbridge wrote:

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

Good idea.

> I think that liaison handling (or the lack thereof) is not just a 
> problem. It is THE problem.

I disagree.  I think there are two problems, and both are important.

<snip>

<insert for Steve Trowbridge>

IETF has one set of requirements for the kinds of networks that they
envision and are within their charter. They develop an architecture and
protocol solutions to support those requirements. ITU-T has an (overlapping
but different) set of requirements for the kinds of networks they envision
(including lots of TDM & WDM traffic that doesn't necessarily carry IP,
etc.). Nobody says that the additional ITU-T requirements are valid for the
IETF application, or that IETF must solve the ITU-T requirements with IETF
developed protocols (they can choose to, but there is no obligation).

When the ITU-T brings these requirements to the IETF's attention, there are
a variety of perfectly reasonable responses:
- The IETF can say "That requirement is important for us also, let's work
  toward a common solution".
- The IETF can say "That requirement is not important for the IETF scope
  of work, but we can see how it is important for yours. From our
  experience with the protocol and our desire for sanity in the protocol
  and all of its extensions, we can offer you the following advice about
  how the protocol can best solve your problem ..."
- The IETF can say "That requirement is not important for the IETF scope
  of work and we are not particularly interested in helping with a solution
-
  you are on your own, but please assign any protocol codepoints through
  IANA and document your extensions as an info RFC so that we can prevent
  any conflict with other extensions.
They could EVEN say "We think you might have misunderstood the requirements:
do you think that the following restatement of the problem would allow your
needs to be met with the current protocols: ..."

But the answer that I would have trouble with would be the IETF saying "That
requirement is not important for the IETF scope of work, and therefore no
solution should be developed for your problem AT ALL. After all, if it is
not important for IETF, it must be irrelevant for everybody."

Of course, without a liaison process, I don't know how we get any of these
responses. Incoming liaisons seem to hit the dustbin before they get serious
consideration regarding which of the above response types might be most
appropriate. Regards, Steve

<end inserted text>

Malcolm Betts

Phone: +1 613 763 7860 (ESN 393)
FAX:   +1 613 763 6608 (ESN 393)
email: betts01@nortelnetworks.com

------_=_NextPart_001_01C2E1D3.B6CDA638
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Kireeti, if we can agree that we have two problems =
and from the perspective of an external SDO they are closely =
coupled.&nbsp; One way of moving forward would be to develop two IDs in =
parallel.&nbsp; The first based on the existing =
anderson-mpls-g-change-proc, modified to state explicitly that requests =
for changes by external SDOs are exempt from this process.&nbsp; The =
second draft would address the liaison process.&nbsp; The key issue =
with changes requested by external SDOs is that in general they will be =
based on the desire to apply (G)MPLS protocols to connection management =
of connection oriented circuit switched (COCS) networks for the benefit =
of COCS clients - i.e. to applications that are well outside the =
&quot;normal&quot; IETF problem space. To keep the activity&nbsp; =
focussed (as suggested in some earlier emails) perhaps we could limit =
the scope to the sub ip area only (at least initially).&nbsp; I think =
that Steve Trowbridge in an earlier email (copy below) provided a good =
summary of the objectives of the liaison process.</FONT></P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Kireeti Kompella [<A =
HREF=3D"mailto:kireeti@juniper.net">mailto:kireeti@juniper.net</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, March 03, 2003 5:02 PM</FONT>
<BR><FONT SIZE=3D2>To: Stephen Trowbridge</FONT>
<BR><FONT SIZE=3D2>Cc: mpls@UU.NET; ccamp</FONT>
<BR><FONT SIZE=3D2>Subject: Re: I-D =
ACTION:draft-andersson-mpls-g-chng-proc-00.txt</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi Steve,</FONT>
</P>

<P><FONT SIZE=3D2>On Mon, 3 Mar 2003, Stephen Trowbridge wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Lets try to zero in on what the problem really =
is.</FONT>
</P>

<P><FONT SIZE=3D2>Good idea.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; I think that liaison handling (or the lack =
thereof) is not just a </FONT>
<BR><FONT SIZE=3D2>&gt; problem. It is THE problem.</FONT>
</P>

<P><FONT SIZE=3D2>I disagree.&nbsp; I think there are two problems, and =
both are important.</FONT>
</P>

<P><FONT SIZE=3D2>&lt;snip&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&lt;insert for Steve Trowbridge&gt;</FONT>
</P>

<P><FONT SIZE=3D2>IETF has one set of requirements for the kinds of =
networks that they envision and are within their charter. They develop =
an architecture and protocol solutions to support those requirements. =
ITU-T has an (overlapping but different) set of requirements for the =
kinds of networks they envision (including lots of TDM &amp; WDM =
traffic that doesn't necessarily carry IP, etc.). Nobody says that the =
additional ITU-T requirements are valid for the IETF application, or =
that IETF must solve the ITU-T requirements with IETF developed =
protocols (they can choose to, but there is no obligation).</FONT></P>

<P><FONT SIZE=3D2>When the ITU-T brings these requirements to the =
IETF's attention, there are a variety of perfectly reasonable =
responses:</FONT></P>

<P><FONT SIZE=3D2>- The IETF can say &quot;That requirement is =
important for us also, let's work</FONT>
<BR><FONT SIZE=3D2>&nbsp; toward a common solution&quot;.</FONT>
<BR><FONT SIZE=3D2>- The IETF can say &quot;That requirement is not =
important for the IETF scope</FONT>
<BR><FONT SIZE=3D2>&nbsp; of work, but we can see how it is important =
for yours. From our</FONT>
<BR><FONT SIZE=3D2>&nbsp; experience with the protocol and our desire =
for sanity in the protocol</FONT>
<BR><FONT SIZE=3D2>&nbsp; and all of its extensions, we can offer you =
the following advice about</FONT>
<BR><FONT SIZE=3D2>&nbsp; how the protocol can best solve your problem =
...&quot;</FONT>
<BR><FONT SIZE=3D2>- The IETF can say &quot;That requirement is not =
important for the IETF scope</FONT>
<BR><FONT SIZE=3D2>&nbsp; of work and we are not particularly =
interested in helping with a solution -</FONT>
<BR><FONT SIZE=3D2>&nbsp; you are on your own, but please assign any =
protocol codepoints through</FONT>
<BR><FONT SIZE=3D2>&nbsp; IANA and document your extensions as an info =
RFC so that we can prevent</FONT>
<BR><FONT SIZE=3D2>&nbsp; any conflict with other extensions.</FONT>
<BR><FONT SIZE=3D2>They could EVEN say &quot;We think you might have =
misunderstood the requirements: do you think that the following =
restatement of the problem would allow your needs to be met with the =
current protocols: ...&quot;</FONT></P>

<P><FONT SIZE=3D2>But the answer that I would have trouble with would =
be the IETF saying &quot;That requirement is not important for the IETF =
scope of work, and therefore no solution should be developed for your =
problem AT ALL. After all, if it is not important for IETF, it must be =
irrelevant for everybody.&quot;</FONT></P>

<P><FONT SIZE=3D2>Of course, without a liaison process, I don't know =
how we get any of these responses. Incoming liaisons seem to hit the =
dustbin before they get serious consideration regarding which of the =
above response types might be most appropriate. Regards, =
Steve</FONT></P>

<P><FONT SIZE=3D2>&lt;end inserted text&gt;</FONT>
</P>

<P><FONT SIZE=3D2>Malcolm Betts</FONT>
</P>

<P><FONT SIZE=3D2>Phone: +1 613 763 7860 (ESN 393)</FONT>
<BR><FONT SIZE=3D2>FAX:&nbsp;&nbsp; +1 613 763 6608 (ESN 393)</FONT>
<BR><FONT SIZE=3D2>email: betts01@nortelnetworks.com</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2E1D3.B6CDA638--


From owner-mpls@UU.NET  Mon Mar  3 17:54:55 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16261
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 17:54:55 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemd03879
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 22:56:53 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoemd02700;
	Mon, 3 Mar 2003 22:56:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoemd04896
	for mpls-outgoing; Mon, 3 Mar 2003 22:55:57 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoemd04889
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 22:55:53 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoemd19247
	for <mpls@UU.NET>; Mon, 3 Mar 2003 22:55:47 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemd08230
	for <mpls@UU.NET>; Mon, 3 Mar 2003 22:55:46 GMT
Received: from mailf.telia.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailf.telia.com [194.22.194.25])
	id QQoemd08215
	for <mpls@UU.NET>; Mon, 3 Mar 2003 22:55:45 GMT
Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241])
	by mailf.telia.com (8.12.5/8.12.5) with ESMTP id h23Mtfb6027914;
	Mon, 3 Mar 2003 23:55:41 +0100 (CET)
X-Original-Recipient: mpls@UU.NET
Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45])
	by d1o888.telia.com (8.10.2/8.10.1) with ESMTP id h23Mte228039;
	Mon, 3 Mar 2003 23:55:41 +0100 (CET)
Message-ID: <3E63DC55.4080206@pi.se>
Date: Mon, 03 Mar 2003 23:51:01 +0100
From: Loa Andersson <loa@pi.se>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Scott Bradner <sob@harvard.edu>
CC: dbrungard@att.com, mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <200303031758.h23HwuI9004544@newdev.harvard.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

All,

I guess that this is equal to an AD shaking his head to doing a SUb-IP 
pilot
liasion process :)

OK - two documents, the change process within Sub-Ip and the liasion 
process
IETF wide, is that it?

/Loa


Scott Bradner wrote:

>>I think there could be an agreement along those lines
>>
>>- one draft that specifies the change-process
>>- one draft that specifies the liasion process
>>    
>>
>
>note that the liasion process discussion is not SUB-IP specific,
>the same issues come up in transport and elsewhere - so that doc
>needs more thinking
>
>it is a topic that I'm quite interested in and would be wiling to
>work on if others thought it would help
>
>Scott
>
>
>  
>




From owner-mpls@UU.NET  Mon Mar  3 18:02:50 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16538
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 18:02:50 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeme16680
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 23:04:47 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeme15331;
	Mon, 3 Mar 2003 23:04:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeme19278
	for mpls-outgoing; Mon, 3 Mar 2003 23:03:41 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoeme18033
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 23:03:31 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoeme09877
	for <mpls@UU.NET>; Mon, 3 Mar 2003 23:01:55 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeme14514
	for <mpls@UU.NET>; Mon, 3 Mar 2003 23:01:55 GMT
Received: from mailb.telia.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailb.telia.com [194.22.194.6])
	id QQoeme14494
	for <mpls@UU.NET>; Mon, 3 Mar 2003 23:01:53 GMT
Received: from d1o888.telia.com (d1o888.telia.com [213.67.172.241])
	by mailb.telia.com (8.12.5/8.12.5) with ESMTP id h23N1mLU007957;
	Tue, 4 Mar 2003 00:01:48 +0100 (CET)
X-Original-Recipient: mpls@UU.NET
Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45])
	by d1o888.telia.com (8.10.2/8.10.1) with ESMTP id h23N1l229865;
	Tue, 4 Mar 2003 00:01:48 +0100 (CET)
Message-ID: <3E63DDC9.9030803@pi.se>
Date: Mon, 03 Mar 2003 23:57:13 +0100
From: Loa Andersson <loa@pi.se>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Ong, Lyndon" <LyOng@ciena.com>
CC: mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <2135200C183FD5119588009027DE572302836D78@webdev-owa.oni.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Lyndon,

inline please!

/Loa

Ong, Lyndon wrote:

>Hi Loa,
>
>Sorry my comments were not as clear as could have been:
>
>-- on the diagram, there should be a path leading away from
>IETF activity (and perhaps looping back) when it is decided
>that the work should be done outside IETF.  Figure this is
>different from "dustbin" :o)
>
shouldn't be a problem, i'll fix it

>
>-- on the mailing lists, the current text is ambiguous as
>to what specific group is addressed:
>  "The mailing list to use should be the Area
>   mailing list for the area that the working group that has specified
>   the protocol being changed and that will likely be the requirement
>   evaluation working group."
>
reason write it this way was to cover siutations where the working group
has be closed, this should work anyway because there is always a
guardian AD, with an aea list

>
>I wonder in fact if it should be the mailing list for the group 
>dealing with the affected protocol, since that's where you'll
>get people's attention.
>
>-- on the "loophole", my thought was that if someone or group brings
>in a proposal, a WG may volunteer to address it but not actually 
>have time on its agenda, and thought there should be some way to
>appeal or raise the issue if nothing is getting done. Since the 
>procedure otherwise is designed to limit the alternatives once it
>has been assigned within IETF, some counterbalance seems needed.
>
I think that wg will try to limit what they bring in to be within charter,
if they don't ADs will ;), so bringing something in will take a commitment
by people doing it, this should be espcially true if that work originates
in another SDO where it has a huge backing

/Loa

>
>Thanks,
>
>Lyndon
>
>
>-----Original Message-----
>From: Loa Andersson [mailto:loa@pi.se]
>Sent: Saturday, March 01, 2003 7:36 AM
>To: Ong, Lyndon
>Cc: mpls@UU.NET
>Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
>
>Lyndon,
>
>thanks - it looks like we are making progress - some questions/inline.
>
>Ong, Lyndon wrote:
>
>  
>
>>Hi Folks,
>>
>>I support the request to stick to constructive comments.
>>
>>Of course that means avoiding statements like "The
>>ITU has stepped out of bounds (again).  They deserve to be ignored."
>>(Last I heard, SDH/OTN networks were within bounds of ITU ;o)
>>
>>Or "dogmatic statements of connection-oriented  religion" (these
>>are, for gmpls, connection-oriented networks we're talking about ;0)
>>
>>Seriously, though, I do have some comments on the draft:
>>
>>-- the figure shows the only path outside of the IETF process to
>>be a dustbin.  Hopefully that's not intentional, although a lot
>>of folks on the list probably believe this ;o)
>>
>>    
>>
>could you specify which path(s)
>
>  
>
>>-- there's some text mixed up in 2.2.1 regarding which mailing list
>>should be used.
>>
>>    
>>
>specific please - I intended to say the area list of the wg that 
>specified the protocol,
>can't see the mix up
>
>  
>
>>-- we should incorporate Deborah's suggestion for 2.2.2 about having
>>the decision posted to the mailing list within a specified period  (the
>>posting of a decision could apply to liaisons, and might have helped
>>avoid the confusion with the ITU liaison)
>>
>>    
>>
>I clearly sympatize with this, but since all decisions in the change
>process are taken by I*, with the exception of the initial of being
>where ADs and wg chairs, decides on whether to request chartiering the
>req evaluation, are controlled by the I*, I think it is outside scope of
>draft to specify how and when. It has been my assumption that this is
>within the I* domain
>
>  
>
>>-- in 2.2.4, the paragraph after item (2) seems a little premature - 
>>the recommendation by the rewg presumably must be approved by IESG/IAB
>>before a decision is made.
>>
>>    
>>
>OK, can see this - would this be feasible
>
>   If IESG/IAB approves of a recommendation according to cases 1 & 2 the 
>   IETF will not publish an RFC that attempts to get around the decision.
>
>I complicates the flow chart a bit, but will be manageable, I can always
>ask Bala to help ;)
>
>  
>
>>-- there is a bit of a loophole in that the problem could be accepted
>>and farmed off to a WG but there's no check to see if anything is ever
>>done, and items could easily fall through a crack given the large 
>>numbers of work items usually in CCAMP and MPLS.  There could be a 
>>procedure to revisit the decision in case no progress is being made
>>within some specified timeframe.
>>
>>    
>>
>no I htink tht this is not a loop hole - there is no way ever where you can
>"farm a problem out" and expect the wg to do your job for you,  ti requires
>youra active participation, IETF  is a community of co-workers not an
>agency that takes assignments - every time you bring something in to the
>IETF youd don't say "Here is something YOU should do while I go about 
>minding
>my own business", instead you should say "Here is something I think WE 
>should do".
>
>  
>
>>-- in general, I hope people keep in mind that the scope of interest
>>and the resources available in IETF are limited, and should not become a
>>bottleneck - if work can be or is already being done in other bodies and 
>>there is a process for IETF to review this work and identify potential
>>problems or simpler/more general ways to do the desired function,
>>this should be viewed as a generally positive thing.
>>
>>    
>>
>
>agreed - that is why all the 4 bullets were insluded, and yes I agree as
>long as the architecural issues and the safe guarding of opertional aspects
>the Inernet are respected, but on the other hand bringing something to the
>IETF and not being prepared to work on it is likely to create a "bottleneck"
>
>  
>
>>Cheers,
>>
>>Lyndon
>>
>>
>>
>>    
>>
>
>
>
>
>  
>




From owner-mpls@UU.NET  Mon Mar  3 18:57:50 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18682
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 18:57:50 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemh16344
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 23:59:51 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoemh16258;
	Mon, 3 Mar 2003 23:59:47 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoemg26366
	for mpls-outgoing; Mon, 3 Mar 2003 23:34:02 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoemg26358
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 23:34:00 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoemg13275
	for <mpls@uu.net>; Mon, 3 Mar 2003 23:32:06 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemg15491
	for <mpls@uu.net>; Mon, 3 Mar 2003 23:32:05 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoemg15480
	for <mpls@uu.net>; Mon, 3 Mar 2003 23:32:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h23NW2Nh026558
	for <mpls@uu.net>; Mon, 3 Mar 2003 18:32:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA18410 for <mpls@uu.net>; Mon, 3 Mar 2003 18:32:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h23NW2u14536 for mpls@uu.net; Mon, 3 Mar 2003 18:32:02 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoemg26065
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 23:30:16 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoemg05473
	for <mpls@UU.NET>; Mon, 3 Mar 2003 23:30:07 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemg13544
	for <mpls@UU.NET>; Mon, 3 Mar 2003 23:30:04 GMT
Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoemg13521
	for <mpls@UU.NET>; Mon, 3 Mar 2003 23:30:04 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id SAA84398;
	Mon, 3 Mar 2003 18:28:03 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303032328.SAA84398@workhorse.fictitious.org>
To: "Malcolm Betts" <betts01@nortelnetworks.com>
cc: "'Kireeti Kompella'" <kireeti@juniper.net>,
        Stephen Trowbridge <sjtrowbridge@lucent.com>, mpls@UU.NET,
        ccamp <ccamp@ops.ietf.org>
Reply-To: curtis@fictitious.org
Subject: Re: {Possible Spam} RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
In-reply-to: Your message of "Mon, 03 Mar 2003 17:38:12 EST."
             <710197BD5AF9D4119E4400508BCFA1360438152F@zcard04u.ca.nortel.com> 
Date: Mon, 03 Mar 2003 18:28:03 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <710197BD5AF9D4119E4400508BCFA1360438152F@zcard04u.ca.nortel.com>, "
Malcolm Betts" writes:
> 
> Kireeti, if we can agree that we have two problems and from the perspective
> of an external SDO they are closely coupled.  One way of moving forward
> would be to develop two IDs in parallel.  The first based on the existing
> anderson-mpls-g-change-proc, modified to state explicitly that requests for
> changes by external SDOs are exempt from this process.  The second draft
> would address the liaison process.  The key issue with changes requested by
> external SDOs is that in general they will be based on the desire to apply
> (G)MPLS protocols to connection management of connection oriented circuit
> switched (COCS) networks for the benefit of COCS clients - i.e. to
> applications that are well outside the "normal" IETF problem space. To keep
> the activity  focussed (as suggested in some earlier emails) perhaps we
> could limit the scope to the sub ip area only (at least initially).  I think
> that Steve Trowbridge in an earlier email (copy below) provided a good
> summary of the objectives of the liaison process.


This is just fine except there is no concensus either way on Steve's
opinion that the role of liasons should be changed.  Kireeti already
told you and he have to agree to disagree on this.

Therefore Loa's draft should not mention exclusion of liasons, because
changing the liason relationship is not the current intent, and
because the liason relationship will be addressed separately as
suggested by Scott Bradner.

The role of liasons can be addressed separately on another list.

Curtis



From owner-mpls@UU.NET  Mon Mar  3 19:15:27 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19045
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 19:15:27 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemj07030
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 00:17:29 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoemj06923;
	Tue, 4 Mar 2003 00:17:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoemh28105
	for mpls-outgoing; Mon, 3 Mar 2003 23:51:44 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoemh28093
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 23:51:29 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoemh01117
	for <mpls@uu.net>; Mon, 3 Mar 2003 23:50:55 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemh17287
	for <mpls@uu.net>; Mon, 3 Mar 2003 23:50:54 GMT
Received: from lightwave.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: lightwave.chromisys.com [63.102.55.206])
	id QQoemh17243
	for <mpls@uu.net>; Mon, 3 Mar 2003 23:50:53 GMT
Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19)
	id <4GJZGMHW>; Mon, 3 Mar 2003 15:50:48 -0800
Message-ID: <9D42C6E086250248810DCADA39CE7EFC97228E@nimbus>
From: John Drake <jdrake@calient.net>
To: "'Zhi-Wei Lin'" <zhiweilin@yahoo.com>, mpls@UU.NET
Subject: RE: FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
Date: Mon, 3 Mar 2003 15:50:44 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2E1DF.B4C4ACE0"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2E1DF.B4C4ACE0
Content-Type: text/plain;
	charset="iso-8859-1"

Zhi,
 
Just to be clear, I consider call/connection separation to be a solution,
not a requirement.  The requirements that I've heard that call/connection
separation is claimed to address are the following:
 
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.) 
 
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.)
 
Keeping track of the circuits in a virtual concatenation group.  (I think
this is covered with the SDH/SONET signalling draft.)
 
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.
 
Thanks,
 
John
 
-----Original Message-----
From: Zhi-Wei Lin [mailto:zhiweilin@yahoo.com]
Sent: Sunday, March 02, 2003 11:21 AM
To: mpls@uu.net
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 



 From: John Drake [mailto:jdrake@calient.net]
Sent: Friday, February 28, 2003 4:15 PM
To: 'erosen@cisco.com'; Varma, Eve L (Eve)
Cc: 'curtis@fictitious.org'; George Newsome; Stephen Trowbridge; Loa
Andersson; mpls@UU.NET
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:erosen@cisco.com]
> Sent: Friday, February 28, 2003 12:54 PM
> To: Varma, Eve L (Eve)
> Cc: 'curtis@fictitious.org'; George Newsome; Stephen Trowbridge; Loa
> Andersson; mpls@UU.NET
> 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!  <http://rd.yahoo.com/finance/mailtagline/*http://taxes.yahoo.com/>
Tax Center - forms, calculators, tips, and more


------_=_NextPart_001_01C2E1DF.B4C4ACE0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.50.4807.2300" name=GENERATOR></HEAD>
<BODY>
<DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
size=2><SPAN class=125442523-03032003>Zhi,</SPAN></FONT></FONT></DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
size=2><SPAN class=125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
size=2><SPAN class=125442523-03032003>Just to be clear, I consider 
call/connection separation to be a solution, not a requirement.&nbsp; The 
requirements that I've heard that call/connection separation is claimed to 
address are the following:</SPAN></FONT></FONT></DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
size=2><SPAN class=125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
size=2><SPAN class=125442523-03032003>Keeping a&nbsp;connection alive while 
attempting to reroute it after outage.&nbsp; (This is basic RSVP and&nbsp; MBB 
allows you to reuse links on the failed path.)&nbsp;</SPAN></FONT></FONT><FONT 
face=Tahoma><FONT size=2><SPAN 
class=125442523-03032003></SPAN></FONT></FONT></DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
size=2><SPAN class=125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
size=2><SPAN class=125442523-03032003>Establishing a new path for an existing 
</SPAN>c<SPAN class=125442523-03032003>onnection so that </SPAN>l<SPAN 
class=125442523-03032003>inks along its&nbsp;current path may be taken out of 
service for maintenance</SPAN>.<SPAN class=125442523-03032003>&nbsp; (This 
sounds like a definition of MBB.)</SPAN></FONT></FONT></DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
size=2><SPAN class=125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
size=2><SPAN class=125442523-03032003></SPAN></FONT></FONT><FONT 
face=Tahoma><FONT size=2><SPAN class=125442523-03032003>Keeping track of the 
circuits in a virtual concatenation group.&nbsp; (I think this is covered with 
the SDH/SONET signalling draft.)</SPAN></FONT></FONT></DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
size=2><SPAN class=125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
size=2><SPAN class=125442523-03032003>The other requirement I've heard is&nbsp;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.</SPAN></FONT></FONT></DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
size=2><SPAN class=125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
size=2><SPAN class=125442523-03032003>Thanks,</SPAN></FONT></FONT></DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
size=2><SPAN class=125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
size=2><SPAN class=125442523-03032003>John</SPAN></FONT></FONT></DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
size=2><SPAN class=125442523-03032003>&nbsp;</SPAN></FONT></FONT></DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
size=2>-----Original Message-----<BR><B>From:</B> Zhi-Wei Lin 
[mailto:zhiweilin@yahoo.com]<BR><B>Sent:</B> Sunday, March 02, 2003 11:21 
AM<BR><B>To:</B> mpls@uu.net<BR><B>Cc:</B> John Drake<BR><B>Subject:</B> Re: FW: 
I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt <BR><BR></FONT></DIV></DIV>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
  <P>Hi John, 
  <P>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? 
  <P>Thanks<BR>Zhi 
  <P> 
  <P>&nbsp;From: John Drake [mailto:jdrake@calient.net]<BR>Sent: Friday, 
  February 28, 2003 4:15 PM<BR>To: 'erosen@cisco.com'; Varma, Eve L (Eve)<BR>Cc: 
  'curtis@fictitious.org'; George Newsome; Stephen Trowbridge; Loa<BR>Andersson; 
  mpls@UU.NET<BR>Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
  <BR><BR><BR>I agree with Eric.<BR><BR>As an example, we have call/connection 
  separation, which has been kicking<BR>around since the early days of ISDN. In 
  discussions as to why it is needed,<BR>the first reason is always "because". 
  Once past that, I have consistently<BR>heard four or five examples cited. What 
  is interesting is that all of them<BR>can be handled with the existing Make 
  Before Break component of RSVP-TE. <BR><BR>Thanks,<BR><BR>John<BR><BR>&gt; 
  -----Original Message-----<BR>&gt; From: Eric Rosen 
  [mailto:erosen@cisco.com]<BR>&gt; Sent: Friday, February 28, 2003 12:54 
  PM<BR>&gt; To: Varma, Eve L (Eve)<BR>&gt; Cc: 'curtis@fictitious.org'; George 
  Newsome; Stephen Trowbridge; Loa<BR>&gt; Andersson; mpls@UU.NET<BR>&gt; 
  Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt <BR>&gt; 
  <BR>&gt; <BR>&gt; <BR>&gt; Eve&gt; For individual contributor drafts coming 
  in, it's quite <BR>&gt; appropriate to<BR>&gt; Eve&gt; evaluate requirements 
  and determine if they are <BR>&gt; legitimate. It's a<BR>&gt; Eve&gt; 
  different case when another SDO, responsible for a <BR>&gt; non-IP 
  applications<BR>&gt; Eve&gt; domain, has established a set of requirements 
  related to <BR>&gt; that domain.<BR>&gt; <BR>&gt; I'd certainly disagree with 
  that. Many of the <BR>&gt; "requirements" I see from<BR>&gt; other 
  organizations are not requirements at all, but <BR>&gt; just dogmatic<BR>&gt; 
  statements of connection-oriented religion. If the IETF <BR>&gt; were to 
  accept<BR>&gt; requirements from other organizations, it would quickly be 
  <BR>&gt; inundated with<BR>&gt; "requirements" to make IP behave exactly like 
  ATM. In <BR>&gt; fact, anyone who<BR>&gt; works in the PWE3 group can testify 
  that such "requirements" <BR>&gt; come in all the<BR>&gt; time. <BR>&gt; 
  <BR>&gt; <BR>&gt; </P>
  <P><BR>
  <HR SIZE=1>
  Do you Yahoo!?<BR><A 
  href="http://rd.yahoo.com/finance/mailtagline/*http://taxes.yahoo.com/">Yahoo! 
  Tax Center</A> - forms, calculators, tips, and more</BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C2E1DF.B4C4ACE0--


From owner-mpls@UU.NET  Mon Mar  3 19:33:09 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19342
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 19:33:09 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemb20734
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 22:22:23 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoemb19909;
	Mon, 3 Mar 2003 22:22:03 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoemb02274
	for mpls-outgoing; Mon, 3 Mar 2003 22:21:36 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoemb02267
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 22:21:19 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoemb03510
	for <mpls@UU.NET>; Mon, 3 Mar 2003 22:20:10 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemb27152
	for <mpls@UU.NET>; Mon, 3 Mar 2003 22:20:10 GMT
Received: from mx.pccwbtn.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mx.pccwbtn.com [63.216.0.99])
	id QQoemb27144
	for <mpls@UU.NET>; Mon, 3 Mar 2003 22:20:09 GMT
Received: from rod ([63.217.151.226])
	(authenticated bits=0)
	by mx.pccwbtn.com (8.12.3/8.12.3) with ESMTP id h23MK95I053101
	for <mpls@UU.NET>; Mon, 3 Mar 2003 17:20:09 -0500 (EST)
	(envelope-from rmartin@btnusa.com)
Reply-To: <rmartin@btnusa.com>
From: "Rod Martin" <rmartin@btnusa.com>
To: <mpls@UU.NET>
Subject: Cisco VPLS support
Date: Mon, 3 Mar 2003 17:21:36 -0500
Message-ID: <PLEHKMIEDLNMFFDJBGMBAEFECEAA.rmartin@btnusa.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Wondering if anyone has configured an target LDP session using Cisco
routers?  I am looking for a performance evaluation.

Thanks



ROD L. MARTIN
CCDP, CFE, JNCIS, CFOE
(MOBILE) 703-967-9506
http://www.juniper.net
http://www.mplsvpn.net


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.459 / Virus Database: 258 - Release Date: 2/25/2003



From owner-mpls@UU.NET  Mon Mar  3 19:33:33 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19365
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 19:33:33 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemk21462
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 00:35:25 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoemk21276;
	Tue, 4 Mar 2003 00:35:18 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoemi16688
	for mpls-outgoing; Tue, 4 Mar 2003 00:09:27 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoemi16679
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 00:09:10 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoemi12943
	for <mpls@UU.NET>; Tue, 4 Mar 2003 00:08:53 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemi19688
	for <mpls@UU.NET>; Tue, 4 Mar 2003 00:08:53 GMT
Received: from smtp.comcast.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp.comcast.net [24.153.64.2])
	id QQoemi19681
	for <mpls@UU.NET>; Tue, 4 Mar 2003 00:08:53 GMT
Received: from LINPORTEGE
 (pcp03191818pcs.midltn01.nj.comcast.net [68.36.136.113])
 by mtaout07.icomcast.net
 (iPlanet Messaging Server 5.2 HotFix 1.09 (built Jan  7 2003))
 with SMTP id <0HB7007RE71ZNU@mtaout07.icomcast.net> for mpls@UU.NET; Mon,
 03 Mar 2003 19:08:23 -0500 (EST)
Date: Mon, 03 Mar 2003 19:08:12 -0500
From: Zhi-Wei Lin <zwlin@comcast.net>
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
In-reply-to: <20030303140750.W51425@kummer.juniper.net>
To: "'Kireeti Kompella'" <kireeti@juniper.net>,
        "'Stephen Trowbridge'" <sjtrowbridge@lucent.com>
Cc: ccamp@ops.ietf.org, mpls@UU.NET
Message-id: <004601c2e1e2$25a90e90$6e00a8c0@na01.lucent.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7BIT

Hi Kireeti,

Just responding to your point (e) below. As someone pointed out in some
previous email exchanges (seems like an age ago), when I submitted my I-D
around the June timeframe, the IETF CCAMP WG were not particularly
interested. However, I did work with and gotten quite good feedback
privately. Among the folks were Adrian, Jerry, Dimitrios, Dimitri, Nick,
Greg, Lyndon, Bala, Yangguang. Of course not everyone agreed with some of
the particular solution but I don't think anyone questioned that there were
technical issues with it...

And also as someone pointed out, many of the critical players in the GMPLS
arena were also players in the OIF. I think the root cause is maybe not the
liaison process but the intent of people working in the topic area? Just a
guess...

Thanks
Zhi



> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Kireeti
> Kompella
> Sent: Monday, March 03, 2003 5:26 PM
> To: Stephen Trowbridge
> Cc: ccamp@ops.ietf.org; mpls@UU.NET
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
>
> 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.
>
> That said, if liaisons truly have lower priority than individual IDs,
> it is more the vehicle (emails, notes posted to the liaison web page,
> etc.) than the source or the content.  One the advice of a
> wise person,
> I have started (belatedly) posting to the CCAMP list that
> such liaisons
> exist.  Note that I don't need to do that for IDs -- the
> authors generally
> do that, and there is a mailing list that one can subscribe for this.
>
> > But it is my opinion that the lack of a liaison process is really
> > the ROOT CAUSE of difficulties like what we saw in January.
>
> If we really do a root cause analysis, it comes down to this (IMO):
> a) CCAMP gets a liaison statement stating that certain changes are
>    requested in the GMPLS specs (doesn't get posted to the
> list, though).
> b) CCAMP doesn't officially respond (mechanisms not in place).
> c) CCAMP WG gets requirements via Zhi's and Osama's drafts.
> d) CCAMP mailing list hosts discussions about whether these
> requirements
>    make sense in the IETF context.
> e) In the interest of quick allocation of code points, these two docs
>    are made Informational, and go through without much review.
> f) Various folks (CCAMP, RSVP, MPLS, ...) are very concerned about the
>    changes made to RSVP and CR-LDP.
>
> (The intent here is not to point fingers, although I've
> already claimed
> my share of the blame.)
>
> I see (b) and (e) as the most serious breakdowns in the process.  The
> GMPLS change doc should help alleviate (e), and hopefully help (a) as
> well.  And if we get started on the liaison doc, that should help (b).
>
> Or we could keep talking :-)
>
> Kireeti.



From owner-mpls@UU.NET  Mon Mar  3 19:52:42 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19668
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 19:52:41 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeml11176
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 00:54:42 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeml11113;
	Tue, 4 Mar 2003 00:54:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoemj18690
	for mpls-outgoing; Tue, 4 Mar 2003 00:28:58 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoemj18683
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 00:28:49 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoemj22043
	for <mpls@UU.NET>; Tue, 4 Mar 2003 00:28:43 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemj10225
	for <mpls@UU.NET>; Tue, 4 Mar 2003 00:28:43 GMT
Received: from smtp.comcast.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp.comcast.net [24.153.64.2])
	id QQoemj10211
	for <mpls@UU.NET>; Tue, 4 Mar 2003 00:28:42 GMT
Received: from LINPORTEGE
 (pcp03191818pcs.midltn01.nj.comcast.net [68.36.136.113])
 by mtaout06.icomcast.net
 (iPlanet Messaging Server 5.2 HotFix 1.09 (built Jan  7 2003))
 with SMTP id <0HB700CMD7YO70@mtaout06.icomcast.net> for mpls@UU.NET; Mon,
 03 Mar 2003 19:28:01 -0500 (EST)
Date: Mon, 03 Mar 2003 19:27:48 -0500
From: Zhi-Wei Lin <zwlin@comcast.net>
Subject: RE: FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
In-reply-to: <9D42C6E086250248810DCADA39CE7EFC97228E@nimbus>
To: "'John Drake'" <jdrake@calient.net>, "'Zhi-Wei Lin'" <zhiweilin@yahoo.com>,
        mpls@UU.NET
Message-id: <004901c2e1e4$e32f5bc0$6e00a8c0@na01.lucent.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_a/AkWgltvD5w+wTlsbglVQ)"
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

--Boundary_(ID_a/AkWgltvD5w+wTlsbglVQ)
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7BIT

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


  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.

  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... ;-) 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). 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:zhiweilin@yahoo.com]
  Sent: Sunday, March 02, 2003 11:21 AM
  To: mpls@uu.net
  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


     From: John Drake [mailto:jdrake@calient.net]
    Sent: Friday, February 28, 2003 4:15 PM
    To: 'erosen@cisco.com'; Varma, Eve L (Eve)
    Cc: 'curtis@fictitious.org'; George Newsome; Stephen Trowbridge; Loa
    Andersson; mpls@UU.NET
    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:erosen@cisco.com]
    > Sent: Friday, February 28, 2003 12:54 PM
    > To: Varma, Eve L (Eve)
    > Cc: 'curtis@fictitious.org'; George Newsome; Stephen Trowbridge; Loa
    > Andersson; mpls@UU.NET
    > 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

--Boundary_(ID_a/AkWgltvD5w+wTlsbglVQ)
Content-type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2800.1141" name=GENERATOR></HEAD>
<BODY>
<DIV>
<P><FONT face=Arial color=#0000ff size=2>Hi John,</FONT></P>
<P><FONT face=Arial><FONT color=#0000ff><FONT size=2>Thanks for the 
clarification.<SPAN class=684041700-04032003> Some more comments 
below...</SPAN></FONT></FONT></FONT></P>
<P><FONT face=Tahoma><SPAN class=125442523-03032003><FONT size=2>Keeping 
a&nbsp;connection alive while attempting to reroute it after outage.&nbsp; (This 
is basic RSVP and&nbsp; MBB allows you to reuse links on the failed 
path.)&nbsp;<BR><SPAN class=684041700-04032003><FONT face=Arial 
color=#0000ff>[Zhi-Wei Lin]&nbsp;&nbsp;I don't think the intent of the call is 
simply to allow to keep connections alive. 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. 
</FONT></SPAN></FONT></SPAN></FONT></P></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
  size=2><SPAN class=125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
  size=2><SPAN class=125442523-03032003>Establishing a new path for an existing 
  </SPAN>c<SPAN class=125442523-03032003>onnection so that </SPAN>l<SPAN 
  class=125442523-03032003>inks along its&nbsp;current path may be taken out of 
  service for maintenance</SPAN>.</FONT><SPAN class=125442523-03032003><FONT 
  size=2>&nbsp; (This sounds like a definition of MBB.)<BR><SPAN 
  class=684041700-04032003><FONT face=Arial color=#0000ff>[Zhi-Wei 
  Lin]&nbsp;&nbsp;Same comment as 
above.</FONT></SPAN></FONT></SPAN></FONT></DIV>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
  size=2><SPAN class=125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
  size=2><SPAN class=125442523-03032003></SPAN></FONT></FONT><FONT 
  face=Tahoma><SPAN class=125442523-03032003><FONT size=2>Keeping track of the 
  circuits in a virtual concatenation group.&nbsp; (I think this is covered with 
  the SDH/SONET signalling draft.)<BR><SPAN class=684041700-04032003><FONT 
  face=Arial color=#0000ff>[Zhi-Wei Lin]&nbsp;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&nbsp;virtual concatenation group&nbsp;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&nbsp;provides a 
  nice way of supporting the multiple routings for each component virtual 
  concatenated&nbsp;signal.</FONT></SPAN></FONT></SPAN></FONT></DIV>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
  size=2><SPAN class=125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><SPAN 
  class=125442523-03032003><FONT size=2>The other requirement I've heard 
  is&nbsp;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.<BR><SPAN class=684041700-04032003><FONT face=Arial 
  color=#0000ff>[Zhi-Wei Lin]&nbsp;Right, but this&nbsp;also means extending the 
  Notify message. So it's a matter of choosing one method&nbsp;for 
  support&nbsp;versus another. Also using the&nbsp;Notify to support this is 
  just solving one part of the puzzle. It could be done, but&nbsp;the call 
  mechanism gives&nbsp;you all the above, plus the "service" concept (whatever 
  that is... ;-) For folks who wants to understand call, you can read G.8080 
  (that&nbsp;ITU-T G. stuff again! )&nbsp;or (*gasp!*) some of the ATM documents 
  on call (Q.2981 I think). 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??)</FONT></SPAN></FONT></SPAN></FONT></DIV>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
  size=2><SPAN class=125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
  size=2><SPAN class=125442523-03032003>Thanks,</SPAN></FONT></FONT></DIV>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
  size=2><SPAN class=125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
  size=2><SPAN class=125442523-03032003>John</SPAN></FONT></FONT></DIV>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
  size=2><SPAN class=125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Zhi-Wei Lin 
  [mailto:zhiweilin@yahoo.com]<BR><B>Sent:</B> Sunday, March 02, 2003 11:21 
  AM<BR><B>To:</B> mpls@uu.net<BR><B>Cc:</B> John Drake<BR><B>Subject:</B> Re: 
  FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
  <BR><BR></FONT></DIV></DIV>
  <BLOCKQUOTE 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
    <P>Hi John, 
    <P>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? 
    <P>Thanks<BR>Zhi 
    <P>
    <P>&nbsp;From: John Drake [mailto:jdrake@calient.net]<BR>Sent: Friday, 
    February 28, 2003 4:15 PM<BR>To: 'erosen@cisco.com'; Varma, Eve L 
    (Eve)<BR>Cc: 'curtis@fictitious.org'; George Newsome; Stephen Trowbridge; 
    Loa<BR>Andersson; mpls@UU.NET<BR>Subject: RE: I-D 
    ACTION:draft-andersson-mpls-g-chng-proc-00.txt <BR><BR><BR>I agree with 
    Eric.<BR><BR>As an example, we have call/connection separation, which has 
    been kicking<BR>around since the early days of ISDN. In discussions as to 
    why it is needed,<BR>the first reason is always "because". Once past that, I 
    have consistently<BR>heard four or five examples cited. What is interesting 
    is that all of them<BR>can be handled with the existing Make Before Break 
    component of RSVP-TE. <BR><BR>Thanks,<BR><BR>John<BR><BR>&gt; -----Original 
    Message-----<BR>&gt; From: Eric Rosen [mailto:erosen@cisco.com]<BR>&gt; 
    Sent: Friday, February 28, 2003 12:54 PM<BR>&gt; To: Varma, Eve L 
    (Eve)<BR>&gt; Cc: 'curtis@fictitious.org'; George Newsome; Stephen 
    Trowbridge; Loa<BR>&gt; Andersson; mpls@UU.NET<BR>&gt; Subject: Re: I-D 
    ACTION:draft-andersson-mpls-g-chng-proc-00.txt <BR>&gt; <BR>&gt; <BR>&gt; 
    <BR>&gt; Eve&gt; For individual contributor drafts coming in, it's quite 
    <BR>&gt; appropriate to<BR>&gt; Eve&gt; evaluate requirements and determine 
    if they are <BR>&gt; legitimate. It's a<BR>&gt; Eve&gt; different case when 
    another SDO, responsible for a <BR>&gt; non-IP applications<BR>&gt; Eve&gt; 
    domain, has established a set of requirements related to <BR>&gt; that 
    domain.<BR>&gt; <BR>&gt; I'd certainly disagree with that. Many of the 
    <BR>&gt; "requirements" I see from<BR>&gt; other organizations are not 
    requirements at all, but <BR>&gt; just dogmatic<BR>&gt; statements of 
    connection-oriented religion. If the IETF <BR>&gt; were to accept<BR>&gt; 
    requirements from other organizations, it would quickly be <BR>&gt; 
    inundated with<BR>&gt; "requirements" to make IP behave exactly like ATM. In 
    <BR>&gt; fact, anyone who<BR>&gt; works in the PWE3 group can testify that 
    such "requirements" <BR>&gt; come in all the<BR>&gt; time. <BR>&gt; <BR>&gt; 
    <BR>&gt; </P>
    <P><BR>
    <HR SIZE=1>
    Do you Yahoo!?<BR><A 
    href="http://rd.yahoo.com/finance/mailtagline/*http://taxes.yahoo.com/">Yahoo! 
    Tax Center</A> - forms, calculators, tips, and 
more</BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_a/AkWgltvD5w+wTlsbglVQ)--


From owner-mpls@UU.NET  Mon Mar  3 20:23:44 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20123
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 20:23:43 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemn13747
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 01:25:45 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoemn13647;
	Tue, 4 Mar 2003 01:25:39 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoemm20935
	for mpls-outgoing; Tue, 4 Mar 2003 01:00:01 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoeml20872
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 00:59:59 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoeml03698
	for <mpls@UU.NET>; Tue, 4 Mar 2003 00:58:48 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeml20428
	for <mpls@UU.NET>; Tue, 4 Mar 2003 00:58:47 GMT
Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQoeml20422
	for <mpls@UU.NET>; Tue, 4 Mar 2003 00:58:46 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h240wiS31869;
	Mon, 3 Mar 2003 16:58:44 -0800 (PST)
	(envelope-from kireeti@juniper.net)
Received: from localhost (kireeti@localhost)
	by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h240wiq52433;
	Mon, 3 Mar 2003 16:58:44 -0800 (PST)
	(envelope-from kireeti@juniper.net)
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
Date: Mon, 3 Mar 2003 16:58:44 -0800 (PST)
From: Kireeti Kompella <kireeti@juniper.net>
To: Curtis Villamizar <curtis@fictitious.org>
cc: Malcolm Betts <betts01@nortelnetworks.com>,
        Stephen Trowbridge <sjtrowbridge@lucent.com>, "" <mpls@UU.NET>,
        ccamp <ccamp@ops.ietf.org>
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
In-Reply-To: <200303032328.SAA84398@workhorse.fictitious.org>
Message-ID: <20030303162744.U51425@kummer.juniper.net>
References: <200303032328.SAA84398@workhorse.fictitious.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Curtis,

On Mon, 3 Mar 2003, Curtis Villamizar wrote:

> > Kireeti, if we can agree that we have two problems and from the perspective
> > of an external SDO they are closely coupled.  One way of moving forward
> > would be to develop two IDs in parallel.  The first based on the existing
> > anderson-mpls-g-change-proc, modified to state explicitly that requests for
> > changes by external SDOs are exempt from this process.  The second draft
> > would address the liaison process.  The key issue with changes requested by
> > external SDOs is that in general they will be based on the desire to apply
> > (G)MPLS protocols to connection management of connection oriented circuit
> > switched (COCS) networks for the benefit of COCS clients - i.e. to
> > applications that are well outside the "normal" IETF problem space. To keep
> > the activity  focussed (as suggested in some earlier emails) perhaps we
> > could limit the scope to the sub ip area only (at least initially).  I think
> > that Steve Trowbridge in an earlier email (copy below) provided a good
> > summary of the objectives of the liaison process.
>
>
> This is just fine except there is no concensus either way on Steve's
> opinion that the role of liasons should be changed.

Going further, I don't think consensus in the CCAMP WG (or even in
the sub-IP area) will change this -- there *are* some things in the
IETF that don't work by consensus.

> Therefore Loa's draft should not mention exclusion of liasons, because
> changing the liason relationship is not the current intent, and
> because the liason relationship will be addressed separately as
> suggested by Scott Bradner.

Agreed.

FYI: a group of us are working on a liaison draft, mainly to put the
issue in front of the IESG.  *I* don't envision this as a sub-IP pilot,
nor do I see this coming of the the CCAMP WG (nor the ITU-T) -- it will
be an individual submission from a bunch of concerned individuals.
Then again, it's a group of us, and we need to come to consensus :-)

Kireeti.


From owner-mpls@UU.NET  Mon Mar  3 21:18:56 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21190
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 21:18:56 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemr20172
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 02:20:58 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoemr20039;
	Tue, 4 Mar 2003 02:20:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoemp10767
	for mpls-outgoing; Tue, 4 Mar 2003 01:55:29 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoemp10762
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 01:55:21 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoemp10857
	for <mpls@UU.NET>; Tue, 4 Mar 2003 01:55:09 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemp27286
	for <mpls@UU.NET>; Tue, 4 Mar 2003 01:55:08 GMT
Received: from lightwave.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: lightwave.chromisys.com [63.102.55.206])
	id QQoemp27251
	for <mpls@UU.NET>; Tue, 4 Mar 2003 01:55:07 GMT
Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19)
	id <4GJZGM35>; Mon, 3 Mar 2003 17:55:03 -0800
Message-ID: <9D42C6E086250248810DCADA39CE7EFC972297@nimbus>
From: John Drake <jdrake@calient.net>
To: "'Zhi-Wei Lin'" <zwlin@comcast.net>, "'Zhi-Wei Lin'" <zhiweilin@yahoo.com>,
        mpls@UU.NET
Subject: RE: FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Mon, 3 Mar 2003 17:54:54 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2E1F1.0D50EB10"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2E1F1.0D50EB10
Content-Type: text/plain;
	charset="iso-8859-1"

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:zwlin@comcast.net]
Sent: Monday, March 03, 2003 4:28 PM
To: John Drake; 'Zhi-Wei Lin'; mpls@UU.NET
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:zhiweilin@yahoo.com]
Sent: Sunday, March 02, 2003 11:21 AM
To: mpls@uu.net
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 



 From: John Drake [mailto:jdrake@calient.net]
Sent: Friday, February 28, 2003 4:15 PM
To: 'erosen@cisco.com'; Varma, Eve L (Eve)
Cc: 'curtis@fictitious.org'; George Newsome; Stephen Trowbridge; Loa
Andersson; mpls@UU.NET
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:erosen@cisco.com]
> Sent: Friday, February 28, 2003 12:54 PM
> To: Varma, Eve L (Eve)
> Cc: 'curtis@fictitious.org'; George Newsome; Stephen Trowbridge; Loa
> Andersson; mpls@UU.NET
> 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!  <http://rd.yahoo.com/finance/mailtagline/*http://taxes.yahoo.com/>
Tax Center - forms, calculators, tips, and more


------_=_NextPart_001_01C2E1F1.0D50EB10
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D999194600-04032003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Comments in line.&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=3D999194600-04032003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D999194600-04032003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>&nbsp;A general comment is that it occurs to me that MBB and =
the RSVP=20
path protection I-D (</FONT><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recov=
ery-e2e-signaling-00.txt"><FONT=20
face=3DArial color=3D#0000ff=20
size=3D2>http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-reco=
very-e2e-signaling-00.txt</FONT></A><FONT=20
face=3DArial color=3D#0000ff size=3D2>)</FONT></SPAN><FONT =
face=3DArial><FONT=20
color=3D#0000ff><FONT size=3D2>&nbsp;<SPAN =
class=3D999194600-04032003>both take=20
advantage of the fact that RSVP-TE already has a a version of =
call/connection=20
separation.&nbsp; It might be prudent to examine its capabilities =
before=20
inventing a new mechanism</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D999194600-04032003></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D999194600-04032003>Thanks,</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D999194600-04032003></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D999194600-04032003>John</SPAN></FONT></FONT></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D999194600-04032003></SPAN></FONT><FONT face=3DTahoma =
size=3D2>-----Original=20
Message-----<BR><B>From:</B> Zhi-Wei Lin=20
[mailto:zwlin@comcast.net]<BR><B>Sent:</B> Monday, March 03, 2003 4:28=20
PM<BR><B>To:</B> John Drake; 'Zhi-Wei Lin'; =
mpls@UU.NET<BR><B>Subject:</B> RE:=20
FW: I-D =
ACTION:draft-andersson-mpls-g-chng-proc-00.txt<BR><BR></DIV></FONT>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV>
  <P><FONT face=3DArial color=3D#0000ff size=3D2>Hi John,</FONT></P>
  <P><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2>Thanks for =
the=20
  clarification.<SPAN class=3D684041700-04032003> Some more comments=20
  below...</SPAN></FONT></FONT></FONT></P>
  <P><FONT face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2>Keeping=20
  a&nbsp;connection alive while attempting to reroute it after =
outage.&nbsp;=20
  (This is basic RSVP and&nbsp; MBB allows you to reuse links on the =
failed=20
  path.)&nbsp;<BR><SPAN class=3D684041700-04032003><FONT face=3DArial=20
  color=3D#0000ff>[Zhi-Wei Lin]&nbsp;&nbsp;I don't think the intent of =
the call is=20
  simply to allow to keep connections alive.&nbsp;<SPAN=20
  =
class=3D999194600-04032003>&nbsp;</SPAN></FONT></SPAN></FONT></SPAN></FO=
NT></P>
  <P><FONT face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2><SPAN=20
  class=3D684041700-04032003><FONT face=3DArial color=3D#0000ff><SPAN=20
  =
class=3D999194600-04032003>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></FONT></SPAN>=
</FONT></SPAN></FONT></P>
  <P><FONT face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2><SPAN=20
  class=3D684041700-04032003><FONT face=3DArial color=3D#0000ff><SPAN=20
  class=3D999194600-04032003>JD:&nbsp; Are you saying that the above is =
not a=20
  requirement?</SPAN></FONT></SPAN></FONT></SPAN></FONT></P>
  <P><SPAN class=3D125442523-03032003><SPAN =
class=3D684041700-04032003><FONT=20
  face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
  class=3D999194600-04032003>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></FONT></FONT>=
</FONT></SPAN></SPAN></P>
  <P><SPAN class=3D125442523-03032003><SPAN =
class=3D684041700-04032003><FONT=20
  face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
  class=3D999194600-04032003>&nbsp;</SPAN>A call is much more related =
to the=20
  concept of providing service to the end-user. One of the services is =
the=20
  ability to keep a connection alive for, e.g., billing purposes, and =
having a=20
  single call ID for a call makes tracking of the service much easier =
as=20
  well.<SPAN=20
  =
class=3D999194600-04032003>&nbsp;</SPAN></FONT></FONT></FONT></SPAN></SP=
AN></P>
  <P><SPAN class=3D125442523-03032003><SPAN =
class=3D684041700-04032003><FONT=20
  face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
  =
class=3D999194600-04032003>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></FONT></FONT>=
</FONT></SPAN></SPAN></P>
  <P><SPAN class=3D125442523-03032003><SPAN =
class=3D684041700-04032003><FONT=20
  face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
  class=3D999194600-04032003>JD:&nbsp; This sounds like an=20
  assertion.</SPAN></FONT></FONT></FONT></SPAN></SPAN></P>
  <P><SPAN class=3D125442523-03032003><SPAN =
class=3D684041700-04032003><FONT=20
  face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
  =
class=3D999194600-04032003>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></FONT></FONT>=
</FONT></SPAN></SPAN><SPAN=20
  class=3D125442523-03032003><SPAN class=3D684041700-04032003><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><FONT size=3D2><SPAN =
class=3D999194600-04032003>&nbsp;</SPAN>=20
  </FONT></FONT></FONT></SPAN></SPAN></P></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff =
2px solid; MARGIN-RIGHT: 0px">
    <DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><FONT=20
    size=3D2><SPAN =
class=3D125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><FONT=20
    size=3D2><SPAN class=3D125442523-03032003>Establishing a new path =
for an=20
    existing </SPAN>c<SPAN class=3D125442523-03032003>onnection so that =

    </SPAN>l<SPAN class=3D125442523-03032003>inks along =
its&nbsp;current path may=20
    be taken out of service for maintenance</SPAN>.</FONT><SPAN=20
    class=3D125442523-03032003><FONT size=3D2>&nbsp; (This sounds like =
a definition=20
    of MBB.)<BR><SPAN class=3D684041700-04032003><FONT face=3DArial=20
    color=3D#0000ff>[Zhi-Wei Lin]&nbsp;&nbsp;Same comment as=20
    above.</FONT></SPAN></FONT></SPAN></FONT></DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><FONT=20
    size=3D2><SPAN =
class=3D125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><FONT=20
    size=3D2><SPAN =
class=3D125442523-03032003></SPAN></FONT></FONT><FONT=20
    face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2>Keeping track of the=20
    circuits in a virtual concatenation group.&nbsp; (I think this is =
covered=20
    with the SDH/SONET signalling draft.)<BR><SPAN=20
    class=3D684041700-04032003><FONT face=3DArial><FONT =
color=3D#0000ff>[Zhi-Wei=20
    Lin]&nbsp;This is really not covered in full in the SONET/SDH =
signaling=20
    draft. The current signaling draft puts a limitation on the virtual =

    concatenation by requiring that all component members of the =
virtual=20
    concatenated signal travel along the same path. The general virtual =

    concatenation mechanism allows for each component of =
the&nbsp;virtual=20
    concatenation group&nbsp;to travel along different paths. This is =
really=20
    where the call concept comes in handy. Again note that call is not =
designed=20
    specifially for the virtual concatenation, but it&nbsp;provides a =
nice way=20
    of supporting the multiple routings for each component virtual=20
    concatenated&nbsp;signal.<SPAN=20
    class=3D999194600-04032003>&nbsp;</SPAN></FONT></FONT></SPAN></FONT>=
</SPAN></FONT></DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><SPAN=20
    class=3D125442523-03032003><FONT size=3D2><SPAN =
class=3D684041700-04032003><FONT=20
    face=3DArial><FONT color=3D#0000ff><SPAN=20
    =
class=3D999194600-04032003></SPAN></FONT></FONT></SPAN></FONT></SPAN></F=
ONT>&nbsp;</DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><SPAN=20
    class=3D125442523-03032003><FONT size=3D2><SPAN =
class=3D684041700-04032003><FONT=20
    face=3DArial><FONT color=3D#0000ff><SPAN=20
    =
class=3D999194600-04032003>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></FONT></FONT>=
</SPAN></FONT></SPAN></FONT></DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><SPAN=20
    class=3D125442523-03032003><FONT size=3D2><SPAN =
class=3D684041700-04032003><FONT=20
    face=3DArial><FONT color=3D#0000ff><SPAN =
class=3D999194600-04032003>JD:&nbsp; I=20
    don't think that multiple connections per call, especially =
connections that=20
    take different paths, is supported in either G.8080 or =
G.7713.x.&nbsp;=20
    Furthermore the existing RSVP-TE mechanisms could be used to =
support the=20
    general =
case&nbsp;</SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT></DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><SPAN=20
    class=3D125442523-03032003><FONT size=3D2><SPAN =
class=3D684041700-04032003><FONT=20
    face=3DArial><FONT color=3D#0000ff><SPAN=20
    =
class=3D999194600-04032003>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></FONT></FONT>=
</SPAN></FONT></SPAN></FONT></DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><FONT=20
    size=3D2><SPAN =
class=3D125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><SPAN=20
    class=3D125442523-03032003><FONT size=3D2>The other requirement =
I've heard=20
    is&nbsp;a need to have the ingress and egress nodes perform a =
capabilities=20
    exchange prior to establishing a connection, and that sounds like =
something=20
    Notify should be used for.<BR><SPAN =
class=3D684041700-04032003><FONT=20
    color=3D#0000ff><FONT face=3DArial>[Zhi-Wei Lin]&nbsp;Right, but =
this&nbsp;also=20
    means extending the Notify message. So it's a matter of choosing =
one=20
    method&nbsp;for support&nbsp;versus another. Also using =
the&nbsp;Notify to=20
    support this is just solving one part of the puzzle. It could be =
done,=20
    but&nbsp;the call mechanism gives&nbsp;you all the above, plus the =
"service"=20
    concept (whatever that is... ;-)&nbsp;<SPAN =
class=3D999194600-04032003><FONT=20
    =
color=3D#000000>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></FONT></SPAN><=
/FONT></DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><SPAN=20
    class=3D125442523-03032003><FONT size=3D2><SPAN =
class=3D684041700-04032003><FONT=20
    color=3D#0000ff><FONT face=3DArial><SPAN=20
    =
class=3D999194600-04032003></SPAN></FONT></FONT></SPAN></FONT></SPAN></F=
ONT>&nbsp;</DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><SPAN=20
    class=3D125442523-03032003><FONT size=3D2><SPAN =
class=3D684041700-04032003><FONT=20
    color=3D#0000ff><FONT face=3DArial><SPAN=20
    =
class=3D999194600-04032003>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></FONT></FO=
NT></SPAN></FONT></SPAN></FONT></DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><SPAN=20
    class=3D125442523-03032003><FONT size=3D2><SPAN =
class=3D684041700-04032003><FONT=20
    color=3D#0000ff><FONT face=3DArial><SPAN =
class=3D999194600-04032003>JD:&nbsp; It=20
    is not at all obvious from your draft&nbsp;whether you=20
    are:</SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT></DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><SPAN=20
    class=3D125442523-03032003><FONT size=3D2><SPAN =
class=3D684041700-04032003><FONT=20
    color=3D#0000ff><FONT face=3DArial><SPAN=20
    =
class=3D999194600-04032003></SPAN></FONT></FONT></SPAN></FONT></SPAN></F=
ONT>&nbsp;</DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><SPAN=20
    class=3D125442523-03032003><FONT size=3D2><SPAN =
class=3D684041700-04032003><FONT=20
    color=3D#0000ff><FONT face=3DArial><SPAN =
class=3D999194600-04032003>&nbsp;a)=20
    piggybacking a call ID on normal RSVP LSP=20
    setup&nbsp;</SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT></DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><SPAN=20
    class=3D125442523-03032003><FONT size=3D2><SPAN =
class=3D684041700-04032003><FONT=20
    color=3D#0000ff><FONT face=3DArial><SPAN=20
    =
class=3D999194600-04032003></SPAN></FONT></FONT></SPAN></FONT></SPAN></F=
ONT>&nbsp;</DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><SPAN=20
    class=3D125442523-03032003><FONT size=3D2><SPAN =
class=3D684041700-04032003><FONT=20
    color=3D#0000ff><FONT face=3DArial><SPAN=20
    =
class=3D999194600-04032003>or</SPAN></FONT></FONT></SPAN></FONT></SPAN><=
/FONT></DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><SPAN=20
    class=3D125442523-03032003><FONT size=3D2><SPAN =
class=3D684041700-04032003><FONT=20
    color=3D#0000ff><FONT face=3DArial><SPAN=20
    =
class=3D999194600-04032003></SPAN></FONT></FONT></SPAN></FONT></SPAN></F=
ONT>&nbsp;</DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><SPAN=20
    class=3D125442523-03032003><FONT size=3D2><SPAN =
class=3D684041700-04032003><FONT=20
    color=3D#0000ff><FONT face=3DArial><SPAN =
class=3D999194600-04032003>&nbsp;b) using=20
    a hacked up version of RSVP LSP setup to instantiate call state in =
all of=20
    the nodes along a path from&nbsp;ingress node&nbsp;to egress=20
    node.</SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT></DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><SPAN=20
    class=3D125442523-03032003><FONT size=3D2><SPAN =
class=3D684041700-04032003><FONT=20
    color=3D#0000ff><FONT face=3DArial><SPAN=20
    =
class=3D999194600-04032003></SPAN></FONT></FONT></SPAN></FONT></SPAN></F=
ONT>&nbsp;</DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><SPAN=20
    class=3D125442523-03032003><FONT size=3D2><SPAN =
class=3D684041700-04032003><FONT=20
    color=3D#0000ff><FONT face=3DArial><SPAN =
class=3D999194600-04032003>If it is the=20
    former, then using Notify is better because it allows a =
capabilities=20
    exchange prior to the allocation of any network resources.&nbsp; If =
it is=20
    the latter, then using&nbsp;Notify is better because you are=20
    creating&nbsp;severe interoperability problems with nodes that=20
    understand&nbsp;GMPLS signalling but don't understand this hacked =
up version=20
    of RSVP setup, in support of something which is supposed to be=20
    an&nbsp;ingress/egress=20
    =
node&nbsp;function.&nbsp;&nbsp;&nbsp;&nbsp;</SPAN></FONT></FONT></SPAN><=
/FONT></SPAN></FONT></DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><SPAN=20
    class=3D125442523-03032003><FONT size=3D2><SPAN =
class=3D684041700-04032003><FONT=20
    color=3D#0000ff><FONT face=3DArial><SPAN=20
    =
class=3D999194600-04032003>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></FONT><=
/FONT></SPAN></FONT></SPAN></FONT></DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><SPAN=20
    class=3D125442523-03032003><FONT size=3D2><SPAN =
class=3D684041700-04032003><FONT=20
    color=3D#0000ff><FONT face=3DArial><SPAN=20
    =
class=3D999194600-04032003></SPAN></FONT></FONT></SPAN></FONT></SPAN></F=
ONT>&nbsp;</DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><SPAN=20
    class=3D125442523-03032003><SPAN class=3D684041700-04032003><FONT=20
    color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20
    class=3D999194600-04032003>&nbsp;</SPAN>For folks who wants to =
understand=20
    call, you can read G.8080 (that&nbsp;ITU-T G. stuff again! =
)&nbsp;or=20
    (*gasp!*) some of the ATM documents on call (Q.2981 I think).&nbsp;<=
SPAN=20
    class=3D999194600-04032003><FONT=20
    =
color=3D#000000>&nbsp;</FONT></SPAN></FONT></FONT></FONT></SPAN></SPAN><=
/DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><SPAN=20
    class=3D125442523-03032003><SPAN class=3D684041700-04032003><FONT=20
    color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20
    =
class=3D999194600-04032003>&nbsp;</SPAN></FONT></FONT></FONT></SPAN></SP=
AN><FONT=20
    face=3DTahoma><SPAN class=3D125442523-03032003><FONT size=3D2><SPAN =

    class=3D684041700-04032003><FONT face=3DArial><SPAN=20
    =
class=3D999194600-04032003></SPAN></FONT></SPAN></FONT></SPAN></FONT></D=
IV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><SPAN=20
    class=3D125442523-03032003><FONT size=3D2><SPAN =
class=3D684041700-04032003><FONT=20
    face=3DArial><FONT color=3D#0000ff><SPAN=20
    =
class=3D999194600-04032003>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></FONT><=
/FONT></SPAN></FONT></SPAN></FONT></DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><SPAN=20
    class=3D125442523-03032003><FONT size=3D2><SPAN =
class=3D684041700-04032003><FONT=20
    face=3DArial><FONT color=3D#0000ff><SPAN =
class=3D999194600-04032003>JD:&nbsp; As=20
    I've said before, during my tenure at the ATM Forum, we could not =
get=20
    call/connection separation to work in=20
    PNNI.</SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT></DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><SPAN=20
    class=3D125442523-03032003><FONT size=3D2><SPAN =
class=3D684041700-04032003><FONT=20
    face=3DArial><FONT color=3D#0000ff><SPAN=20
    =
class=3D999194600-04032003>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></FONT><=
/FONT></SPAN></FONT></SPAN></FONT></DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><SPAN=20
    class=3D125442523-03032003><FONT color=3D#0000ff><FONT =
face=3DArial><FONT=20
    size=3D2><SPAN class=3D999194600-04032003><FONT=20
    =
color=3D#000000>&nbsp;</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><SPAN=20
    class=3D125442523-03032003><FONT color=3D#0000ff><FONT =
face=3DArial><FONT=20
    size=3D2><SPAN class=3D999194600-04032003>&nbsp;</SPAN>Of course =
those of you=20
    who still uses your telephone or even your cellphone are everyday =
making a=20
    "call" (but only always one connection within the call -- very =
limited,=20
    huh??)<SPAN=20
    =
class=3D999194600-04032003>&nbsp;</SPAN></FONT></FONT></FONT></SPAN></DI=
V>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
size=3D2><SPAN=20
    class=3D125442523-03032003><FONT color=3D#0000ff><FONT =
face=3DArial><SPAN=20
    =
class=3D999194600-04032003></SPAN></FONT></FONT></SPAN></FONT>&nbsp;</DI=
V>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><FONT=20
    size=3D2><SPAN =
class=3D125442523-03032003>Thanks,</SPAN></FONT></FONT></DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><FONT=20
    size=3D2><SPAN =
class=3D125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><FONT=20
    size=3D2><SPAN =
class=3D125442523-03032003>John</SPAN></FONT></FONT></DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma><FONT=20
    size=3D2><SPAN =
class=3D125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Zhi-Wei Lin=20
    [mailto:zhiweilin@yahoo.com]<BR><B>Sent:</B> Sunday, March 02, 2003 =
11:21=20
    AM<BR><B>To:</B> mpls@uu.net<BR><B>Cc:</B> John =
Drake<BR><B>Subject:</B> Re:=20
    FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt=20
    <BR><BR></FONT></DIV></DIV>
    <BLOCKQUOTE=20
    style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff =
2px solid">
      <P>Hi John,=20
      <P>I was wondering about the statements you've made below, =
especially the=20
      one about "all of them can be handled with the existing Make =
Before Break=20
      component of RSVP-TE". I'm a little slow, so could you elaborate =
a little=20
      more as to how this is related to the call/connection concept, =
and how the=20
      make-before-break actually handles the call service concept?=20
      <P>Thanks<BR>Zhi=20
      <P>
      <P>&nbsp;From: John Drake [mailto:jdrake@calient.net]<BR>Sent: =
Friday,=20
      February 28, 2003 4:15 PM<BR>To: 'erosen@cisco.com'; Varma, Eve L =

      (Eve)<BR>Cc: 'curtis@fictitious.org'; George Newsome; Stephen =
Trowbridge;=20
      Loa<BR>Andersson; mpls@UU.NET<BR>Subject: RE: I-D=20
      ACTION:draft-andersson-mpls-g-chng-proc-00.txt <BR><BR><BR>I =
agree with=20
      Eric.<BR><BR>As an example, we have call/connection separation, =
which has=20
      been kicking<BR>around since the early days of ISDN. In =
discussions as to=20
      why it is needed,<BR>the first reason is always "because". Once =
past that,=20
      I have consistently<BR>heard four or five examples cited. What is =

      interesting is that all of them<BR>can be handled with the =
existing Make=20
      Before Break component of RSVP-TE. =
<BR><BR>Thanks,<BR><BR>John<BR><BR>&gt;=20
      -----Original Message-----<BR>&gt; From: Eric Rosen=20
      [mailto:erosen@cisco.com]<BR>&gt; Sent: Friday, February 28, 2003 =
12:54=20
      PM<BR>&gt; To: Varma, Eve L (Eve)<BR>&gt; Cc: =
'curtis@fictitious.org';=20
      George Newsome; Stephen Trowbridge; Loa<BR>&gt; Andersson;=20
      mpls@UU.NET<BR>&gt; Subject: Re: I-D=20
      ACTION:draft-andersson-mpls-g-chng-proc-00.txt <BR>&gt; <BR>&gt; =
<BR>&gt;=20
      <BR>&gt; Eve&gt; For individual contributor drafts coming in, =
it's quite=20
      <BR>&gt; appropriate to<BR>&gt; Eve&gt; evaluate requirements and =

      determine if they are <BR>&gt; legitimate. It's a<BR>&gt; Eve&gt; =

      different case when another SDO, responsible for a <BR>&gt; =
non-IP=20
      applications<BR>&gt; Eve&gt; domain, has established a set of =
requirements=20
      related to <BR>&gt; that domain.<BR>&gt; <BR>&gt; I'd certainly =
disagree=20
      with that. Many of the <BR>&gt; "requirements" I see from<BR>&gt; =
other=20
      organizations are not requirements at all, but <BR>&gt; just=20
      dogmatic<BR>&gt; statements of connection-oriented religion. If =
the IETF=20
      <BR>&gt; were to accept<BR>&gt; requirements from other =
organizations, it=20
      would quickly be <BR>&gt; inundated with<BR>&gt; "requirements" =
to make IP=20
      behave exactly like ATM. In <BR>&gt; fact, anyone who<BR>&gt; =
works in the=20
      PWE3 group can testify that such "requirements" <BR>&gt; come in =
all=20
      the<BR>&gt; time. <BR>&gt; <BR>&gt; <BR>&gt; </P>
      <P><BR>
      <HR SIZE=3D1>
      Do you Yahoo!?<BR><A=20
      =
href=3D"http://rd.yahoo.com/finance/mailtagline/*http://taxes.yahoo.com/=
">Yahoo!=20
      Tax Center</A> - forms, calculators, tips, and=20
more</BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C2E1F1.0D50EB10--


From owner-mpls@UU.NET  Mon Mar  3 21:43:08 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21678
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 21:43:08 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemt28395
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 02:45:09 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoemt28151;
	Tue, 4 Mar 2003 02:45:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoemr29580
	for mpls-outgoing; Tue, 4 Mar 2003 02:19:20 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoemr29573
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 02:19:13 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoemr19063
	for <mpls@uu.net>; Tue, 4 Mar 2003 02:18:05 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemr17646
	for <mpls@uu.net>; Tue, 4 Mar 2003 02:18:05 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoemr17641
	for <mpls@uu.net>; Tue, 4 Mar 2003 02:18:04 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h242I2JR000225
	for <mpls@uu.net>; Mon, 3 Mar 2003 21:18:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA27005 for <mpls@uu.net>; Mon, 3 Mar 2003 21:18:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h242I1026873 for mpls@uu.net; Mon, 3 Mar 2003 21:18:01 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoemr29409
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 02:16:10 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoemr12653
	for <mpls@UU.NET>; Tue, 4 Mar 2003 02:15:48 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemr23717
	for <mpls@UU.NET>; Tue, 4 Mar 2003 02:15:48 GMT
Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoemr23692
	for <mpls@UU.NET>; Tue, 4 Mar 2003 02:15:47 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id VAA84999;
	Mon, 3 Mar 2003 21:13:43 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303040213.VAA84999@workhorse.fictitious.org>
To: Zhi-Wei Lin <zwlin@comcast.net>
cc: "'John Drake'" <jdrake@calient.net>, "'Zhi-Wei Lin'" <zhiweilin@yahoo.com>,
        mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
In-reply-to: Your message of "Mon, 03 Mar 2003 19:27:48 EST."
             <004901c2e1e4$e32f5bc0$6e00a8c0@na01.lucent.com> 
Date: Mon, 03 Mar 2003 21:13:43 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <004901c2e1e4$e32f5bc0$6e00a8c0@na01.lucent.com>, Zhi-Wei Lin writes
:
> 
> 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. 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.
> 
> 
>   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.
> 
>   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... ;-) 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). 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??)


Zhi,

MPLS is used for traffic engineering and is applied mostly to OC48c
and OC192c cores, though maybe extending out to OC12c and OC3c fringes
of a provider's network.  These MPLS LSP are not "calls".  They are
not customer "connections" of any kind.  GMPLS applies to even larger
aggregations of bandwidth when applied to optical (its orgiginal
purpose).

> keep a connection alive for, e.g., billing purposes, and having a single

This is the heart of the call/connection argument.  It didn't fly in
the early 1990s.  The Internet didn't implode because there was no way
to do per connection billing.  In fact it is the call/connection
telcos that are having the severe financial woes.  Those that own IP
operations (and virtually all do) generally have profitable IP
divisions.  Leased and switched services are declining while end
system encrypted VPN and provider VPN are growing.  Voice is becoming
flat rate.  Email and IM are clearly not call/connection oriented
unless you consider TCP to be call/connection.  Add voice to IM and
break through the last mile bandwidth monopoly and we wouldn't even
need the PSTN and its call/connection model, the last remnants of a
legacy technology whose demise began in 1984.

FR, SMDS, and ATM provided customer connections.  FR is still used for
low speed customer circuits, VPNs, etc.  SMDS is dead.  ATM SVC
services had virtually ZERO penetration at its peak and what little it
had was at low bandwidths.

ATM had some brief success as a core technology but 100% of that was
PVC or SPVC.  The reason we have MPLS is there were some things about
ATM that the IETF regarded as very broken.  The people that regarded
it as very broken were the very poeple running among the highest
capacity ATM deploymennts in the world, all running IP over ATM SPVCs.

What you are trying to do is bring some of the call/connection
brokenness that was rejected in the mid to late 1990s back into MPLS
after ATM failed in the market.

If you want to reminisce about the Q.2931 connection model go to the
ATM Forum and reminisce.  The Q.2931 model is dead in the IETF, always
has been, always will be.  The ATM Forum loves Q.2931 and they'd love
G.8080 since it is of the same mindset.  Please go away and use PNNI.

Curtis



From owner-mpls@UU.NET  Mon Mar  3 22:10:22 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22037
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 22:10:22 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemu21912
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 03:12:24 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoemu21808;
	Tue, 4 Mar 2003 03:12:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoems01140
	for mpls-outgoing; Tue, 4 Mar 2003 02:44:52 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoems01128
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 02:44:46 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoems17903
	for <mpls@UU.NET>; Tue, 4 Mar 2003 02:44:09 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoems27300
	for <mpls@UU.NET>; Tue, 4 Mar 2003 02:44:08 GMT
Received: from smtp.comcast.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp.comcast.net [24.153.64.2])
	id QQoems27293
	for <mpls@UU.NET>; Tue, 4 Mar 2003 02:44:08 GMT
Received: from LINPORTEGE
 (pcp03191818pcs.midltn01.nj.comcast.net [68.36.136.113])
 by mtaout02.icomcast.net
 (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003))
 with SMTP id <0HB7008L7E9IF2@mtaout02.icomcast.net> for mpls@UU.NET; Mon,
 03 Mar 2003 21:44:08 -0500 (EST)
Date: Mon, 03 Mar 2003 21:43:53 -0500
From: Zhi-Wei Lin <zwlin@comcast.net>
Subject: RE: FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
In-reply-to: <9D42C6E086250248810DCADA39CE7EFC972297@nimbus>
To: "'John Drake'" <jdrake@calient.net>, mpls@UU.NET
Message-id: <000001c2e1f7$e5f84520$6e00a8c0@na01.lucent.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_owFHvRANZoymFcK8E0zriQ)"
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

--Boundary_(ID_owFHvRANZoymFcK8E0zriQ)
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7BIT

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

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:jdrake@calient.net]
  Sent: Monday, March 03, 2003 8:55 PM
  To: 'Zhi-Wei Lin'; 'Zhi-Wei Lin'; mpls@UU.NET
  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) 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:zwlin@comcast.net]
  Sent: Monday, March 03, 2003 4:28 PM
  To: John Drake; 'Zhi-Wei Lin'; mpls@UU.NET
  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:zhiweilin@yahoo.com]
      Sent: Sunday, March 02, 2003 11:21 AM
      To: mpls@uu.net
      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


         From: John Drake [mailto:jdrake@calient.net]
        Sent: Friday, February 28, 2003 4:15 PM
        To: 'erosen@cisco.com'; Varma, Eve L (Eve)
        Cc: 'curtis@fictitious.org'; George Newsome; Stephen Trowbridge; Loa
        Andersson; mpls@UU.NET
        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:erosen@cisco.com]
        > Sent: Friday, February 28, 2003 12:54 PM
        > To: Varma, Eve L (Eve)
        > Cc: 'curtis@fictitious.org'; George Newsome; Stephen Trowbridge;
Loa
        > Andersson; mpls@UU.NET
        > 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

--Boundary_(ID_owFHvRANZoymFcK8E0zriQ)
Content-type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2800.1141" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=405023802-04032003>Hi 
John,</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=405023802-04032003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=405023802-04032003>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. 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?</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=405023802-04032003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=405023802-04032003>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. </SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=405023802-04032003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=405023802-04032003>Thanks 
for your comments! Definitely helps to identify what different methods there are 
to solve the same problem.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=405023802-04032003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=405023802-04032003>Zhi</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=405023802-04032003></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> John Drake 
  [mailto:jdrake@calient.net]<BR><B>Sent:</B> Monday, March 03, 2003 8:55 
  PM<BR><B>To:</B> 'Zhi-Wei Lin'; 'Zhi-Wei Lin'; mpls@UU.NET<BR><B>Subject:</B> 
  RE: FW: I-D 
ACTION:draft-andersson-mpls-g-chng-proc-00.txt<BR><BR></FONT></DIV>
  <DIV><SPAN class=999194600-04032003><FONT face=Arial color=#0000ff 
  size=2>Comments in line.&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=999194600-04032003><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=999194600-04032003><FONT face=Arial color=#0000ff 
  size=2>&nbsp;A general comment is that it occurs to me that MBB and the RSVP 
  path protection I-D (</FONT><A 
  href="http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-00.txt"><FONT 
  face=Arial color=#0000ff 
  size=2>http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-00.txt</FONT></A><FONT 
  face=Arial color=#0000ff size=2>)</FONT></SPAN><FONT face=Arial><FONT 
  color=#0000ff><FONT size=2>&nbsp;<SPAN class=999194600-04032003>both take 
  advantage of the fact that RSVP-TE already has a a version of call/connection 
  separation.&nbsp; It might be prudent to examine its capabilities before 
  inventing a new mechanism</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
  class=999194600-04032003></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
  class=999194600-04032003>Thanks,</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
  class=999194600-04032003></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
  class=999194600-04032003>John</SPAN></FONT></FONT></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=999194600-04032003></SPAN></FONT><FONT face=Tahoma size=2>-----Original 
  Message-----<BR><B>From:</B> Zhi-Wei Lin 
  [mailto:zwlin@comcast.net]<BR><B>Sent:</B> Monday, March 03, 2003 4:28 
  PM<BR><B>To:</B> John Drake; 'Zhi-Wei Lin'; mpls@UU.NET<BR><B>Subject:</B> RE: 
  FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt<BR><BR></DIV></FONT>
  <BLOCKQUOTE dir=ltr 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
    <DIV>
    <P><FONT face=Arial color=#0000ff size=2>Hi John,</FONT></P>
    <P><FONT face=Arial><FONT color=#0000ff><FONT size=2>Thanks for the 
    clarification.<SPAN class=684041700-04032003> Some more comments 
    below...</SPAN></FONT></FONT></FONT></P>
    <P><FONT face=Tahoma><SPAN class=125442523-03032003><FONT size=2>Keeping 
    a&nbsp;connection alive while attempting to reroute it after outage.&nbsp; 
    (This is basic RSVP and&nbsp; MBB allows you to reuse links on the failed 
    path.)&nbsp;<BR><SPAN class=684041700-04032003><FONT face=Arial 
    color=#0000ff>[Zhi-Wei Lin]&nbsp;&nbsp;I don't think the intent of the call 
    is simply to allow to keep connections alive.&nbsp;<SPAN 
    class=999194600-04032003>&nbsp;</SPAN></FONT></SPAN></FONT></SPAN></FONT></P>
    <P><FONT face=Tahoma><SPAN class=125442523-03032003><FONT size=2><SPAN 
    class=684041700-04032003><FONT face=Arial color=#0000ff><SPAN 
    class=999194600-04032003>========================================================================================================</SPAN></FONT></SPAN></FONT></SPAN></FONT></P>
    <P><FONT face=Tahoma><SPAN class=125442523-03032003><FONT size=2><SPAN 
    class=684041700-04032003><FONT face=Arial color=#0000ff><SPAN 
    class=999194600-04032003>JD:&nbsp; Are you saying that the above is not a 
    requirement?</SPAN></FONT></SPAN></FONT></SPAN></FONT></P>
    <P><SPAN class=125442523-03032003><SPAN class=684041700-04032003><FONT 
    face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
    class=999194600-04032003>========================================================================================================</SPAN></FONT></FONT></FONT></SPAN></SPAN></P>
    <P><SPAN class=125442523-03032003><SPAN class=684041700-04032003><FONT 
    face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
    class=999194600-04032003>&nbsp;</SPAN>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.<SPAN 
    class=999194600-04032003>&nbsp;</SPAN></FONT></FONT></FONT></SPAN></SPAN></P>
    <P><SPAN class=125442523-03032003><SPAN class=684041700-04032003><FONT 
    face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
    class=999194600-04032003>========================================================================================================</SPAN></FONT></FONT></FONT></SPAN></SPAN></P>
    <P><SPAN class=125442523-03032003><SPAN class=684041700-04032003><FONT 
    face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
    class=999194600-04032003>JD:&nbsp; This sounds like an 
    assertion.</SPAN></FONT></FONT></FONT></SPAN></SPAN></P>
    <P><SPAN class=125442523-03032003><SPAN class=684041700-04032003><FONT 
    face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
    class=999194600-04032003>========================================================================================================</SPAN></FONT></FONT></FONT></SPAN></SPAN><SPAN 
    class=125442523-03032003><SPAN class=684041700-04032003><FONT 
    face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
    class=999194600-04032003>&nbsp;</SPAN> 
    </FONT></FONT></FONT></SPAN></SPAN></P></DIV>
    <BLOCKQUOTE dir=ltr 
    style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
      <DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
      size=2><SPAN class=125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
      size=2><SPAN class=125442523-03032003>Establishing a new path for an 
      existing </SPAN>c<SPAN class=125442523-03032003>onnection so that 
      </SPAN>l<SPAN class=125442523-03032003>inks along its&nbsp;current path 
      may be taken out of service for maintenance</SPAN>.</FONT><SPAN 
      class=125442523-03032003><FONT size=2>&nbsp; (This sounds like a 
      definition of MBB.)<BR><SPAN class=684041700-04032003><FONT face=Arial 
      color=#0000ff>[Zhi-Wei Lin]&nbsp;&nbsp;Same comment as 
      above.</FONT></SPAN></FONT></SPAN></FONT></DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
      size=2><SPAN class=125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
      size=2><SPAN class=125442523-03032003></SPAN></FONT></FONT><FONT 
      face=Tahoma><SPAN class=125442523-03032003><FONT size=2>Keeping track of 
      the circuits in a virtual concatenation group.&nbsp; (I think this is 
      covered with the SDH/SONET signalling draft.)<BR><SPAN 
      class=684041700-04032003><FONT face=Arial><FONT color=#0000ff>[Zhi-Wei 
      Lin]&nbsp;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&nbsp;virtual 
      concatenation group&nbsp;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&nbsp;provides a 
      nice way of supporting the multiple routings for each component virtual 
      concatenated&nbsp;signal.<SPAN 
      class=999194600-04032003>&nbsp;</SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT></DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><SPAN 
      class=125442523-03032003><FONT size=2><SPAN class=684041700-04032003><FONT 
      face=Arial><FONT color=#0000ff><SPAN 
      class=999194600-04032003></SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><SPAN 
      class=125442523-03032003><FONT size=2><SPAN class=684041700-04032003><FONT 
      face=Arial><FONT color=#0000ff><SPAN 
      class=999194600-04032003>========================================================================================================</SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT></DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><SPAN 
      class=125442523-03032003><FONT size=2><SPAN class=684041700-04032003><FONT 
      face=Arial><FONT color=#0000ff><SPAN class=999194600-04032003>JD:&nbsp; 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.&nbsp; Furthermore the existing RSVP-TE mechanisms could be used 
      to support the general 
      case&nbsp;</SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT></DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><SPAN 
      class=125442523-03032003><FONT size=2><SPAN class=684041700-04032003><FONT 
      face=Arial><FONT color=#0000ff><SPAN 
      class=999194600-04032003>========================================================================================================</SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT></DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
      size=2><SPAN class=125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><SPAN 
      class=125442523-03032003><FONT size=2>The other requirement I've heard 
      is&nbsp;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.<BR><SPAN 
      class=684041700-04032003><FONT color=#0000ff><FONT face=Arial>[Zhi-Wei 
      Lin]&nbsp;Right, but this&nbsp;also means extending the Notify message. So 
      it's a matter of choosing one method&nbsp;for support&nbsp;versus another. 
      Also using the&nbsp;Notify to support this is just solving one part of the 
      puzzle. It could be done, but&nbsp;the call mechanism gives&nbsp;you all 
      the above, plus the "service" concept (whatever that is... ;-)&nbsp;<SPAN 
      class=999194600-04032003><FONT 
      color=#000000>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT></DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><SPAN 
      class=125442523-03032003><FONT size=2><SPAN class=684041700-04032003><FONT 
      color=#0000ff><FONT face=Arial><SPAN 
      class=999194600-04032003></SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><SPAN 
      class=125442523-03032003><FONT size=2><SPAN class=684041700-04032003><FONT 
      color=#0000ff><FONT face=Arial><SPAN 
      class=999194600-04032003>=========================================================================================================</SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT></DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><SPAN 
      class=125442523-03032003><FONT size=2><SPAN class=684041700-04032003><FONT 
      color=#0000ff><FONT face=Arial><SPAN class=999194600-04032003>JD:&nbsp; It 
      is not at all obvious from your draft&nbsp;whether you 
      are:</SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT></DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><SPAN 
      class=125442523-03032003><FONT size=2><SPAN class=684041700-04032003><FONT 
      color=#0000ff><FONT face=Arial><SPAN 
      class=999194600-04032003></SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><SPAN 
      class=125442523-03032003><FONT size=2><SPAN class=684041700-04032003><FONT 
      color=#0000ff><FONT face=Arial><SPAN class=999194600-04032003>&nbsp;a) 
      piggybacking a call ID on normal RSVP LSP 
      setup&nbsp;</SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT></DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><SPAN 
      class=125442523-03032003><FONT size=2><SPAN class=684041700-04032003><FONT 
      color=#0000ff><FONT face=Arial><SPAN 
      class=999194600-04032003></SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><SPAN 
      class=125442523-03032003><FONT size=2><SPAN class=684041700-04032003><FONT 
      color=#0000ff><FONT face=Arial><SPAN 
      class=999194600-04032003>or</SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT></DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><SPAN 
      class=125442523-03032003><FONT size=2><SPAN class=684041700-04032003><FONT 
      color=#0000ff><FONT face=Arial><SPAN 
      class=999194600-04032003></SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><SPAN 
      class=125442523-03032003><FONT size=2><SPAN class=684041700-04032003><FONT 
      color=#0000ff><FONT face=Arial><SPAN class=999194600-04032003>&nbsp;b) 
      using a hacked up version of RSVP LSP setup to instantiate call state in 
      all of the nodes along a path from&nbsp;ingress node&nbsp;to egress 
      node.</SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT></DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><SPAN 
      class=125442523-03032003><FONT size=2><SPAN class=684041700-04032003><FONT 
      color=#0000ff><FONT face=Arial><SPAN 
      class=999194600-04032003></SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><SPAN 
      class=125442523-03032003><FONT size=2><SPAN class=684041700-04032003><FONT 
      color=#0000ff><FONT face=Arial><SPAN class=999194600-04032003>If it is the 
      former, then using Notify is better because it allows a capabilities 
      exchange prior to the allocation of any network resources.&nbsp; If it is 
      the latter, then using&nbsp;Notify is better because you are 
      creating&nbsp;severe interoperability problems with nodes that 
      understand&nbsp;GMPLS signalling but don't understand this hacked up 
      version of RSVP setup, in support of something which is supposed to be 
      an&nbsp;ingress/egress 
      node&nbsp;function.&nbsp;&nbsp;&nbsp;&nbsp;</SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT></DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><SPAN 
      class=125442523-03032003><FONT size=2><SPAN class=684041700-04032003><FONT 
      color=#0000ff><FONT face=Arial><SPAN 
      class=999194600-04032003>==========================================================================================================</SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT></DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><SPAN 
      class=125442523-03032003><FONT size=2><SPAN class=684041700-04032003><FONT 
      color=#0000ff><FONT face=Arial><SPAN 
      class=999194600-04032003></SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><SPAN 
      class=125442523-03032003><SPAN class=684041700-04032003><FONT 
      color=#0000ff><FONT face=Arial><FONT size=2><SPAN 
      class=999194600-04032003>&nbsp;</SPAN>For folks who wants to understand 
      call, you can read G.8080 (that&nbsp;ITU-T G. stuff again! )&nbsp;or 
      (*gasp!*) some of the ATM documents on call (Q.2981 I think).&nbsp;<SPAN 
      class=999194600-04032003><FONT 
      color=#000000>&nbsp;</FONT></SPAN></FONT></FONT></FONT></SPAN></SPAN></DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><SPAN 
      class=125442523-03032003><SPAN class=684041700-04032003><FONT 
      color=#0000ff><FONT face=Arial><FONT size=2><SPAN 
      class=999194600-04032003></SPAN></FONT></FONT></FONT></SPAN></SPAN><FONT 
      face=Tahoma><SPAN class=125442523-03032003><FONT size=2><SPAN 
      class=684041700-04032003><FONT face=Arial><SPAN 
      class=999194600-04032003></SPAN></FONT></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><SPAN 
      class=125442523-03032003><FONT size=2><SPAN class=684041700-04032003><FONT 
      face=Arial><FONT color=#0000ff><SPAN 
      class=999194600-04032003>==========================================================================================================</SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT></DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><SPAN 
      class=125442523-03032003><FONT size=2><SPAN class=684041700-04032003><FONT 
      face=Arial><FONT color=#0000ff><SPAN class=999194600-04032003>JD:&nbsp; As 
      I've said before, during my tenure at the ATM Forum, we could not get 
      call/connection separation to work in 
      PNNI.</SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT></DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><SPAN 
      class=125442523-03032003><FONT size=2><SPAN class=684041700-04032003><FONT 
      face=Arial><FONT color=#0000ff><SPAN 
      class=999194600-04032003>==========================================================================================================</SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT></DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><SPAN 
      class=125442523-03032003><FONT color=#0000ff><FONT face=Arial><FONT 
      size=2><SPAN class=999194600-04032003><FONT 
      color=#000000></FONT></SPAN></FONT></FONT></FONT></SPAN>&nbsp;</DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><SPAN 
      class=125442523-03032003><FONT color=#0000ff><FONT face=Arial><FONT 
      size=2><SPAN class=999194600-04032003>&nbsp;</SPAN>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??)<SPAN 
      class=999194600-04032003>&nbsp;</SPAN></FONT></FONT></FONT></SPAN></DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT size=2><SPAN 
      class=125442523-03032003><FONT color=#0000ff><FONT face=Arial><SPAN 
      class=999194600-04032003></SPAN></FONT></FONT></SPAN></FONT>&nbsp;</DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
      size=2><SPAN class=125442523-03032003>Thanks,</SPAN></FONT></FONT></DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
      size=2><SPAN class=125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
      size=2><SPAN class=125442523-03032003>John</SPAN></FONT></FONT></DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
      size=2><SPAN class=125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
      size=2>-----Original Message-----<BR><B>From:</B> Zhi-Wei Lin 
      [mailto:zhiweilin@yahoo.com]<BR><B>Sent:</B> Sunday, March 02, 2003 11:21 
      AM<BR><B>To:</B> mpls@uu.net<BR><B>Cc:</B> John Drake<BR><B>Subject:</B> 
      Re: FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
      <BR><BR></FONT></DIV></DIV>
      <BLOCKQUOTE 
      style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
        <P>Hi John, 
        <P>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? 

        <P>Thanks<BR>Zhi 
        <P>
        <P>&nbsp;From: John Drake [mailto:jdrake@calient.net]<BR>Sent: Friday, 
        February 28, 2003 4:15 PM<BR>To: 'erosen@cisco.com'; Varma, Eve L 
        (Eve)<BR>Cc: 'curtis@fictitious.org'; George Newsome; Stephen 
        Trowbridge; Loa<BR>Andersson; mpls@UU.NET<BR>Subject: RE: I-D 
        ACTION:draft-andersson-mpls-g-chng-proc-00.txt <BR><BR><BR>I agree with 
        Eric.<BR><BR>As an example, we have call/connection separation, which 
        has been kicking<BR>around since the early days of ISDN. In discussions 
        as to why it is needed,<BR>the first reason is always "because". Once 
        past that, I have consistently<BR>heard four or five examples cited. 
        What is interesting is that all of them<BR>can be handled with the 
        existing Make Before Break component of RSVP-TE. 
        <BR><BR>Thanks,<BR><BR>John<BR><BR>&gt; -----Original 
        Message-----<BR>&gt; From: Eric Rosen [mailto:erosen@cisco.com]<BR>&gt; 
        Sent: Friday, February 28, 2003 12:54 PM<BR>&gt; To: Varma, Eve L 
        (Eve)<BR>&gt; Cc: 'curtis@fictitious.org'; George Newsome; Stephen 
        Trowbridge; Loa<BR>&gt; Andersson; mpls@UU.NET<BR>&gt; Subject: Re: I-D 
        ACTION:draft-andersson-mpls-g-chng-proc-00.txt <BR>&gt; <BR>&gt; 
        <BR>&gt; <BR>&gt; Eve&gt; For individual contributor drafts coming in, 
        it's quite <BR>&gt; appropriate to<BR>&gt; Eve&gt; evaluate requirements 
        and determine if they are <BR>&gt; legitimate. It's a<BR>&gt; Eve&gt; 
        different case when another SDO, responsible for a <BR>&gt; non-IP 
        applications<BR>&gt; Eve&gt; domain, has established a set of 
        requirements related to <BR>&gt; that domain.<BR>&gt; <BR>&gt; I'd 
        certainly disagree with that. Many of the <BR>&gt; "requirements" I see 
        from<BR>&gt; other organizations are not requirements at all, but 
        <BR>&gt; just dogmatic<BR>&gt; statements of connection-oriented 
        religion. If the IETF <BR>&gt; were to accept<BR>&gt; requirements from 
        other organizations, it would quickly be <BR>&gt; inundated with<BR>&gt; 
        "requirements" to make IP behave exactly like ATM. In <BR>&gt; fact, 
        anyone who<BR>&gt; works in the PWE3 group can testify that such 
        "requirements" <BR>&gt; come in all the<BR>&gt; time. <BR>&gt; <BR>&gt; 
        <BR>&gt; </P>
        <P><BR>
        <HR SIZE=1>
        Do you Yahoo!?<BR><A 
        href="http://rd.yahoo.com/finance/mailtagline/*http://taxes.yahoo.com/">Yahoo! 
        Tax Center</A> - forms, calculators, tips, and 
  more</BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_owFHvRANZoymFcK8E0zriQ)--


From owner-mpls@UU.NET  Mon Mar  3 22:24:57 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22235
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 22:24:57 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemv20197
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 03:26:59 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoemv20040;
	Tue, 4 Mar 2003 03:26:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoemu05077
	for mpls-outgoing; Tue, 4 Mar 2003 03:00:27 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoemu04081
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 03:00:15 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoemt18028
	for <mpls@UU.NET>; Tue, 4 Mar 2003 02:58:33 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemt24152
	for <mpls@UU.NET>; Tue, 4 Mar 2003 02:58:33 GMT
Received: from smtp.comcast.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp.comcast.net [24.153.64.2])
	id QQoemt24143
	for <mpls@UU.NET>; Tue, 4 Mar 2003 02:58:32 GMT
Received: from LINPORTEGE
 (pcp03191818pcs.midltn01.nj.comcast.net [68.36.136.113])
 by mtaout05.icomcast.net
 (iPlanet Messaging Server 5.2 HotFix 1.09 (built Jan  7 2003))
 with SMTP id <0HB700G86EW2P3@mtaout05.icomcast.net> for mpls@UU.NET; Mon,
 03 Mar 2003 21:57:39 -0500 (EST)
Date: Mon, 03 Mar 2003 21:57:25 -0500
From: Zhi-Wei Lin <zwlin@comcast.net>
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
In-reply-to: <200303040213.VAA84999@workhorse.fictitious.org>
To: curtis@fictitious.org
Cc: mpls@UU.NET
Message-id: <000501c2e1f9$ca231bc0$6e00a8c0@na01.lucent.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7BIT

Hi Curtis,

Wow! What a position. Anyway, getting to some of your technical comments,
the ASON and just like the GMPLS is probably most useful at lower granular
signals where there are more churn and requests and therefore an automated
systems more useful. The original intent may be for optical OC-48 and above,
but (G)MPLS is supposed to be applied to everything under the sun, including
VT1.5/VC-11 signals.

Now getting to your other comments that would incite a lot of religious
discussions (and polarize folks)...your statement "In fact it is the
call/connection telcos that are having the severe financial woes" I thought
was interesting. Talking to some folks who works in the operating companies
lead me to believe that the root of the current crisis in the telecom
industry is that the operators have no way to build a profitable business
model. This is because they cannot charge for IP "services", but can only
bill on a flat rate for IP. And it's because of the broken IP business model
that they are in financial meltdown mode. Yes, the antiquated PSTN service
is suffering because of this, and people can say this is because the PSTN
business model is broken, but I prefer to think that the PSTN is a colateral
damage to the broken IP business model...

Of course the other heart of the current problem is the sudden dramatic
expansion of the capacity and services from many many many CLECs that
saturated the market with the same type of service offerings causing this
current meltdown in price and thus profitable revenue. None of this has to
do with a broken call/connection model. In fact my believe is that once a
service model is instituted on the IP world, operators will start to gain
traction in the business model front as well...of course we would never
stand for such draconian measure (after all, why should the RBOCs and PTTs
make any money?? they're dinosaurs who deserve to go extinct!! ;-)

As always, flames are very unwelcome, but I'm sure I'll get some with what I
said above... :-(

Looking forward to your reply!
Zhi



> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@fictitious.org]
> Sent: Monday, March 03, 2003 9:14 PM
> To: Zhi-Wei Lin
> Cc: 'John Drake'; 'Zhi-Wei Lin'; mpls@UU.NET
> Subject: Re: FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
>
>
> In message <004901c2e1e4$e32f5bc0$6e00a8c0@na01.lucent.com>,
> Zhi-Wei Lin writes
> :
> >
> > 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. 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.
> >
> >
> >   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.
> >
> >   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... ;-) 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). 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??)
>
>
> Zhi,
>
> MPLS is used for traffic engineering and is applied mostly to OC48c
> and OC192c cores, though maybe extending out to OC12c and OC3c fringes
> of a provider's network.  These MPLS LSP are not "calls".  They are
> not customer "connections" of any kind.  GMPLS applies to even larger
> aggregations of bandwidth when applied to optical (its orgiginal
> purpose).
>
> > keep a connection alive for, e.g., billing purposes, and
> having a single
>
> This is the heart of the call/connection argument.  It didn't fly in
> the early 1990s.  The Internet didn't implode because there was no way
> to do per connection billing.  In fact it is the call/connection
> telcos that are having the severe financial woes.  Those that own IP
> operations (and virtually all do) generally have profitable IP
> divisions.  Leased and switched services are declining while end
> system encrypted VPN and provider VPN are growing.  Voice is becoming
> flat rate.  Email and IM are clearly not call/connection oriented
> unless you consider TCP to be call/connection.  Add voice to IM and
> break through the last mile bandwidth monopoly and we wouldn't even
> need the PSTN and its call/connection model, the last remnants of a
> legacy technology whose demise began in 1984.
>
> FR, SMDS, and ATM provided customer connections.  FR is still used for
> low speed customer circuits, VPNs, etc.  SMDS is dead.  ATM SVC
> services had virtually ZERO penetration at its peak and what little it
> had was at low bandwidths.
>
> ATM had some brief success as a core technology but 100% of that was
> PVC or SPVC.  The reason we have MPLS is there were some things about
> ATM that the IETF regarded as very broken.  The people that regarded
> it as very broken were the very poeple running among the highest
> capacity ATM deploymennts in the world, all running IP over ATM SPVCs.
>
> What you are trying to do is bring some of the call/connection
> brokenness that was rejected in the mid to late 1990s back into MPLS
> after ATM failed in the market.
>
> If you want to reminisce about the Q.2931 connection model go to the
> ATM Forum and reminisce.  The Q.2931 model is dead in the IETF, always
> has been, always will be.  The ATM Forum loves Q.2931 and they'd love
> G.8080 since it is of the same mindset.  Please go away and use PNNI.
>
> Curtis



From owner-mpls@UU.NET  Mon Mar  3 23:22:38 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23288
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 23:22:38 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemz23354
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 04:24:40 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoemz23180;
	Tue, 4 Mar 2003 04:24:33 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoemx22972
	for mpls-outgoing; Tue, 4 Mar 2003 03:58:53 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoemx22967
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 03:58:49 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoemx28849
	for <mpls@uu.net>; Tue, 4 Mar 2003 03:58:06 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemx16383
	for <mpls@uu.net>; Tue, 4 Mar 2003 03:58:05 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoemx16375
	for <mpls@uu.net>; Tue, 4 Mar 2003 03:58:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h243w2Nh002926
	for <mpls@uu.net>; Mon, 3 Mar 2003 22:58:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA00629 for <mpls@uu.net>; Mon, 3 Mar 2003 22:58:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h243w2p04718 for mpls@uu.net; Mon, 3 Mar 2003 22:58:02 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoemx22944
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 03:57:25 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoemx15554
	for <mpls@UU.NET>; Tue, 4 Mar 2003 03:57:13 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemx10464
	for <mpls@UU.NET>; Tue, 4 Mar 2003 03:57:13 GMT
Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoemx10419
	for <mpls@UU.NET>; Tue, 4 Mar 2003 03:57:11 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id WAA85708;
	Mon, 3 Mar 2003 22:55:16 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303040355.WAA85708@workhorse.fictitious.org>
To: Zhi-Wei Lin <zwlin@comcast.net>
cc: curtis@fictitious.org, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
In-reply-to: Your message of "Mon, 03 Mar 2003 21:57:25 EST."
             <000501c2e1f9$ca231bc0$6e00a8c0@na01.lucent.com> 
Date: Mon, 03 Mar 2003 22:55:16 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <000501c2e1f9$ca231bc0$6e00a8c0@na01.lucent.com>, Zhi-Wei Lin writes
:
> Hi Curtis,
> 
> Wow! What a position. Anyway, getting to some of your technical comments,
> the ASON and just like the GMPLS is probably most useful at lower granular
> signals where there are more churn and requests and therefore an automated
> systems more useful. The original intent may be for optical OC-48 and above,
> but (G)MPLS is supposed to be applied to everything under the sun, including
> VT1.5/VC-11 signals.

MPLS so far has been applied to TE at mostly OC48c and OC192c.  I'm
sure there is an interney-draft somewhere to apply MPLS to the
microprocessor in my coffee maker but I don't see it happenning.

> Now getting to your other comments that would incite a lot of religious
> discussions (and polarize folks)...your statement "In fact it is the
> call/connection telcos that are having the severe financial woes" I thought
> was interesting. Talking to some folks who works in the operating companies
> lead me to believe that the root of the current crisis in the telecom
> industry is that the operators have no way to build a profitable business
> model. This is because they cannot charge for IP "services", but can only
> bill on a flat rate for IP. And it's because of the broken IP business model
> that they are in financial meltdown mode. Yes, the antiquated PSTN service
> is suffering because of this, and people can say this is because the PSTN
> business model is broken, but I prefer to think that the PSTN is a colateral
> damage to the broken IP business model...

The IP business is profitable for many.  The PSTN is suffering because
of the competition from IP and competition from elsewhere.

Back in the mid to late 1990s the largest and most profitable IP
providers were bought by carrier that were loaded with cash from their
near-monopoly business.  They couldn't trash the IP businesses they
bought because others remained to compete against them so they ended
up undercutting themselves.  They still had the eroding voice business
to weight them down.

There is nothing wrong with voice as a service.  It is just that if
there is a competative market, you can only milk a tenth of the profit
out of the voice business that the big telcos made in the late 80s and
early 90s and remain competative.  For example, the new Worldcom will
very likely emerge smaller and it looks like with a flat rate voice
model.  Not much seems to be changing in the IP side of the house
which was still healthy and growing at an impressive rate until the
rest of the company dragged it along into the bankrupcy court.

> Of course the other heart of the current problem is the sudden dramatic
> expansion of the capacity and services from many many many CLECs that
> saturated the market with the same type of service offerings causing this
> current meltdown in price and thus profitable revenue. None of this has to
> do with a broken call/connection model. In fact my believe is that once a
> service model is instituted on the IP world, operators will start to gain
> traction in the business model front as well...of course we would never
> stand for such draconian measure (after all, why should the RBOCs and PTTs
> make any money?? they're dinosaurs who deserve to go extinct!! ;-)

The saturation that you are speaking of was at the transport level.
Many IP providers have been unable to make capital expenditures due to
the parent company problems and have capacity concerns either eminent
of on the near term horizon.

The fast provisioning promise of optical switching produced near
nothing over plain ol' WDM in terms of revenue or operational savings.
Switched services is declining and growth of leased line is slow and
may be driven largely by IP tail circuits.

According to some people the logical next step to rebuild the
transport business based on a model that just failed.  :-)
IP is still making money and the business is growning.

btw- If we didn't have a monopoly bottleneck at the last mile in the
US more of that overbuilt transport would be in use but that is a
political issue that is out of scope for IETF or SDOs in general.

> As always, flames are very unwelcome, but I'm sure I'll get some with what I
> said above... :-(
> 
> Looking forward to your reply!
> Zhi

Why.  Do you think you have some sort of compelling argument?

Quite frankly at this point I think we are wasting everyones time
including our own so lets just agree to disagree and follow Scott
Bradner's lead and leave liason completely out of Loa's draft and
address it separately, elsewhere.

Curtis



From owner-mpls@UU.NET  Tue Mar  4 00:05:35 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24080
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 00:05:34 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoenc20028
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 05:07:36 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoenc19644;
	Tue, 4 Mar 2003 05:07:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoena13844
	for mpls-outgoing; Tue, 4 Mar 2003 04:41:29 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoena13839
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 04:41:20 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoena14606
	for <mpls@uu.net>; Tue, 4 Mar 2003 04:41:05 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoena23636
	for <mpls@uu.net>; Tue, 4 Mar 2003 04:41:04 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoena23625
	for <mpls@uu.net>; Tue, 4 Mar 2003 04:41:04 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h244f2JR003823
	for <mpls@uu.net>; Mon, 3 Mar 2003 23:41:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id XAA02161 for <mpls@uu.net>; Mon, 3 Mar 2003 23:41:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h244f1m08866 for mpls@uu.net; Mon, 3 Mar 2003 23:41:01 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoena13632
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 04:39:38 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoena19547
	for <mpls@uu.net>; Tue, 4 Mar 2003 04:39:19 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoena19475
	for <mpls@uu.net>; Tue, 4 Mar 2003 04:39:18 GMT
Received: from pqhy by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [202.88.151.67])
	id QQoena19153
	for <mpls@uu.net>; Tue, 4 Mar 2003 04:39:07 GMT
From: Terminiate It <Terminiateyxpg@ibm.com>
To: <mpls@UU.NET>
Subject: Avoid bankruptcy ol
Date: Mon, 03 Mar 2003 15:39:59 -0500
Mime-Version: 1.0
Content-Type: text/html
Content-Transfer-Encoding: base64
Message-Id: <kuwgxmxfdcpyf@ibm.com>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5leHZucHBub2V5ZWpoanh2YmlxeHJvbnB2c3RtcmJy
eHlvbnFlZGdrPC90aXRsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IiNGRkZGRkYiPg0K
PGZvbnQgZmFjZT1WZXJkYW5hIHNpemU9Mj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cubXBsc0Bk
ZWJ0LXBsYW5uaW5nLmNvbS8/YWZmaWQ9bzg4OCZlPW1wbHNAdXUubmV0Ij48aW1nDQpzcmM9
Imh0dHA6Ly9tcGxzQDE0NC4xNzYuNTAuMTIyLzQyNXg1MDBfYWRzLmpwZyIgYm9yZGVyPTAg
d2lkdGg9NDI1IGhlaWdodD01MDA+PC9hPg0KPHA+Jm5ic3A7PC9wPg0KPHA+LS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cu
bXBsc0BkZWJ0LXBsYW5uaW5nLmNvbS9yLz9lPW1wbHNAdXUubmV0Ij48aW1nDQpzcmM9Imh0
dHA6Ly8xNDQuMTc2LjUwLjEyMi9yZS5naWYiIGJvcmRlcj0wIHdpZHRoPTIwOSBoZWlnaHQ9
MjA+PC9hPjxicj5leHZucHBub2V5ZWpoanh2YmlxeHJvbnB2c3RtcmJyeHlvbnFlZGdrLDxi
cj5BcHBsaWNhbnQgaW50ZXJydXB0ZWQgaW50ZXJ2aWV3IHRvIHBob25lIGhlciB0aGVyYXBp
c3QgZm9yIGFkdmljZSBvbiBob3cgdG8gYW5zd2VyIHNwZWNpZmljIGludGVydmlldyBxdWVz
dGlvbnMuLDxicj5gQnV0IGxvb2sgeW91IGZvdW5kIHRoZSBub3RpY2UgZGlkbid0IHlvdT8n
PC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K



From owner-mpls@UU.NET  Tue Mar  4 01:27:00 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25905
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 01:27:00 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoenh07814
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 06:29:01 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoenh07656;
	Tue, 4 Mar 2003 06:28:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeng19335
	for mpls-outgoing; Tue, 4 Mar 2003 06:02:30 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoeng18983
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 06:02:27 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoeng17701
	for <mpls@UU.NET>; Tue, 4 Mar 2003 06:01:48 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeng23343
	for <mpls@UU.NET>; Tue, 4 Mar 2003 06:01:47 GMT
Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQoeng23320
	for <mpls@UU.NET>; Tue, 4 Mar 2003 06:01:46 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2461kS47395;
	Mon, 3 Mar 2003 22:01:46 -0800 (PST)
	(envelope-from kireeti@juniper.net)
Received: from localhost (kireeti@localhost)
	by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h2461kr53342;
	Mon, 3 Mar 2003 22:01:46 -0800 (PST)
	(envelope-from kireeti@juniper.net)
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
Date: Mon, 3 Mar 2003 22:01:46 -0800 (PST)
From: Kireeti Kompella <kireeti@juniper.net>
To: Zhi-Wei Lin <zwlin@comcast.net>
cc: mpls@UU.NET
Subject: a propos of nothing at all ...
In-Reply-To: <000501c2e1f9$ca231bc0$6e00a8c0@na01.lucent.com>
Message-ID: <20030303214755.S53165@kummer.juniper.net>
References: <000501c2e1f9$ca231bc0$6e00a8c0@na01.lucent.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Zhi,

On Mon, 3 Mar 2003, Zhi-Wei Lin wrote:

> Now getting to your other comments that would incite a lot of religious
> discussions (and polarize folks)...your statement "In fact it is the
> call/connection telcos that are having the severe financial woes" I thought
> was interesting. Talking to some folks who works in the operating companies
> lead me to believe that the root of the current crisis in the telecom
> industry is that the operators have no way to build a profitable business
> model. This is because they cannot charge for IP "services", but can only
> bill on a flat rate for IP.

I agree with you that this is interesting -- even if completely unrelated
to CCAMP.

I pay flat rate for my local service.  I see a tentative move towards
flat rate for long distance; my cell phone bill is essentially flat
rate (I pay for more minutes than I would ever use per month.)  Of
course, I pay flat rate for my DSL (thanks to which you get this
message :-))

1) Assume the world is moving towards flat rate billing (big IF), would
   call and connection separation still be a requirement?

2) While GMPLS could be used down to the T1 and DS0 level, suppose
   for a minute that its use was restricted to OC12 and above.
   Would call and connection separation still be a requirement?

Thanks for your insights,
Kireeti.


From owner-mpls@UU.NET  Tue Mar  4 01:50:10 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26461
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 01:50:10 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemb07125
	for <mpls-archive@lists.ietf.org>; Mon, 3 Mar 2003 22:28:47 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoemb04986;
	Mon, 3 Mar 2003 22:27:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoemb02685
	for mpls-outgoing; Mon, 3 Mar 2003 22:27:15 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoemb02676
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 22:27:00 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoemb29421
	for <mpls@UU.NET>; Mon, 3 Mar 2003 22:26:09 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemb12775
	for <mpls@UU.NET>; Mon, 3 Mar 2003 22:26:08 GMT
Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQoemb12752
	for <mpls@UU.NET>; Mon, 3 Mar 2003 22:26:07 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h23MQ7S19627;
	Mon, 3 Mar 2003 14:26:07 -0800 (PST)
	(envelope-from kireeti@juniper.net)
Received: from localhost (kireeti@localhost)
	by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h23MQ6A51686;
	Mon, 3 Mar 2003 14:26:07 -0800 (PST)
	(envelope-from kireeti@juniper.net)
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
Date: Mon, 3 Mar 2003 14:26:06 -0800 (PST)
From: Kireeti Kompella <kireeti@juniper.net>
To: Stephen Trowbridge <sjtrowbridge@lucent.com>
cc: ccamp@ops.ietf.org, "" <mpls@UU.NET>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
In-Reply-To: <3E638C95.167731F8@lucent.com>
Message-ID: <20030303140750.W51425@kummer.juniper.net>
References: <200303031648.h23GmwJO003841@newdev.harvard.edu>
 <3E638C95.167731F8@lucent.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

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.

That said, if liaisons truly have lower priority than individual IDs,
it is more the vehicle (emails, notes posted to the liaison web page,
etc.) than the source or the content.  One the advice of a wise person,
I have started (belatedly) posting to the CCAMP list that such liaisons
exist.  Note that I don't need to do that for IDs -- the authors generally
do that, and there is a mailing list that one can subscribe for this.

> But it is my opinion that the lack of a liaison process is really
> the ROOT CAUSE of difficulties like what we saw in January.

If we really do a root cause analysis, it comes down to this (IMO):
a) CCAMP gets a liaison statement stating that certain changes are
   requested in the GMPLS specs (doesn't get posted to the list, though).
b) CCAMP doesn't officially respond (mechanisms not in place).
c) CCAMP WG gets requirements via Zhi's and Osama's drafts.
d) CCAMP mailing list hosts discussions about whether these requirements
   make sense in the IETF context.
e) In the interest of quick allocation of code points, these two docs
   are made Informational, and go through without much review.
f) Various folks (CCAMP, RSVP, MPLS, ...) are very concerned about the
   changes made to RSVP and CR-LDP.

(The intent here is not to point fingers, although I've already claimed
my share of the blame.)

I see (b) and (e) as the most serious breakdowns in the process.  The
GMPLS change doc should help alleviate (e), and hopefully help (a) as
well.  And if we get started on the liaison doc, that should help (b).

Or we could keep talking :-)

Kireeti.


From owner-mpls@UU.NET  Tue Mar  4 05:32:01 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11471
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 05:32:01 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeny15595
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 10:34:03 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeny15402;
	Tue, 4 Mar 2003 10:33:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoenw21196
	for mpls-outgoing; Tue, 4 Mar 2003 10:08:18 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoenw21191
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 10:08:14 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoenw16757
	for <mpls@UU.NET>; Tue, 4 Mar 2003 10:08:07 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoenw21727
	for <mpls@UU.NET>; Tue, 4 Mar 2003 10:08:06 GMT
Received: from bt0g2p.god.bel.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alc136.alcatel.be [195.207.101.136])
	id QQoenw21699
	for <mpls@UU.NET>; Tue, 4 Mar 2003 10:08:05 GMT
Received: from bemail05.net.alcatel.be (relay3 [127.0.0.1])
	by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id h24A84P08100
	for <mpls@UU.NET>; Tue, 4 Mar 2003 11:08:04 +0100
Received: from alcatel.be ([138.203.64.155])
          by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11)
          with ESMTP id 2003030411080195:1819 ;
          Tue, 4 Mar 2003 11:08:01 +0100 
Message-ID: <3E647AC8.FB3B45DD@alcatel.be>
Date: Tue, 04 Mar 2003 11:07:04 +0100
From: Dimitri.Papadimitriou@alcatel.be
Organization: optical network architecture (nta - antwerpen)
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Zhi-Wei Lin <zwlin@comcast.net>
Cc: "'John Drake'" <jdrake@calient.net>, mpls@UU.NET
Subject: Re: FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <000001c2e1f7$e5f84520$6e00a8c0@na01.lucent.com>
X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 03/04/2003 11:08:02,
	Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 03/04/2003 11:08:04,
	Serialize complete at 03/04/2003 11:08:04
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

zhi,

see in-line with [DP]

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.

[DP] the same kind of arguments you're using since day one
     and i am not sure it has help in progressing the debate
     ... i should probably say they are many ways to cook it
     and for the time being your carrot is crude

What you've specified using the Notify probably works just as well. 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. 
[DP] so if i well understand what's today in the info rfc
     doesn't deliver what it claims to do ?

This is because not all technical issues have been resolved. 

[DP] and this is why a discussion with the wg is always better
     than going alone with a partial solution

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. 

Thanks for your comments! Definitely helps to identify what different
methods there are to solve the same problem.

[DP] as usual you escape the problem instead of solving it
you are using a hacked up version of RSVP LSP setup for 
instantiating the call state in all of the nodes along a
path from ingress node to egress node before establishing
the connection clearly what happens if one of the nodes
in between doesn't support your info rfc ?

-- 
Papadimitriou Dimitri 
E-mail : dimitri.papadimitriou@alcatel.be 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491


From owner-mpls@UU.NET  Tue Mar  4 06:26:38 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12841
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 06:26:38 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeob03570
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 11:28:41 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeob03509;
	Tue, 4 Mar 2003 11:28:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeoa00743
	for mpls-outgoing; Tue, 4 Mar 2003 11:00:51 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoeoa29332
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 11:00:40 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoeoa23425
	for <mpls@UU.NET>; Tue, 4 Mar 2003 11:00:26 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeoa13085
	for <mpls@UU.NET>; Tue, 4 Mar 2003 11:00:25 GMT
Received: from bt0g2p.god.bel.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alc136.alcatel.be [195.207.101.136])
	id QQoeoa13062
	for <mpls@UU.NET>; Tue, 4 Mar 2003 11:00:24 GMT
Received: from bemail05.net.alcatel.be (relay3 [127.0.0.1])
	by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id h24B0Io20985;
	Tue, 4 Mar 2003 12:00:18 +0100
Received: from alcatel.be ([138.203.64.155])
          by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11)
          with ESMTP id 2003030412001674:2117 ;
          Tue, 4 Mar 2003 12:00:16 +0100 
Message-ID: <3E648707.1CBDC106@alcatel.be>
Date: Tue, 04 Mar 2003 11:59:19 +0100
From: Dimitri.Papadimitriou@alcatel.be
Organization: optical network architecture (nta - antwerpen)
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Zhi-Wei Lin <zwlin@comcast.net>
Cc: "'John Drake'" <jdrake@calient.net>, "'Zhi-Wei Lin'" <zhiweilin@yahoo.com>,
        mpls@UU.NET
Subject: Re: FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <004901c2e1e4$e32f5bc0$6e00a8c0@na01.lucent.com>
X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 03/04/2003 12:00:16,
	Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 03/04/2003 12:00:17,
	Serialize complete at 03/04/2003 12:00:17
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

zhi,

see comments in-line [DP]

---

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

[DP] if it was to name sessions why not simply use the session
name of the session attribute object ?

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.
        
[DP] let's be a bit more inventive here, admin status object
with its flags has been defined for that purpose was it really
impossible to use it here ?

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.
       
[DP] this problem was known w/i the ccamp community since begin'01
this is also the reason why "lbm stuff" has been proposed to fully
cover virtual concatenation
 
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... ;-) 

[DP] i have a problem here, it seems that proposed extensions 
have been proposed to cover a concept rather than really 
translating an implementation need, would be more than useful
for the ccamp community that you clearly mean by service here

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). 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??)

[DP] Q.2982, but it is clear that the higher the granularity
less this call concept will be interesting, and the smaller
the network less this concept will be interesting in addition 
for atm networks this concept hasn't been widely used, the 
question is that there are no clear evidence that it won't
be the case with sdh networks as well ... dimitri.
        
       Thanks,
        
       John
      
-- 
Papadimitriou Dimitri 
E-mail : dimitri.papadimitriou@alcatel.be 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491


From owner-mpls@UU.NET  Tue Mar  4 06:33:00 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13018
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 06:33:00 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeoc11494
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 11:35:03 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeoc11310;
	Tue, 4 Mar 2003 11:34:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeoa12848
	for mpls-outgoing; Tue, 4 Mar 2003 11:07:37 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoeoa12843
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 11:07:34 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoeoa14467
	for <mpls@UU.NET>; Tue, 4 Mar 2003 11:07:22 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeoa26430
	for <mpls@UU.NET>; Tue, 4 Mar 2003 11:07:20 GMT
Received: from bt0g2p.god.bel.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alc136.alcatel.be [195.207.101.136])
	id QQoeoa26195
	for <mpls@UU.NET>; Tue, 4 Mar 2003 11:07:14 GMT
Received: from bemail05.net.alcatel.be (relay3 [127.0.0.1])
	by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id h24B75A22882;
	Tue, 4 Mar 2003 12:07:05 +0100
Received: from alcatel.be ([138.203.64.155])
          by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11)
          with ESMTP id 2003030412070262:2149 ;
          Tue, 4 Mar 2003 12:07:02 +0100 
Message-ID: <3E64889E.17DAC6E@alcatel.be>
Date: Tue, 04 Mar 2003 12:06:06 +0100
From: Dimitri.Papadimitriou@alcatel.be
Organization: optical network architecture (nta - antwerpen)
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Zhi-Wei Lin <zwlin@comcast.net>
Cc: "'Kireeti Kompella'" <kireeti@juniper.net>,
        "'Stephen Trowbridge'" <sjtrowbridge@lucent.com>, ccamp@ops.ietf.org,
        mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <004601c2e1e2$25a90e90$6e00a8c0@na01.lucent.com>
X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 03/04/2003 12:07:02,
	Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 03/04/2003 12:07:05,
	Serialize complete at 03/04/2003 12:07:05
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

zhi,

let's be very clear here, intent was to gather feedback
from the ccamp community during the yokohama meeting, i
have to say that the achieved consensus (as previously
explained was more than satisfactory imho) when you have
decided to go on the info track it has been based on the
expectation to get code points on time, now that you have
received them, i more than strongly suggest that you put 
this document over the table and that we discuss it... at 
the end i've got the impression that you don't want to 
discuss it at all anymore... is there something to hide 
here ?

ps: some of the critical oif players you refer in your
below e-mail are seriously questioning what has been done
over time ... and from this perspective only implementation
will decide about the relevance of these extensions

thanks,
- dimitri.

Zhi-Wei Lin wrote:
> 
> Hi Kireeti,
> 
> Just responding to your point (e) below. As someone pointed out in some
> previous email exchanges (seems like an age ago), when I submitted my I-D
> around the June timeframe, the IETF CCAMP WG were not particularly
> interested. However, I did work with and gotten quite good feedback
> privately. Among the folks were Adrian, Jerry, Dimitrios, Dimitri, Nick,
> Greg, Lyndon, Bala, Yangguang. Of course not everyone agreed with some of
> the particular solution but I don't think anyone questioned that there were
> technical issues with it...
> 
> And also as someone pointed out, many of the critical players in the GMPLS
> arena were also players in the OIF. I think the root cause is maybe not the
> liaison process but the intent of people working in the topic area? Just a
> guess...
> 
> Thanks
> Zhi
> 
> > -----Original Message-----
> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Kireeti
> > Kompella
> > Sent: Monday, March 03, 2003 5:26 PM
> > To: Stephen Trowbridge
> > Cc: ccamp@ops.ietf.org; mpls@UU.NET
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> >
> > 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.
> >
> > That said, if liaisons truly have lower priority than individual IDs,
> > it is more the vehicle (emails, notes posted to the liaison web page,
> > etc.) than the source or the content.  One the advice of a
> > wise person,
> > I have started (belatedly) posting to the CCAMP list that
> > such liaisons
> > exist.  Note that I don't need to do that for IDs -- the
> > authors generally
> > do that, and there is a mailing list that one can subscribe for this.
> >
> > > But it is my opinion that the lack of a liaison process is really
> > > the ROOT CAUSE of difficulties like what we saw in January.
> >
> > If we really do a root cause analysis, it comes down to this (IMO):
> > a) CCAMP gets a liaison statement stating that certain changes are
> >    requested in the GMPLS specs (doesn't get posted to the
> > list, though).
> > b) CCAMP doesn't officially respond (mechanisms not in place).
> > c) CCAMP WG gets requirements via Zhi's and Osama's drafts.
> > d) CCAMP mailing list hosts discussions about whether these
> > requirements
> >    make sense in the IETF context.
> > e) In the interest of quick allocation of code points, these two docs
> >    are made Informational, and go through without much review.
> > f) Various folks (CCAMP, RSVP, MPLS, ...) are very concerned about the
> >    changes made to RSVP and CR-LDP.
> >
> > (The intent here is not to point fingers, although I've
> > already claimed
> > my share of the blame.)
> >
> > I see (b) and (e) as the most serious breakdowns in the process.  The
> > GMPLS change doc should help alleviate (e), and hopefully help (a) as
> > well.  And if we get started on the liaison doc, that should help (b).
> >
> > Or we could keep talking :-)
> >
> > Kireeti.

-- 
Papadimitriou Dimitri 
E-mail : dimitri.papadimitriou@alcatel.be 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491


From owner-mpls@UU.NET  Tue Mar  4 08:01:10 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17723
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 08:01:10 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeoi26337
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 13:03:11 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeoi26225;
	Tue, 4 Mar 2003 13:03:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeog06915
	for mpls-outgoing; Tue, 4 Mar 2003 12:33:21 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoeog06909
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 12:33:17 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoeog06257
	for <mpls@uu.net>; Tue, 4 Mar 2003 12:33:07 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeog11772
	for <mpls@uu.net>; Tue, 4 Mar 2003 12:33:06 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoeog11748
	for <mpls@uu.net>; Tue, 4 Mar 2003 12:33:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h24CX2JR023626
	for <mpls@uu.net>; Tue, 4 Mar 2003 07:33:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA23632 for <mpls@uu.net>; Tue, 4 Mar 2003 07:33:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h24CX2403341 for mpls@uu.net; Tue, 4 Mar 2003 07:33:02 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoeog06860
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 12:31:43 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoeog28619
	for <mpls@uu.net>; Tue, 4 Mar 2003 12:31:17 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeog08385
	for <mpls@uu.net>; Tue, 4 Mar 2003 12:31:16 GMT
Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQoeog08312
	for <mpls@uu.net>; Tue, 4 Mar 2003 12:31:14 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14820;
	Tue, 4 Mar 2003 07:29:11 -0500 (EST)
Message-Id: <200303041229.HAA14820@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-lsp-query-06.txt
Date: Tue, 04 Mar 2003 07:29:11 -0500
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title		: Multi Protocol Label Switching Label Distribution 
                          Protocol Query Message Description
	Author(s)	: P. Ashwood-Smith, A. Paraschiv
	Filename	: draft-ietf-mpls-lsp-query-06.txt
	Pages		: 19
	Date		: 2003-3-3
	
This document describes the encoding and procedures for three new
Label Distribution Protocol (LDP) messages: Query Message, Query-
Reply Message and Partial Query-Reply Message (the last one is almost
identical to the Query-Reply message; therefore all references to the
Query-Reply messages imply the Partial Query-Reply messages as well,
unless otherwise specified).  A Lable Edge Router (LER) sends a Query
message when it needs to find out information about a Label Switched
Path (LSP). The Query message is sent for an established LSP.  The
Query message can be used for LDP LSPs as well as for Constraint-
Based Label Switched Paths (CR-LSPs).  The queried data is encoded
into the Query-Reply messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-query-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-lsp-query-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-lsp-query-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-3-3144934.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-lsp-query-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-lsp-query-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-3-3144934.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Tue Mar  4 08:01:12 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17737
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 08:01:12 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeoi26483
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 13:03:13 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeoi26260;
	Tue, 4 Mar 2003 13:03:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeog06918
	for mpls-outgoing; Tue, 4 Mar 2003 12:33:24 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoeog06910
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 12:33:18 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoeog06290
	for <mpls@uu.net>; Tue, 4 Mar 2003 12:33:07 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeog11773
	for <mpls@uu.net>; Tue, 4 Mar 2003 12:33:06 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoeog11750
	for <mpls@uu.net>; Tue, 4 Mar 2003 12:33:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h24CX2JR023628
	for <mpls@uu.net>; Tue, 4 Mar 2003 07:33:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA23634 for <mpls@uu.net>; Tue, 4 Mar 2003 07:33:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h24CX2P03348 for mpls@uu.net; Tue, 4 Mar 2003 07:33:02 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoeog06858
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 12:31:42 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoeog26335
	for <mpls@uu.net>; Tue, 4 Mar 2003 12:31:10 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeog08222
	for <mpls@uu.net>; Tue, 4 Mar 2003 12:31:10 GMT
Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQoeog08204
	for <mpls@uu.net>; Tue, 4 Mar 2003 12:31:09 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14782;
	Tue, 4 Mar 2003 07:29:07 -0500 (EST)
Message-Id: <200303041229.HAA14782@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt
Date: Tue, 04 Mar 2003 07:29:06 -0500
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title		: Fast Reroute Extensions to RSVP-TE for LSP Tunnels
	Author(s)	: P. Pan et al.
	Filename	: draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt
	Pages		: 34
	Date		: 2003-3-3
	
This document defines extensions to and describes the use of RSVP to
establish backup label-switched path (LSP) tunnels for local repair
of LSP tunnels.  These mechanisms enable the re-direction of traffic
onto backup LSP tunnels in 10s of milliseconds in the event of a
failure.
Two methods are defined here.  The one-to-one backup method creates
detour LSPs for each protected LSP at each potential point of local
repair.  The facility backup method creates a bypass tunnel to
protect a potential failure point; by taking advantage of MPLS label
stacking, this bypass tunnel can protect a set of protected LSPs that
have similar backup constraints. Both methods can be used to protect
links and nodes during network failure.  The described behavior and
extensions to RSVP allow nodes to implement either or both methods
and to interoperate in a mixed network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-3-3144926.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-3-3144926.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Tue Mar  4 08:39:06 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20505
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 08:39:06 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeok12421
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 13:41:08 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeok12091;
	Tue, 4 Mar 2003 13:40:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeoi28222
	for mpls-outgoing; Tue, 4 Mar 2003 13:14:22 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoeoi28217
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 13:14:13 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoeoi04975
	for <mpls@UU.NET>; Tue, 4 Mar 2003 13:13:58 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeoi10725
	for <mpls@UU.NET>; Tue, 4 Mar 2003 13:13:57 GMT
Received: from hoemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail1.lucent.com [192.11.226.161])
	id QQoeoi10699
	for <mpls@UU.NET>; Tue, 4 Mar 2003 13:13:57 GMT
Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58])
	by hoemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h24DDsB02754;
	Tue, 4 Mar 2003 08:13:54 -0500 (EST)
Received: from lucent.com ([135.13.45.36]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id IAA10065; Tue, 4 Mar 2003 08:13:53 -0500 (EST)
Message-ID: <3E64A690.D3BB8603@lucent.com>
Date: Tue, 04 Mar 2003 08:13:52 -0500
From: Yangguang Xu <xuyg@lucent.com>
Organization: Lucent Technologies, Inc.
X-Mailer: Mozilla 4.7 [en]C-EMS-1.4  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Kireeti Kompella <kireeti@juniper.net>
CC: Zhi-Wei Lin <zwlin@comcast.net>, mpls@UU.NET
Subject: Re: a propos of nothing at all ...
References: <000501c2e1f9$ca231bc0$6e00a8c0@na01.lucent.com> <20030303214755.S53165@kummer.juniper.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



Kireeti,

Yea, you are right. You pay flat rate for a DSL. I guess you have to double your
pay if you get TWO DSLs. :-) More important, you are talking about "consumer"
service, where flat rate may be popular for the time being. Carrier chooses flat
rate for many business reasons, e.g. ... (totally out of CCAMP scope, so skip).
Yet, it may be a different picture in the business customer service area.

Furthermore, you are talking about billing. Indeed, one of the reasons opertors
choose flat rate is to simplify billing because the control/management plane
can't generate accurate information. 

The bottom line is that as the building block of the overall management
functions, control plane should provide adequate function to support high level
services. Otherwise, everything becomes commodity.

Regards,

Yangguang

> 
> I pay flat rate for my local service.  I see a tentative move towards
> flat rate for long distance; my cell phone bill is essentially flat
> rate (I pay for more minutes than I would ever use per month.)  Of
> course, I pay flat rate for my DSL (thanks to which you get this
> message :-))
> 
> 1) Assume the world is moving towards flat rate billing (big IF), would
>    call and connection separation still be a requirement?
> 
> 2) While GMPLS could be used down to the T1 and DS0 level, suppose
>    for a minute that its use was restricted to OC12 and above.
>    Would call and connection separation still be a requirement?
> 
> Thanks for your insights,
> Kireeti.


From owner-mpls@UU.NET  Tue Mar  4 08:43:07 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20677
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 08:43:07 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeol07038
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 13:45:08 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeok06545;
	Tue, 4 Mar 2003 13:44:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeoj28739
	for mpls-outgoing; Tue, 4 Mar 2003 13:18:22 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoeoj28734
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 13:18:19 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoeoj15197
	for <mpls@UU.NET>; Tue, 4 Mar 2003 13:18:14 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeoj25017
	for <mpls@UU.NET>; Tue, 4 Mar 2003 13:18:13 GMT
Received: from hoemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail1.lucent.com [192.11.226.161])
	id QQoeoj24994
	for <mpls@UU.NET>; Tue, 4 Mar 2003 13:18:13 GMT
Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58])
	by hoemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h24DI9B04583;
	Tue, 4 Mar 2003 08:18:10 -0500 (EST)
Received: from lucent.com ([135.13.45.36]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id IAA10363; Tue, 4 Mar 2003 08:18:08 -0500 (EST)
Message-ID: <3E64A78F.F2A56A0B@lucent.com>
Date: Tue, 04 Mar 2003 08:18:07 -0500
From: Yangguang Xu <xuyg@lucent.com>
Organization: Lucent Technologies, Inc.
X-Mailer: Mozilla 4.7 [en]C-EMS-1.4  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Dimitri.Papadimitriou@alcatel.be
CC: Zhi-Wei Lin <zwlin@comcast.net>,
        "'Kireeti Kompella'" <kireeti@juniper.net>,
        "'Stephen Trowbridge'" <sjtrowbridge@lucent.com>, ccamp@ops.ietf.org,
        mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <004601c2e1e2$25a90e90$6e00a8c0@na01.lucent.com> <3E64889E.17DAC6E@alcatel.be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



Dimitri,

> 
> ps: some of the critical oif players you refer in your
> below e-mail are seriously questioning what has been done
> over time ... and from this perspective only implementation
> will decide about the relevance of these extensions
> 

FYI, I've been writing code for all the time when you are talking... 

Yangguang


From owner-mpls@UU.NET  Tue Mar  4 10:38:34 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27479
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 10:38:34 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeos07231
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 15:40:37 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeos07000;
	Tue, 4 Mar 2003 15:40:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeoo22707
	for mpls-outgoing; Tue, 4 Mar 2003 14:40:42 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoeoo22702
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 14:40:38 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoeoo23837
	for <mpls@UU.NET>; Tue, 4 Mar 2003 14:39:46 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeoo22705
	for <mpls@UU.NET>; Tue, 4 Mar 2003 14:39:45 GMT
Received: from bt0g2p.god.bel.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alc136.alcatel.be [195.207.101.136])
	id QQoeoo22686
	for <mpls@UU.NET>; Tue, 4 Mar 2003 14:39:44 GMT
Received: from bemail05.net.alcatel.be (relay3 [127.0.0.1])
	by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id h24EdWi10962;
	Tue, 4 Mar 2003 15:39:32 +0100
Received: from alcatel.be ([138.203.64.155])
          by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11)
          with ESMTP id 2003030415393023:3415 ;
          Tue, 4 Mar 2003 15:39:30 +0100 
Message-ID: <3E64BA68.84D16EA8@alcatel.be>
Date: Tue, 04 Mar 2003 15:38:32 +0100
From: Dimitri.Papadimitriou@alcatel.be
Organization: optical network architecture (nta - antwerpen)
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Yangguang Xu <xuyg@lucent.com>
Cc: Zhi-Wei Lin <zwlin@comcast.net>,
        "'Kireeti Kompella'" <kireeti@juniper.net>,
        "'Stephen Trowbridge'" <sjtrowbridge@lucent.com>, ccamp@ops.ietf.org,
        mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <004601c2e1e2$25a90e90$6e00a8c0@na01.lucent.com> <3E64889E.17DAC6E@alcatel.be> <3E64A78F.F2A56A0B@lucent.com>
X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 03/04/2003 15:39:30,
	Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 03/04/2003 15:39:31,
	Serialize complete at 03/04/2003 15:39:31
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

as from our side we are done with the oif stuff, 
we've took the time to make some charts explaining
some of the issues related to this implementation
agreement (just to be sure that the next version 
will be more easy to develop)

http://psg.com/~dpapadimitriou/slides02.ppt

Yangguang Xu wrote:
> 
> Dimitri,
> 
> >
> > ps: some of the critical oif players you refer in your
> > below e-mail are seriously questioning what has been done
> > over time ... and from this perspective only implementation
> > will decide about the relevance of these extensions
> >
> 
> FYI, I've been writing code for all the time when you are talking...
> 
> Yangguang

-- 
Papadimitriou Dimitri 
E-mail : dimitri.papadimitriou@alcatel.be 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491


From owner-mpls@UU.NET  Tue Mar  4 10:48:49 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27896
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 10:48:49 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeot23438
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 15:50:51 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeot23248;
	Tue, 4 Mar 2003 15:50:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeop23390
	for mpls-outgoing; Tue, 4 Mar 2003 14:45:41 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoeop23382
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 14:45:28 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoeoo04163
	for <mpls@UU.NET>; Tue, 4 Mar 2003 14:44:41 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeoo22054
	for <mpls@UU.NET>; Tue, 4 Mar 2003 14:44:40 GMT
Received: from auemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: auemail2.lucent.com [192.11.223.163])
	id QQoeoo22039
	for <mpls@UU.NET>; Tue, 4 Mar 2003 14:44:40 GMT
Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58])
	by auemail2.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h24EicW18852;
	Tue, 4 Mar 2003 09:44:38 -0500 (EST)
Received: from lucent.com (cc316.mv.lucent.com [135.13.162.152]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id JAA16804; Tue, 4 Mar 2003 09:44:37 -0500 (EST)
Message-ID: <3E64BC39.263A6A56@lucent.com>
Date: Tue, 04 Mar 2003 09:46:17 -0500
From: Yangguang Xu <xuyg@lucent.com>
Organization: Lucent Technologies ,  Optical Networking Group, MV
X-Mailer: Mozilla 4.76C-CCK-MCD EMS-1.5 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Dimitri.Papadimitriou@alcatel.be
CC: ccamp@ops.ietf.org, mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <004601c2e1e2$25a90e90$6e00a8c0@na01.lucent.com> <3E64889E.17DAC6E@alcatel.be> <3E64A78F.F2A56A0B@lucent.com> <3E64BA68.84D16EA8@alcatel.be>
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

You don't get it, do you?

BTW, this is IETF. I was talking about IETF stuff.


Dimitri.Papadimitriou@alcatel.be wrote:
> 
> as from our side we are done with the oif stuff,
> we've took the time to make some charts explaining
> some of the issues related to this implementation
> agreement (just to be sure that the next version
> will be more easy to develop)
> 
> http://psg.com/~dpapadimitriou/slides02.ppt
> 
> Yangguang Xu wrote:
> >
> > Dimitri,
> >
> > >
> > > ps: some of the critical oif players you refer in your
> > > below e-mail are seriously questioning what has been done
> > > over time ... and from this perspective only implementation
> > > will decide about the relevance of these extensions
> > >
> >
> > FYI, I've been writing code for all the time when you are talking...
> >
> > Yangguang
> 
> --
> Papadimitriou Dimitri
> E-mail : dimitri.papadimitriou@alcatel.be
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : dpapadimitriou@psg.com
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : +32 3 240-8491


From owner-mpls@UU.NET  Tue Mar  4 10:52:05 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28010
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 10:52:04 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeot19111
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 15:54:06 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeot18655;
	Tue, 4 Mar 2003 15:53:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeop23810
	for mpls-outgoing; Tue, 4 Mar 2003 14:50:17 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoeop23803
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 14:50:15 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoeop04303
	for <mpls@uu.net>; Tue, 4 Mar 2003 14:49:58 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeop28801
	for <mpls@uu.net>; Tue, 4 Mar 2003 14:49:57 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoeop28781
	for <mpls@uu.net>; Tue, 4 Mar 2003 14:49:57 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h24EnsJR000218
	for <mpls@uu.net>; Tue, 4 Mar 2003 09:49:54 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA00814 for <mpls@uu.net>; Tue, 4 Mar 2003 09:49:53 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h24Enri15818 for mpls@uu.net; Tue, 4 Mar 2003 09:49:53 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoemd05123
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Mar 2003 22:58:04 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoemd19348
	for <mpls@UU.NET>; Mon, 3 Mar 2003 22:57:47 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoemd10381
	for <mpls@UU.NET>; Mon, 3 Mar 2003 22:57:47 GMT
Received: from ihemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ihemail2.lucent.com [192.11.222.163])
	id QQoemd10370
	for <mpls@UU.NET>; Mon, 3 Mar 2003 22:57:46 GMT
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h23MvjC21744;
	Mon, 3 Mar 2003 17:57:45 -0500 (EST)
Received: from lucent.com (sjtrowbridge-1.dr.lucent.com [135.4.20.16]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id QAA09922; Mon, 3 Mar 2003 16:57:40 -0600 (CST)
Message-ID: <3E63DDE2.FDA6F7AD@lucent.com>
Date: Mon, 03 Mar 2003 15:57:38 -0700
From: Stephen Trowbridge <sjtrowbridge@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5  (Windows NT 5.0; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: Kireeti Kompella <kireeti@juniper.net>
CC: ccamp@ops.ietf.org, mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <200303031648.h23GmwJO003841@newdev.harvard.edu>
	 <3E638C95.167731F8@lucent.com> <20030303140750.W51425@kummer.juniper.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Kireeti,

snip
> I have started (belatedly) posting to the CCAMP list that such liaisons
> exist.  Note that I don't need to do that for IDs -- the authors generally
> do that, and there is a mailing list that one can subscribe for this.
I saw this, and I think it is definitely a step in the right direction. Thanks!

> 
> > But it is my opinion that the lack of a liaison process is really
> > the ROOT CAUSE of difficulties like what we saw in January.
> 
> If we really do a root cause analysis, it comes down to this (IMO):
> a) CCAMP gets a liaison statement stating that certain changes are
>    requested in the GMPLS specs (doesn't get posted to the list, though).
Perhaps we didn't get an email out the instant something appeared in
http://www.ietf.org/IESG/liaison.html, but I think that (at least for
liaisons to ccamp from ITU-T SG15 since Oct. 2001) there was always
an email from the presenter (Wesam or myself) at the occasion of the
next IETF meeting with reminders about the location of the liaison information
and the slides presented in the meeting to explain them. So within a
window of time, I think all incoming liaisons were advertised.

> b) CCAMP doesn't officially respond (mechanisms not in place).
> c) CCAMP WG gets requirements via Zhi's and Osama's drafts.
> d) CCAMP mailing list hosts discussions about whether these requirements
>    make sense in the IETF context.
> e) In the interest of quick allocation of code points, these two docs
>    are made Informational, and go through without much review.
> f) Various folks (CCAMP, RSVP, MPLS, ...) are very concerned about the
>    changes made to RSVP and CR-LDP.
> 
> (The intent here is not to point fingers, although I've already claimed
> my share of the blame.)
> 
> I see (b) and (e) as the most serious breakdowns in the process.  The
> GMPLS change doc should help alleviate (e), and hopefully help (a) as
> well.  And if we get started on the liaison doc, that should help (b).
Personally, I think that if we had done a good job at getting the bi-
directional communication channel going at (b), we wouldn't have run
into problems at (e). Either ccamp would have been actively involved in
producing the solution, or people would have understood the reasons
why it was being done outside and been OK with it at (e).

What happened at (e) was a step to try to unblock some ITU-T work that
was stuck because we didn't get the right communication to happen at (b).
I think what some of us worry about here is that if we remove the flexibility
we had at (e) without fixing the communication problem at (b), then IETF
ends up (intentionally or unintentionally, depending on who in this thread
you believe) putting up roadblocks to the progress in other organizations.
This is why we feel that the liaison process has to be either a prerequisite
(or a co-requisite) of the change control process.

> Or we could keep talking :-)
I'm sure we'll do this anyway ...
> 
> Kireeti.

Regards,
Steve



From owner-mpls@UU.NET  Tue Mar  4 10:52:14 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28025
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 10:52:14 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeot28083
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 15:54:16 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeot27779;
	Tue, 4 Mar 2003 15:54:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeop23906
	for mpls-outgoing; Tue, 4 Mar 2003 14:51:27 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoeop23897
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 14:51:07 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoeop06209
	for <mpls@uu.net>; Tue, 4 Mar 2003 14:50:29 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeop00451
	for <mpls@uu.net>; Tue, 4 Mar 2003 14:50:28 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoeop00445
	for <mpls@uu.net>; Tue, 4 Mar 2003 14:50:28 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h24EoPNh029091
	for <mpls@uu.net>; Tue, 4 Mar 2003 09:50:25 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA00869 for <mpls@uu.net>; Tue, 4 Mar 2003 09:50:25 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h24EoP315903 for mpls@uu.net; Tue, 4 Mar 2003 09:50:25 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoene05440
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 05:35:28 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoene24687
	for <mpls@UU.NET>; Tue, 4 Mar 2003 05:34:53 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoene02871
	for <mpls@UU.NET>; Tue, 4 Mar 2003 05:34:53 GMT
Received: from rediffmail.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: webmail23.rediffmail.com [203.199.83.145] (may be forged))
	id QQoene02806
	for <mpls@UU.NET>; Tue, 4 Mar 2003 05:34:50 GMT
Received: (qmail 7671 invoked by uid 510); 4 Mar 2003 05:33:31 -0000
Date: 4 Mar 2003 05:33:31 -0000
Message-ID: <20030304053331.7670.qmail@webmail23.rediffmail.com>
Received: from unknown (203.200.20.226) by rediffmail.com via HTTP; 04 mar 2003 05:33:31 -0000
MIME-Version: 1.0
From: "Harish  Kumtakar" <harishk3@rediffmail.com>
Reply-To: "Harish  Kumtakar" <harishk3@rediffmail.com>
To: mpls@UU.NET, rsvp@isi.edu
Subject: help
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk

hi,

      Why IPSEC can not be used in RSVP to care of security. 
Please throw some light on this aspect.

Regards
-harish


Harish Kumtakar
Samsung India Software Operations
Samsung Digital House
No. 67, Infantry Road
Bangalore - 560 001

Ph: 5550555 extn:2260



From owner-mpls@UU.NET  Tue Mar  4 10:56:35 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28213
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 10:56:35 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeot05449
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 15:58:38 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeot05282;
	Tue, 4 Mar 2003 15:58:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeoq29275
	for mpls-outgoing; Tue, 4 Mar 2003 15:02:08 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoeoq29064
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 15:01:57 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoeoq25678
	for <mpls@UU.NET>; Tue, 4 Mar 2003 15:01:54 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeoq16838
	for <mpls@UU.NET>; Tue, 4 Mar 2003 15:01:53 GMT
Received: from relay2.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alc239.alcatel.be [195.207.101.239])
	id QQoeoq16813
	for <mpls@UU.NET>; Tue, 4 Mar 2003 15:01:52 GMT
Received: from bemail05.net.alcatel.be (localhost [127.0.0.1])
	by relay2.alcatel.be (8.10.1/8.11.4) with ESMTP id h24F1iG27119;
	Tue, 4 Mar 2003 16:01:44 +0100 (MET)
Received: from alcatel.be ([138.203.64.155])
          by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11)
          with ESMTP id 2003030416014195:3547 ;
          Tue, 4 Mar 2003 16:01:41 +0100 
Message-ID: <3E64BF9A.B8ACA6BA@alcatel.be>
Date: Tue, 04 Mar 2003 16:00:42 +0100
From: Dimitri.Papadimitriou@alcatel.be
Organization: optical network architecture (nta - antwerpen)
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Yangguang Xu <xuyg@lucent.com>
Cc: ccamp@ops.ietf.org, mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <004601c2e1e2$25a90e90$6e00a8c0@na01.lucent.com> <3E64889E.17DAC6E@alcatel.be> <3E64A78F.F2A56A0B@lucent.com> <3E64BA68.84D16EA8@alcatel.be> <3E64BC39.263A6A56@lucent.com>
X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 03/04/2003 16:01:42,
	Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 03/04/2003 16:01:44,
	Serialize complete at 03/04/2003 16:01:44
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

true, i took a look at

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-signaling-survey-03.txt

and i don't get you as well !

Yangguang Xu wrote:
> 
> You don't get it, do you?
> 
> BTW, this is IETF. I was talking about IETF stuff.
> 
> Dimitri.Papadimitriou@alcatel.be wrote:
> >
> > as from our side we are done with the oif stuff,
> > we've took the time to make some charts explaining
> > some of the issues related to this implementation
> > agreement (just to be sure that the next version
> > will be more easy to develop)
> >
> > http://psg.com/~dpapadimitriou/slides02.ppt
> >
> > Yangguang Xu wrote:
> > >
> > > Dimitri,
> > >
> > > >
> > > > ps: some of the critical oif players you refer in your
> > > > below e-mail are seriously questioning what has been done
> > > > over time ... and from this perspective only implementation
> > > > will decide about the relevance of these extensions
> > > >
> > >
> > > FYI, I've been writing code for all the time when you are talking...
> > >
> > > Yangguang
> >
> > --
> > Papadimitriou Dimitri
> > E-mail : dimitri.papadimitriou@alcatel.be
> > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > E-mail : dpapadimitriou@psg.com
> > Public : http://psg.com/~dpapadimitriou/
> > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > Phone  : +32 3 240-8491

-- 
Papadimitriou Dimitri 
E-mail : dimitri.papadimitriou@alcatel.be 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491


From owner-mpls@UU.NET  Tue Mar  4 11:04:29 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28622
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 11:04:29 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeou13409
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 16:06:31 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeou13325;
	Tue, 4 Mar 2003 16:06:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeor15967
	for mpls-outgoing; Tue, 4 Mar 2003 15:27:11 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoeor15955
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 15:27:00 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoeor05501
	for <mpls@UU.NET>; Tue, 4 Mar 2003 15:26:46 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeor09022
	for <mpls@UU.NET>; Tue, 4 Mar 2003 15:26:45 GMT
Received: from hoemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail2.lucent.com [192.11.226.163])
	id QQoeor09010
	for <mpls@UU.NET>; Tue, 4 Mar 2003 15:26:45 GMT
Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35])
	by hoemail2.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h24FQia08383
	for <mpls@UU.NET>; Tue, 4 Mar 2003 10:26:44 -0500 (EST)
Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19)
	id <1HW0HSGJ>; Tue, 4 Mar 2003 10:26:43 -0500
Message-ID: <B99995113B318D44BBE87DC50092EDA943A7A8@nj7460exch006u.ho.lucent.com>
From: "Jiang, Donghua (Jane)" <djiang1@lucent.com>
To: "'Harish  Kumtakar'" <harishk3@rediffmail.com>, mpls@UU.NET, rsvp@isi.edu
Subject: RE: help
Date: Tue, 4 Mar 2003 10:26:34 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Harish,

I don't think it is an issue of whether IPSec can or cannot be used in RSVP.  It is an issue of what we want IPSec to do with RSVP.

The concept of IPSec is to encode IP packets so no one can intercept the IP packets while the IP packets are in transit between two end points.  If we encode RSVP packet with IPSec, do we expect RSVP nodes in between to understand the encoded RSVP packet?

We could implement IPSec between two RSVP nodes, if we fear the link between the two RSVP nodes is not safe at all.  Then, implementing IPSec hop by hop between RSVP nodes along the path might be too much.  IPSec is generally meant to be applied in "end-to-end" situation rather than "hop-by-hop" situation.

Regards,
Jane D. Jiang

 

-----Original Message-----
From: Harish Kumtakar [mailto:harishk3@rediffmail.com]
Sent: Tuesday, March 04, 2003 12:34 AM
To: mpls@UU.NET; rsvp@isi.edu
Subject: help


hi,

      Why IPSEC can not be used in RSVP to care of security. 
Please throw some light on this aspect.

Regards
-harish


Harish Kumtakar
Samsung India Software Operations
Samsung Digital House
No. 67, Infantry Road
Bangalore - 560 001

Ph: 5550555 extn:2260


From owner-mpls@UU.NET  Tue Mar  4 11:47:41 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00383
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 11:47:41 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeox11535
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 16:49:44 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeox11345;
	Tue, 4 Mar 2003 16:49:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeov08270
	for mpls-outgoing; Tue, 4 Mar 2003 16:16:26 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoeov08265
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 16:16:24 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoeov05990
	for <mpls@uu.net>; Tue, 4 Mar 2003 16:16:07 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeov24908
	for <mpls@uu.net>; Tue, 4 Mar 2003 16:16:06 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoeov24871
	for <mpls@uu.net>; Tue, 4 Mar 2003 16:16:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h24GG3JR006764
	for <mpls@uu.net>; Tue, 4 Mar 2003 11:16:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA08162 for <mpls@uu.net>; Tue, 4 Mar 2003 11:16:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h24GG2627406 for mpls@uu.net; Tue, 4 Mar 2003 11:16:02 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoeou07817
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 16:14:36 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoeou04369
	for <mpls@UU.NET>; Tue, 4 Mar 2003 16:12:13 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeou12014
	for <mpls@UU.NET>; Tue, 4 Mar 2003 16:12:12 GMT
Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoeou11986
	for <mpls@UU.NET>; Tue, 4 Mar 2003 16:12:11 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA91545;
	Tue, 4 Mar 2003 11:10:06 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303041610.LAA91545@workhorse.fictitious.org>
To: Yangguang Xu <xuyg@lucent.com>
cc: Kireeti Kompella <kireeti@juniper.net>, Zhi-Wei Lin <zwlin@comcast.net>,
        mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: billing & call management (was Re: a propos of nothing at all)
In-reply-to: Your message of "Tue, 04 Mar 2003 08:13:52 EST."
             <3E64A690.D3BB8603@lucent.com> 
Date: Tue, 04 Mar 2003 11:10:06 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <3E64A690.D3BB8603@lucent.com>, Yangguang Xu writes:
> 
> 
> Kireeti,
> 
> Yea, you are right. You pay flat rate for a DSL.  [...]

Lets look up and down the food chain.  

  At consumer level, service is tiered flat rate.  DSL, cable IP, cell
  phone, now POTS.

  IP service at T1 or higher has always been flat rate or burstable
  tiered flat rate.

  Switched services such as FR and ATM have been flat rate PVC or
  SPVC.  SVC service is generally not available and where it is has
  almost negligible penetration.

  At the high end, leased lines, leased lambdas, and leased dark fiber
  is definitely not signaled dynamicly by the customer so there is not
  "call" or customer connection.

What has had a call model:

  X.25

  ISDN

Even ISDN, where it has been at all successful, is flat rate.  Where
it is metered, market penetration is zip.  (btw - Its still metered
where I live afaik and might as well not be offered).

> Furthermore, you are talking about billing. Indeed, one of the reasons operto
> rs
> choose flat rate is to simplify billing because the control/management plane
> can't generate accurate information. 
> 
> The bottom line is that as the building block of the overall management
> functions, control plane should provide adequate function to support high lev
> el
> services. Otherwise, everything becomes commodity.

So what does this billing and control/management plane nonsense mean
in a world with flat rate or tiered service with no customer initiated
connections to bill for?  It has absolutely no purpose except to try
to perpetuate a mindset and perpetuate a hope that services with the
X.25 and ISDN metered billing model will somehow gain penetration and
the SP will be able to milk huge profits from it.  Unfortunately the
customer isn't stupid enough, so short of a return to monopoly rule or
other exclusion of competition, it won't happen.

> Yangguang

Curtis



From owner-mpls@UU.NET  Tue Mar  4 11:52:00 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00775
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 11:52:00 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeox14645
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 16:54:03 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeox14460;
	Tue, 4 Mar 2003 16:53:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeov08436
	for mpls-outgoing; Tue, 4 Mar 2003 16:19:53 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoeov08422
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 16:19:42 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoeov06907
	for <mpls@UU.NET>; Tue, 4 Mar 2003 16:18:40 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeov12527
	for <mpls@UU.NET>; Tue, 4 Mar 2003 16:18:40 GMT
Received: from bridge.axiowave.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged))
	id QQoeov12479
	for <mpls@UU.NET>; Tue, 4 Mar 2003 16:18:39 GMT
Message-ID: <EB5FFC72F183D411B382000629573429035E889D@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'Yangguang Xu'" <xuyg@lucent.com>,
        Kireeti Kompella
	 <kireeti@juniper.net>
Cc: Zhi-Wei Lin <zwlin@comcast.net>, mpls@UU.NET
Subject: RE: a propos of nothing at all ...
Date: Tue, 4 Mar 2003 11:18:28 -0500 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk


> The bottom line is that as the building block of the overall 
> management functions, control plane should provide adequate 
> function to support high level services. 
> Otherwise, everything becomes commodity.
> 
> Yangguang

And everything becoming a commodity is a bad thing?

And I thought that one of the few glories of the 
capatalist system was that we drove the price of a 
horseless carriage down to the point that every 
worker could afford one.  

- jeff parker


From owner-mpls@UU.NET  Tue Mar  4 12:04:26 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01604
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 12:04:25 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeoy03482
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 17:06:28 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeoy03427;
	Tue, 4 Mar 2003 17:06:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeow09664
	for mpls-outgoing; Tue, 4 Mar 2003 16:34:46 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoeow09659
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 16:34:38 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoeow07058
	for <mpls@UU.NET>; Tue, 4 Mar 2003 16:33:13 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeow06652
	for <mpls@UU.NET>; Tue, 4 Mar 2003 16:33:12 GMT
Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQoeow06636
	for <mpls@UU.NET>; Tue, 4 Mar 2003 16:33:12 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA02261;
	Tue, 4 Mar 2003 11:33:10 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA24176;
	Tue, 4 Mar 2003 11:33:10 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <D3QMZJFS>; Tue, 4 Mar 2003 11:33:09 -0500
Message-ID: <39469E08BD83D411A3D900204840EC557634E7@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'Harish  Kumtakar'" <harishk3@rediffmail.com>, mpls@UU.NET
Subject: RE: help
Date: Tue, 4 Mar 2003 11:33:08 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Harish,

->       Why IPSEC can not be used in RSVP to care of security. 
-> Please throw some light on this aspect.

   Right now NSIS WG is discussing signaling security.
   Move the discussion to NSIS list, let us discuss this there.

FYI-
http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg02191.html
http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg02192.html

Venkata.


From owner-mpls@UU.NET  Tue Mar  4 12:24:01 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02466
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 12:24:01 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeoz01920
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 17:26:03 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeoz01651;
	Tue, 4 Mar 2003 17:25:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeox11898
	for mpls-outgoing; Tue, 4 Mar 2003 16:59:35 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoeox11886
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 16:59:21 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoeox23649
	for <mpls@UU.NET>; Tue, 4 Mar 2003 16:58:05 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeox23480
	for <mpls@UU.NET>; Tue, 4 Mar 2003 16:58:04 GMT
Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQoeox23400
	for <mpls@UU.NET>; Tue, 4 Mar 2003 16:58:01 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA03604;
	Tue, 4 Mar 2003 11:57:52 -0500 (EST)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA27861;
	Tue, 4 Mar 2003 11:57:53 -0500 (EST)
Message-ID: <3E64DB31.3020204@marconi.com>
Date: Tue, 04 Mar 2003 11:58:25 -0500
From: David Charlap <David.Charlap@marconi.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210
X-Accept-Language: en-us, en, he
MIME-Version: 1.0
To: mpls@UU.NET, rsvp@isi.edu
Subject: Re: help
References: <20030304053331.7670.qmail@webmail23.rediffmail.com>
In-Reply-To: <20030304053331.7670.qmail@webmail23.rediffmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Harish Kumtakar wrote:
> 
>      Why IPSEC can not be used in RSVP to care of security. Please throw 
> some light on this aspect.

The reason it isn't in classical RSVP is because IPSEC secures two 
endpoints.  But the nature of RSVP is such that packets are supposed to 
be intercepted and processed by transit routers.

An RSVP router does not send a Path message to his neighbor.  He sends 
it to the ultimate destination address, with the router-alert option, so 
that RSVP-aware routers along the way may intercept and process the 
packet.  This is fundamentally incompatible with IPSEC - where the 
packet is encrypted such that transit routers can not intercept anything.

If you want to use IPSEC with RSVP, then you must send packets directly 
to neighbors and abandon the use of router-alert.  This isn't a problem 
for RSVP-TE, since the presence of non-RSVP routers isn't permitted in 
an MPLS/RSVP-TE network.  But it eliminates the ability for classical 
RSVP to work over networks with non-RSVP nodes - something that is a key 
goal of the RSVP protocol.

IPSEC also makes multicast much more CPU intensive.  If every packet is 
encrypted, then you can't simply generate one Path message for 
transmission to all downstream nodes in a multicast group.  You have to 
generate multiple separate packets and encrypt them individually.

-- David



From owner-mpls@UU.NET  Tue Mar  4 12:39:42 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03162
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 12:39:42 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepa15728
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 17:41:45 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoepa15657;
	Tue, 4 Mar 2003 17:41:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeoz01356
	for mpls-outgoing; Tue, 4 Mar 2003 17:15:35 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoeoz01349
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 17:15:32 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoeoz23404
	for <mpls@uu.net>; Tue, 4 Mar 2003 17:15:08 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeoz13071
	for <mpls@uu.net>; Tue, 4 Mar 2003 17:15:08 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoeoz13059
	for <mpls@uu.net>; Tue, 4 Mar 2003 17:15:07 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h24HF5JR010862
	for <mpls@uu.net>; Tue, 4 Mar 2003 12:15:05 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA13164 for <mpls@uu.net>; Tue, 4 Mar 2003 12:15:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h24HF2404100 for mpls@uu.net; Tue, 4 Mar 2003 12:15:02 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoeoy01048
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 17:13:51 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoeoy19428
	for <mpls@UU.NET>; Tue, 4 Mar 2003 17:13:01 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeoy09308
	for <mpls@UU.NET>; Tue, 4 Mar 2003 17:13:01 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoeoy09297
	for <mpls@UU.NET>; Tue, 4 Mar 2003 17:13:00 GMT
Received: from bucket.cisco.com (IDENT:mirapoint@bucket.cisco.com [161.44.167.72])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h24HCsNh008199;
	Tue, 4 Mar 2003 12:12:54 -0500 (EST)
Received: from tnadeau-w2k.cisco.com (dhcp-161-44-139-157.cisco.com [161.44.139.157])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ACR39789;
	Tue, 4 Mar 2003 12:12:53 -0500 (EST)
Message-Id: <5.2.0.9.2.20030304120829.0308b6c0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 04 Mar 2003 12:12:51 -0500
To: Yangguang Xu <xuyg@lucent.com>, Kireeti Kompella <kireeti@juniper.net>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: a propos of nothing at all ...
Cc: Zhi-Wei Lin <zwlin@comcast.net>, mpls@UU.NET
In-Reply-To: <3E64A690.D3BB8603@lucent.com>
References: <000501c2e1f9$ca231bc0$6e00a8c0@na01.lucent.com>
 <20030303214755.S53165@kummer.juniper.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 08:13 AM 3/4/2003 -0500, Yangguang Xu wrote:


>Kireeti,
>
>Yea, you are right. You pay flat rate for a DSL. I guess you have to 
>double your
>pay if you get TWO DSLs. :-) More important, you are talking about "consumer"
>service, where flat rate may be popular for the time being. Carrier 
>chooses flat
>rate for many business reasons, e.g. ... (totally out of CCAMP scope, so 
>skip).
>Yet, it may be a different picture in the business customer service area.
>Furthermore, you are talking about billing. Indeed, one of the reasons 
>opertors
>choose flat rate is to simplify billing because the control/management plane
>can't generate accurate information.

         That it not entirely true. I know some providers that
due bill based on usage, and also verify based on these
same SLAs.

>The bottom line is that as the building block of the overall management
>functions, control plane should provide adequate function to support high 
>level
>services. Otherwise, everything becomes commodity.

         I wonder how you have arrived at your bottom line.
I personally think that the current offering of management is
largely sufficient to satisfy the requirements for monitoring
SLAs in many different levels of granularity. New drafts are
appearing all the time to fill in the holes.  There are other things
being working on in other  WGs such as IPFIX to standardize
additional accounting.  If you can identify specific deficiencies,
please let us all know.

         --Tom

>Regards,
>
>Yangguang
>
> >
> > I pay flat rate for my local service.  I see a tentative move towards
> > flat rate for long distance; my cell phone bill is essentially flat
> > rate (I pay for more minutes than I would ever use per month.)  Of
> > course, I pay flat rate for my DSL (thanks to which you get this
> > message :-))
> >
> > 1) Assume the world is moving towards flat rate billing (big IF), would
> >    call and connection separation still be a requirement?
> >
> > 2) While GMPLS could be used down to the T1 and DS0 level, suppose
> >    for a minute that its use was restricted to OC12 and above.
> >    Would call and connection separation still be a requirement?
> >
> > Thanks for your insights,
> > Kireeti.




From owner-mpls@UU.NET  Tue Mar  4 13:50:29 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05206
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 13:50:29 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepf27328
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 18:52:30 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoepf27188;
	Tue, 4 Mar 2003 18:52:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoepc21757
	for mpls-outgoing; Tue, 4 Mar 2003 18:03:35 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoepc21734
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 18:03:28 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoepc15616
	for <mpls@uu.net>; Tue, 4 Mar 2003 18:02:05 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepc20160
	for <mpls@uu.net>; Tue, 4 Mar 2003 18:02:05 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoepc20149
	for <mpls@uu.net>; Tue, 4 Mar 2003 18:02:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h24I22Nh010750
	for <mpls@uu.net>; Tue, 4 Mar 2003 13:02:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA17084 for <mpls@uu.net>; Tue, 4 Mar 2003 13:02:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h24I21V09394 for mpls@uu.net; Tue, 4 Mar 2003 13:02:01 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoepc08002
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 18:00:27 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoepb15012
	for <mpls@UU.NET>; Tue, 4 Mar 2003 17:59:30 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepb19598
	for <mpls@UU.NET>; Tue, 4 Mar 2003 17:59:29 GMT
Received: from fig.isi.edu by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fig.isi.edu [128.9.160.78])
	id QQoepb19576
	for <mpls@UU.NET>; Tue, 4 Mar 2003 17:59:28 GMT
Received: from fig.isi.edu (localhost.localdomain [127.0.0.1])
	by fig.isi.edu (8.12.8/8.12.8) with ESMTP id h24I0E1K014549;
	Tue, 4 Mar 2003 10:00:14 -0800
Received: from localhost (berson@localhost)
	by fig.isi.edu (8.12.8/8.12.5/Submit) with ESMTP id h24I0DFS014545;
	Tue, 4 Mar 2003 10:00:13 -0800
X-Authentication-Warning: fig.isi.edu: berson owned process doing -bs
Date: Tue, 4 Mar 2003 10:00:12 -0800 (PST)
From: Steven Berson <berson@isi.edu>
To: David Charlap <David.Charlap@marconi.com>
cc: mpls@UU.NET, <rsvp@isi.edu>
Subject: Re: [Rsvp] Re: help
In-Reply-To: <3E64DB31.3020204@marconi.com>
Message-ID: <Pine.LNX.4.44.0303040956310.14121-100000@fig.isi.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Actually, RSVP can be used with IPSEC.  See RFC 2207, ``RSVP 
Extensions for IPSEC Data Flows''.

Regards,
Steve

On Tue, 4 Mar 2003, David Charlap wrote:

> Harish Kumtakar wrote:
> > 
> >      Why IPSEC can not be used in RSVP to care of security. Please throw 
> > some light on this aspect.
> 
> The reason it isn't in classical RSVP is because IPSEC secures two 
> endpoints.  But the nature of RSVP is such that packets are supposed to 
> be intercepted and processed by transit routers.
> 
> An RSVP router does not send a Path message to his neighbor.  He sends 
> it to the ultimate destination address, with the router-alert option, so 
> that RSVP-aware routers along the way may intercept and process the 
> packet.  This is fundamentally incompatible with IPSEC - where the 
> packet is encrypted such that transit routers can not intercept anything.
> 
> If you want to use IPSEC with RSVP, then you must send packets directly 
> to neighbors and abandon the use of router-alert.  This isn't a problem 
> for RSVP-TE, since the presence of non-RSVP routers isn't permitted in 
> an MPLS/RSVP-TE network.  But it eliminates the ability for classical 
> RSVP to work over networks with non-RSVP nodes - something that is a key 
> goal of the RSVP protocol.
> 
> IPSEC also makes multicast much more CPU intensive.  If every packet is 
> encrypted, then you can't simply generate one Path message for 
> transmission to all downstream nodes in a multicast group.  You have to 
> generate multiple separate packets and encrypt them individually.
> 
> -- David
> 
> _______________________________________________
> Rsvp mailing list
> Rsvp@mailman.isi.edu
> http://mailman.isi.edu/mailman/listinfo/rsvp
> 



From owner-mpls@UU.NET  Tue Mar  4 13:54:23 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05340
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 13:54:22 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepf24556
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 18:56:24 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoepf24446;
	Tue, 4 Mar 2003 18:56:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoepc22312
	for mpls-outgoing; Tue, 4 Mar 2003 18:04:42 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoepc22290
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 18:04:35 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoepc02817
	for <mpls@UU.NET>; Tue, 4 Mar 2003 18:04:24 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepc25702
	for <mpls@UU.NET>; Tue, 4 Mar 2003 18:04:23 GMT
Received: from hoemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail1.lucent.com [192.11.226.161])
	id QQoepc25685
	for <mpls@UU.NET>; Tue, 4 Mar 2003 18:04:23 GMT
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by hoemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h24I4Kn29183;
	Tue, 4 Mar 2003 13:04:20 -0500 (EST)
Received: from lucent.com (sjtrowbridge-1.dr.lucent.com [135.4.20.16]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id MAA19829; Tue, 4 Mar 2003 12:04:18 -0600 (CST)
Message-ID: <3E64EAA2.FDD36434@lucent.com>
Date: Tue, 04 Mar 2003 11:04:18 -0700
From: Stephen Trowbridge <sjtrowbridge@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5  (Windows NT 5.0; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: curtis@fictitious.org
CC: Yangguang Xu <xuyg@lucent.com>, Kireeti Kompella <kireeti@juniper.net>,
        Zhi-Wei Lin <zwlin@comcast.net>, mpls@UU.NET
Subject: Re: billing & call management (was Re: a propos of nothing at all)
References: <200303041610.LAA91545@workhorse.fictitious.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Curtis,
Working for an equipment manufacturer, I have never felt that it was
my place to tell a SP how they should bill for their services. I don't
think we should preclude any particular billing model by our architecture.
It is the market that should decide what gets offered at a flat rate:
not the equipment, and certainly not the standards.
Steve

Curtis Villamizar wrote:
> 
> In message <3E64A690.D3BB8603@lucent.com>, Yangguang Xu writes:
> >
> >
> > Kireeti,
> >
> > Yea, you are right. You pay flat rate for a DSL.  [...]
> 
> Lets look up and down the food chain.
> 
>   At consumer level, service is tiered flat rate.  DSL, cable IP, cell
>   phone, now POTS.
> 
>   IP service at T1 or higher has always been flat rate or burstable
>   tiered flat rate.
> 
>   Switched services such as FR and ATM have been flat rate PVC or
>   SPVC.  SVC service is generally not available and where it is has
>   almost negligible penetration.
> 
>   At the high end, leased lines, leased lambdas, and leased dark fiber
>   is definitely not signaled dynamicly by the customer so there is not
>   "call" or customer connection.
> 
> What has had a call model:
> 
>   X.25
> 
>   ISDN
> 
> Even ISDN, where it has been at all successful, is flat rate.  Where
> it is metered, market penetration is zip.  (btw - Its still metered
> where I live afaik and might as well not be offered).
> 
> > Furthermore, you are talking about billing. Indeed, one of the reasons operto
> > rs
> > choose flat rate is to simplify billing because the control/management plane
> > can't generate accurate information.
> >
> > The bottom line is that as the building block of the overall management
> > functions, control plane should provide adequate function to support high lev
> > el
> > services. Otherwise, everything becomes commodity.
> 
> So what does this billing and control/management plane nonsense mean
> in a world with flat rate or tiered service with no customer initiated
> connections to bill for?  It has absolutely no purpose except to try
> to perpetuate a mindset and perpetuate a hope that services with the
> X.25 and ISDN metered billing model will somehow gain penetration and
> the SP will be able to milk huge profits from it.  Unfortunately the
> customer isn't stupid enough, so short of a return to monopoly rule or
> other exclusion of competition, it won't happen.
> 
> > Yangguang
> 
> Curtis


From owner-mpls@UU.NET  Tue Mar  4 13:55:57 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05396
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 13:55:57 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepf14224
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 18:57:58 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoepf13993;
	Tue, 4 Mar 2003 18:57:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoepc22859
	for mpls-outgoing; Tue, 4 Mar 2003 18:06:48 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoepc22854
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 18:06:41 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoepc23297
	for <mpls@UU.NET>; Tue, 4 Mar 2003 18:06:09 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepc28083
	for <mpls@UU.NET>; Tue, 4 Mar 2003 18:06:07 GMT
Received: from lightwave.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: lightwave.chromisys.com [63.102.55.206])
	id QQoepc28010
	for <mpls@UU.NET>; Tue, 4 Mar 2003 18:06:05 GMT
Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19)
	id <4GJZGN7J>; Tue, 4 Mar 2003 10:05:44 -0800
Message-ID: <9D42C6E086250248810DCADA39CE7EFC97229C@nimbus>
From: John Drake <jdrake@calient.net>
To: "'Zhi-Wei Lin'" <zwlin@comcast.net>, mpls@UU.NET
Subject: RE: FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Tue, 4 Mar 2003 10:05:39 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2E278.A9CEF220"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2E278.A9CEF220
Content-Type: text/plain;
	charset="iso-8859-1"

Comments inline
.  
-----Original Message-----
From: Zhi-Wei Lin [mailto:zwlin@comcast.net]
Sent: Monday, March 03, 2003 6:44 PM
To: John Drake; mpls@UU.NET
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:jdrake@calient.net]
Sent: Monday, March 03, 2003 8:55 PM
To: 'Zhi-Wei Lin'; 'Zhi-Wei Lin'; mpls@UU.NET
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:zwlin@comcast.net]
Sent: Monday, March 03, 2003 4:28 PM
To: John Drake; 'Zhi-Wei Lin'; mpls@UU.NET
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:zhiweilin@yahoo.com]
Sent: Sunday, March 02, 2003 11:21 AM
To: mpls@uu.net
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 



 From: John Drake [mailto:jdrake@calient.net]
Sent: Friday, February 28, 2003 4:15 PM
To: 'erosen@cisco.com'; Varma, Eve L (Eve)
Cc: 'curtis@fictitious.org'; George Newsome; Stephen Trowbridge; Loa
Andersson; mpls@UU.NET
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:erosen@cisco.com]
> Sent: Friday, February 28, 2003 12:54 PM
> To: Varma, Eve L (Eve)
> Cc: 'curtis@fictitious.org'; George Newsome; Stephen Trowbridge; Loa
> Andersson; mpls@UU.NET
> 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!  <http://rd.yahoo.com/finance/mailtagline/*http://taxes.yahoo.com/>
Tax Center - forms, calculators, tips, and more


------_=_NextPart_001_01C2E278.A9CEF220
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D168165317-04032003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Comments inline</FONT></SPAN></DIV>
<DIV><SPAN class=3D168165317-04032003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>.&nbsp; </FONT></SPAN></DIV>
<DIV><SPAN class=3D168165317-04032003></SPAN><FONT face=3DTahoma=20
size=3D2>-----Original Message-----<BR><B>From:</B> Zhi-Wei Lin=20
[mailto:zwlin@comcast.net]<BR><B>Sent:</B> Monday, March 03, 2003 6:44=20
PM<BR><B>To:</B> John Drake; mpls@UU.NET<BR><B>Subject:</B> RE: FW: I-D =

ACTION:draft-andersson-mpls-g-chng-proc-00.txt<BR><BR></DIV></FONT>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D405023802-04032003>Hi=20
  John,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D405023802-04032003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D405023802-04032003>What=20
  you said is probably all true, but then that just gets to the fact =
that there=20
  are multiple ways to skin a carrot. What you've specified using the =
Notify=20
  probably works just as well.<SPAN=20
  class=3D168165317-04032003>&nbsp;</SPAN></SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D405023802-04032003><SPAN=20
  class=3D168165317-04032003></SPAN></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D405023802-04032003><SPAN=20
  =
class=3D168165317-04032003>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></SPAN></FONT>=
</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D405023802-04032003><SPAN class=3D168165317-04032003>JD:&nbsp; =
You choose a=20
  design approach that is incompatible with GMPLS signalling when there =
are=20
  other design approaches that are compatible with GMPLS=20
  signalling?</SPAN></SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D405023802-04032003><SPAN=20
  =
class=3D168165317-04032003>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D&nbsp;&nbsp;</SPAN></=
SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D405023802-04032003><SPAN=20
  class=3D168165317-04032003></SPAN></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D405023802-04032003><SPAN =
class=3D168165317-04032003>&nbsp;</SPAN> As for=20
  your other comments, as I said keeping a connection alive is not the =
only call=20
  property, but just one. That doesn't mean it's not a requirement =
anymore, just=20
  one of them. As for the assertion, you're probably referring to this=20
  statement: "having a single call ID for a call makes tracking of the =
service=20
  much easier as well". Well, yes it is an assertion I guess, but I =
think it's=20
  an understandable assertion, no? How many IDs do you want to be used =
to=20
  represent a single service offered to a customer?</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D405023802-04032003></SPAN></FONT>&nbsp;</DIV>
  <DIV><SPAN class=3D405023802-04032003><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
  size=3D2>As for the virtual concat support, you're right again that =
G.7713.x=20
  does not support the general case either. This is because not all =
technical=20
  issues have been resolved. But the call ID provides the method for =
enabling=20
  tying the different virtual concat connections together as a single =
call=20
  service. Again there are multiple ways to do this, and we've chosen =
one.<SPAN=20
  =
class=3D168165317-04032003>&nbsp;</SPAN></FONT></FONT></FONT></SPAN></DI=
V>
  <DIV><SPAN class=3D405023802-04032003><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
  size=3D2><SPAN class=3D168165317-04032003>&nbsp;</SPAN><SPAN=20
  =
class=3D168165317-04032003>&nbsp;</SPAN></FONT></FONT></FONT></SPAN></DI=
V>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D405023802-04032003><SPAN=20
  =
class=3D168165317-04032003>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></SPAN></FO=
NT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D405023802-04032003><SPAN class=3D168165317-04032003>JD:&nbsp; =
Are you=20
  saying that your draft doesn't actually do what you originally =
claimed it=20
  did?</SPAN></SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D405023802-04032003><SPAN=20
  =
class=3D168165317-04032003>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></SPAN></FO=
NT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D405023802-04032003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D405023802-04032003>Thanks for your comments! Definitely helps =
to=20
  identify what different methods there are to solve the same=20
  problem.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D405023802-04032003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D405023802-04032003>Zhi</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D405023802-04032003></SPAN></FONT>&nbsp;</DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff =
2px solid; MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> John Drake=20
    [mailto:jdrake@calient.net]<BR><B>Sent:</B> Monday, March 03, 2003 =
8:55=20
    PM<BR><B>To:</B> 'Zhi-Wei Lin'; 'Zhi-Wei Lin';=20
    mpls@UU.NET<BR><B>Subject:</B> RE: FW: I-D=20
    ACTION:draft-andersson-mpls-g-chng-proc-00.txt<BR><BR></FONT></DIV>
    <DIV><SPAN class=3D999194600-04032003><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>Comments in line.&nbsp;</FONT></SPAN></DIV>
    <DIV><SPAN class=3D999194600-04032003><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=3D999194600-04032003><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>&nbsp;A general comment is that it occurs to me that MBB =
and the RSVP=20
    path protection I-D (</FONT><A=20
    =
href=3D"http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recov=
ery-e2e-signaling-00.txt"><FONT=20
    face=3DArial color=3D#0000ff=20
    =
size=3D2>http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-reco=
very-e2e-signaling-00.txt</FONT></A><FONT=20
    face=3DArial color=3D#0000ff size=3D2>)</FONT></SPAN><FONT =
face=3DArial><FONT=20
    color=3D#0000ff><FONT size=3D2>&nbsp;<SPAN =
class=3D999194600-04032003>both take=20
    advantage of the fact that RSVP-TE already has a a version of=20
    call/connection separation.&nbsp; It might be prudent to examine =
its=20
    capabilities before inventing a new=20
    mechanism</SPAN></FONT></FONT></FONT></DIV>
    <DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
    class=3D999194600-04032003></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
    =
class=3D999194600-04032003>Thanks,</SPAN></FONT></FONT></FONT></DIV>
    <DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
    class=3D999194600-04032003></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
    class=3D999194600-04032003>John</SPAN></FONT></FONT></FONT></DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
    class=3D999194600-04032003></SPAN></FONT><FONT face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Zhi-Wei Lin=20
    [mailto:zwlin@comcast.net]<BR><B>Sent:</B> Monday, March 03, 2003 =
4:28=20
    PM<BR><B>To:</B> John Drake; 'Zhi-Wei Lin'; =
mpls@UU.NET<BR><B>Subject:</B>=20
    RE: FW: I-D=20
    ACTION:draft-andersson-mpls-g-chng-proc-00.txt<BR><BR></DIV></FONT>
    <BLOCKQUOTE dir=3Dltr=20
    style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff =
2px solid; MARGIN-RIGHT: 0px">
      <DIV>
      <P><FONT face=3DArial color=3D#0000ff size=3D2>Hi =
John,</FONT></P>
      <P><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2>Thanks =
for the=20
      clarification.<SPAN class=3D684041700-04032003> Some more =
comments=20
      below...</SPAN></FONT></FONT></FONT></P>
      <P><FONT face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2>Keeping=20
      a&nbsp;connection alive while attempting to reroute it after =
outage.&nbsp;=20
      (This is basic RSVP and&nbsp; MBB allows you to reuse links on =
the failed=20
      path.)&nbsp;<BR><SPAN class=3D684041700-04032003><FONT =
face=3DArial=20
      color=3D#0000ff>[Zhi-Wei Lin]&nbsp;&nbsp;I don't think the intent =
of the=20
      call is simply to allow to keep connections alive.&nbsp;<SPAN=20
      =
class=3D999194600-04032003>&nbsp;</SPAN></FONT></SPAN></FONT></SPAN></FO=
NT></P>
      <P><FONT face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2><SPAN=20
      class=3D684041700-04032003><FONT face=3DArial =
color=3D#0000ff><SPAN=20
      =
class=3D999194600-04032003>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></FONT></SPAN>=
</FONT></SPAN></FONT></P>
      <P><FONT face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2><SPAN=20
      class=3D684041700-04032003><FONT face=3DArial =
color=3D#0000ff><SPAN=20
      class=3D999194600-04032003>JD:&nbsp; Are you saying that the =
above is not a=20
      requirement?</SPAN></FONT></SPAN></FONT></SPAN></FONT></P>
      <P><SPAN class=3D125442523-03032003><SPAN =
class=3D684041700-04032003><FONT=20
      face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
      =
class=3D999194600-04032003>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></FONT></FONT>=
</FONT></SPAN></SPAN></P>
      <P><SPAN class=3D125442523-03032003><SPAN =
class=3D684041700-04032003><FONT=20
      face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
      class=3D999194600-04032003>&nbsp;</SPAN>A call is much more =
related to the=20
      concept of providing service to the end-user. One of the services =
is the=20
      ability to keep a connection alive for, e.g., billing purposes, =
and having=20
      a single call ID for a call makes tracking of the service much =
easier as=20
      well.<SPAN=20
      =
class=3D999194600-04032003>&nbsp;</SPAN></FONT></FONT></FONT></SPAN></SP=
AN></P>
      <P><SPAN class=3D125442523-03032003><SPAN =
class=3D684041700-04032003><FONT=20
      face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
      =
class=3D999194600-04032003>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></FONT></FONT>=
</FONT></SPAN></SPAN></P>
      <P><SPAN class=3D125442523-03032003><SPAN =
class=3D684041700-04032003><FONT=20
      face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
      class=3D999194600-04032003>JD:&nbsp; This sounds like an=20
      assertion.</SPAN></FONT></FONT></FONT></SPAN></SPAN></P>
      <P><SPAN class=3D125442523-03032003><SPAN =
class=3D684041700-04032003><FONT=20
      face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
      =
class=3D999194600-04032003>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></FONT></FONT>=
</FONT></SPAN></SPAN><SPAN=20
      class=3D125442523-03032003><SPAN class=3D684041700-04032003><FONT =

      face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
      class=3D999194600-04032003>&nbsp;</SPAN>=20
      </FONT></FONT></FONT></SPAN></SPAN></P></DIV>
      <BLOCKQUOTE dir=3Dltr=20
      style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: =
#0000ff 2px solid; MARGIN-RIGHT: 0px">
        <DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><FONT size=3D2><SPAN=20
        class=3D125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><FONT size=3D2><SPAN =
class=3D125442523-03032003>Establishing a=20
        new path for an existing </SPAN>c<SPAN=20
        class=3D125442523-03032003>onnection so that </SPAN>l<SPAN=20
        class=3D125442523-03032003>inks along its&nbsp;current path may =
be taken=20
        out of service for maintenance</SPAN>.</FONT><SPAN=20
        class=3D125442523-03032003><FONT size=3D2>&nbsp; (This sounds =
like a=20
        definition of MBB.)<BR><SPAN class=3D684041700-04032003><FONT =
face=3DArial=20
        color=3D#0000ff>[Zhi-Wei Lin]&nbsp;&nbsp;Same comment as=20
        above.</FONT></SPAN></FONT></SPAN></FONT></DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><FONT size=3D2><SPAN=20
        class=3D125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><FONT size=3D2><SPAN=20
        class=3D125442523-03032003></SPAN></FONT></FONT><FONT =
face=3DTahoma><SPAN=20
        class=3D125442523-03032003><FONT size=3D2>Keeping track of the =
circuits in a=20
        virtual concatenation group.&nbsp; (I think this is covered =
with the=20
        SDH/SONET signalling draft.)<BR><SPAN =
class=3D684041700-04032003><FONT=20
        face=3DArial><FONT color=3D#0000ff>[Zhi-Wei Lin]&nbsp;This is =
really not=20
        covered in full in the SONET/SDH signaling draft. The current =
signaling=20
        draft puts a limitation on the virtual concatenation by =
requiring that=20
        all component members of the virtual concatenated signal travel =
along=20
        the same path. The general virtual concatenation mechanism =
allows for=20
        each component of the&nbsp;virtual concatenation group&nbsp;to =
travel=20
        along different paths. This is really where the call concept =
comes in=20
        handy. Again note that call is not designed specifially for the =
virtual=20
        concatenation, but it&nbsp;provides a nice way of supporting =
the=20
        multiple routings for each component virtual=20
        concatenated&nbsp;signal.<SPAN=20
        =
class=3D999194600-04032003>&nbsp;</SPAN></FONT></FONT></SPAN></FONT></SP=
AN></FONT></DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2><SPAN=20
        class=3D684041700-04032003><FONT face=3DArial><FONT =
color=3D#0000ff><SPAN=20
        =
class=3D999194600-04032003></SPAN></FONT></FONT></SPAN></FONT></SPAN></F=
ONT>&nbsp;</DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2><SPAN=20
        class=3D684041700-04032003><FONT face=3DArial><FONT =
color=3D#0000ff><SPAN=20
        =
class=3D999194600-04032003>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></FONT></FONT>=
</SPAN></FONT></SPAN></FONT></DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2><SPAN=20
        class=3D684041700-04032003><FONT face=3DArial><FONT =
color=3D#0000ff><SPAN=20
        class=3D999194600-04032003>JD:&nbsp; I don't think that =
multiple=20
        connections per call, especially connections that take =
different paths,=20
        is supported in either G.8080 or G.7713.x.&nbsp; Furthermore =
the=20
        existing RSVP-TE mechanisms could be used to support the =
general=20
        =
case&nbsp;</SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT></DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2><SPAN=20
        class=3D684041700-04032003><FONT face=3DArial><FONT =
color=3D#0000ff><SPAN=20
        =
class=3D999194600-04032003>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></FONT></FONT>=
</SPAN></FONT></SPAN></FONT></DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><FONT size=3D2><SPAN=20
        class=3D125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2>The other=20
        requirement I've heard is&nbsp;a need to have the ingress and =
egress=20
        nodes perform a capabilities exchange prior to establishing a=20
        connection, and that sounds like something Notify should be =
used=20
        for.<BR><SPAN class=3D684041700-04032003><FONT =
color=3D#0000ff><FONT=20
        face=3DArial>[Zhi-Wei Lin]&nbsp;Right, but this&nbsp;also means =
extending=20
        the Notify message. So it's a matter of choosing one =
method&nbsp;for=20
        support&nbsp;versus another. Also using the&nbsp;Notify to =
support this=20
        is just solving one part of the puzzle. It could be done, =
but&nbsp;the=20
        call mechanism gives&nbsp;you all the above, plus the "service" =
concept=20
        (whatever that is... ;-)&nbsp;<SPAN =
class=3D999194600-04032003><FONT=20
        =
color=3D#000000>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></FONT></SPAN><=
/FONT></DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2><SPAN=20
        class=3D684041700-04032003><FONT color=3D#0000ff><FONT =
face=3DArial><SPAN=20
        =
class=3D999194600-04032003></SPAN></FONT></FONT></SPAN></FONT></SPAN></F=
ONT>&nbsp;</DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2><SPAN=20
        class=3D684041700-04032003><FONT color=3D#0000ff><FONT =
face=3DArial><SPAN=20
        =
class=3D999194600-04032003>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></FONT></FO=
NT></SPAN></FONT></SPAN></FONT></DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2><SPAN=20
        class=3D684041700-04032003><FONT color=3D#0000ff><FONT =
face=3DArial><SPAN=20
        class=3D999194600-04032003>JD:&nbsp; It is not at all obvious =
from your=20
        draft&nbsp;whether you=20
        are:</SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT></DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2><SPAN=20
        class=3D684041700-04032003><FONT color=3D#0000ff><FONT =
face=3DArial><SPAN=20
        =
class=3D999194600-04032003></SPAN></FONT></FONT></SPAN></FONT></SPAN></F=
ONT>&nbsp;</DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2><SPAN=20
        class=3D684041700-04032003><FONT color=3D#0000ff><FONT =
face=3DArial><SPAN=20
        class=3D999194600-04032003>&nbsp;a) piggybacking a call ID on =
normal RSVP=20
        LSP =
setup&nbsp;</SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT></DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2><SPAN=20
        class=3D684041700-04032003><FONT color=3D#0000ff><FONT =
face=3DArial><SPAN=20
        =
class=3D999194600-04032003></SPAN></FONT></FONT></SPAN></FONT></SPAN></F=
ONT>&nbsp;</DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2><SPAN=20
        class=3D684041700-04032003><FONT color=3D#0000ff><FONT =
face=3DArial><SPAN=20
        =
class=3D999194600-04032003>or</SPAN></FONT></FONT></SPAN></FONT></SPAN><=
/FONT></DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2><SPAN=20
        class=3D684041700-04032003><FONT color=3D#0000ff><FONT =
face=3DArial><SPAN=20
        =
class=3D999194600-04032003></SPAN></FONT></FONT></SPAN></FONT></SPAN></F=
ONT>&nbsp;</DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2><SPAN=20
        class=3D684041700-04032003><FONT color=3D#0000ff><FONT =
face=3DArial><SPAN=20
        class=3D999194600-04032003>&nbsp;b) using a hacked up version =
of RSVP LSP=20
        setup to instantiate call state in all of the nodes along a =
path=20
        from&nbsp;ingress node&nbsp;to egress=20
        node.</SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT></DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2><SPAN=20
        class=3D684041700-04032003><FONT color=3D#0000ff><FONT =
face=3DArial><SPAN=20
        =
class=3D999194600-04032003></SPAN></FONT></FONT></SPAN></FONT></SPAN></F=
ONT>&nbsp;</DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2><SPAN=20
        class=3D684041700-04032003><FONT color=3D#0000ff><FONT =
face=3DArial><SPAN=20
        class=3D999194600-04032003>If it is the former, then using =
Notify is=20
        better because it allows a capabilities exchange prior to the =
allocation=20
        of any network resources.&nbsp; If it is the latter, then=20
        using&nbsp;Notify is better because you are =
creating&nbsp;severe=20
        interoperability problems with nodes that understand&nbsp;GMPLS =

        signalling but don't understand this hacked up version of RSVP =
setup, in=20
        support of something which is supposed to be =
an&nbsp;ingress/egress=20
        =
node&nbsp;function.&nbsp;&nbsp;&nbsp;&nbsp;</SPAN></FONT></FONT></SPAN><=
/FONT></SPAN></FONT></DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2><SPAN=20
        class=3D684041700-04032003><FONT color=3D#0000ff><FONT =
face=3DArial><SPAN=20
        =
class=3D999194600-04032003>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></FONT><=
/FONT></SPAN></FONT></SPAN></FONT></DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2><SPAN=20
        class=3D684041700-04032003><FONT color=3D#0000ff><FONT =
face=3DArial><SPAN=20
        =
class=3D999194600-04032003></SPAN></FONT></FONT></SPAN></FONT></SPAN></F=
ONT>&nbsp;</DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><SPAN=20
        class=3D125442523-03032003><SPAN =
class=3D684041700-04032003><FONT=20
        color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20
        class=3D999194600-04032003>&nbsp;</SPAN>For folks who wants to =
understand=20
        call, you can read G.8080 (that&nbsp;ITU-T G. stuff again! =
)&nbsp;or=20
        (*gasp!*) some of the ATM documents on call (Q.2981 I =
think).&nbsp;<SPAN=20
        class=3D999194600-04032003><FONT=20
        =
color=3D#000000>&nbsp;</FONT></SPAN></FONT></FONT></FONT></SPAN></SPAN><=
/DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><SPAN=20
        class=3D125442523-03032003><SPAN =
class=3D684041700-04032003><FONT=20
        color=3D#0000ff><FONT face=3DArial><FONT size=3D2><SPAN=20
        =
class=3D999194600-04032003></SPAN></FONT></FONT></FONT></SPAN></SPAN><FO=
NT=20
        face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2><SPAN=20
        class=3D684041700-04032003><FONT face=3DArial><SPAN=20
        =
class=3D999194600-04032003></SPAN></FONT></SPAN></FONT></SPAN></FONT>&nb=
sp;</DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2><SPAN=20
        class=3D684041700-04032003><FONT face=3DArial><FONT =
color=3D#0000ff><SPAN=20
        =
class=3D999194600-04032003>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></FONT><=
/FONT></SPAN></FONT></SPAN></FONT></DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2><SPAN=20
        class=3D684041700-04032003><FONT face=3DArial><FONT =
color=3D#0000ff><SPAN=20
        class=3D999194600-04032003>JD:&nbsp; As I've said before, =
during my tenure=20
        at the ATM Forum, we could not get call/connection separation =
to work in=20
        PNNI.</SPAN></FONT></FONT></SPAN></FONT></SPAN></FONT></DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><SPAN class=3D125442523-03032003><FONT =
size=3D2><SPAN=20
        class=3D684041700-04032003><FONT face=3DArial><FONT =
color=3D#0000ff><SPAN=20
        =
class=3D999194600-04032003>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></FONT><=
/FONT></SPAN></FONT></SPAN></FONT></DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><SPAN=20
        class=3D125442523-03032003><FONT color=3D#0000ff><FONT =
face=3DArial><FONT=20
        size=3D2><SPAN class=3D999194600-04032003><FONT=20
        =
color=3D#000000></FONT></SPAN></FONT></FONT></FONT></SPAN>&nbsp;</DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><SPAN=20
        class=3D125442523-03032003><FONT color=3D#0000ff><FONT =
face=3DArial><FONT=20
        size=3D2><SPAN class=3D999194600-04032003>&nbsp;</SPAN>Of =
course those of=20
        you who still uses your telephone or even your cellphone are =
everyday=20
        making a "call" (but only always one connection within the call =
-- very=20
        limited, huh??)<SPAN=20
        =
class=3D999194600-04032003>&nbsp;</SPAN></FONT></FONT></FONT></SPAN></DI=
V>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
size=3D2><SPAN=20
        class=3D125442523-03032003><FONT color=3D#0000ff><FONT =
face=3DArial><SPAN=20
        =
class=3D999194600-04032003></SPAN></FONT></FONT></SPAN></FONT>&nbsp;</DI=
V>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><FONT size=3D2><SPAN=20
        class=3D125442523-03032003>Thanks,</SPAN></FONT></FONT></DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><FONT size=3D2><SPAN=20
        class=3D125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><FONT size=3D2><SPAN=20
        class=3D125442523-03032003>John</SPAN></FONT></FONT></DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT=20
        face=3DTahoma><FONT size=3D2><SPAN=20
        class=3D125442523-03032003></SPAN></FONT></FONT>&nbsp;</DIV>
        <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
        size=3D2>-----Original Message-----<BR><B>From:</B> Zhi-Wei Lin =

        [mailto:zhiweilin@yahoo.com]<BR><B>Sent:</B> Sunday, March 02, =
2003=20
        11:21 AM<BR><B>To:</B> mpls@uu.net<BR><B>Cc:</B> John=20
        Drake<BR><B>Subject:</B> Re: FW: I-D=20
        ACTION:draft-andersson-mpls-g-chng-proc-00.txt=20
        <BR><BR></FONT></DIV></DIV>
        <BLOCKQUOTE=20
        style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: =
#0000ff 2px solid">
          <P>Hi John,=20
          <P>I was wondering about the statements you've made below, =
especially=20
          the one about "all of them can be handled with the existing =
Make=20
          Before Break component of RSVP-TE". I'm a little slow, so =
could you=20
          elaborate a little more as to how this is related to the=20
          call/connection concept, and how the make-before-break =
actually=20
          handles the call service concept?=20
          <P>Thanks<BR>Zhi=20
          <P>
          <P>&nbsp;From: John Drake =
[mailto:jdrake@calient.net]<BR>Sent: Friday,=20
          February 28, 2003 4:15 PM<BR>To: 'erosen@cisco.com'; Varma, =
Eve L=20
          (Eve)<BR>Cc: 'curtis@fictitious.org'; George Newsome; Stephen =

          Trowbridge; Loa<BR>Andersson; mpls@UU.NET<BR>Subject: RE: I-D =

          ACTION:draft-andersson-mpls-g-chng-proc-00.txt <BR><BR><BR>I =
agree=20
          with Eric.<BR><BR>As an example, we have call/connection =
separation,=20
          which has been kicking<BR>around since the early days of =
ISDN. In=20
          discussions as to why it is needed,<BR>the first reason is =
always=20
          "because". Once past that, I have consistently<BR>heard four =
or five=20
          examples cited. What is interesting is that all of =
them<BR>can be=20
          handled with the existing Make Before Break component of =
RSVP-TE.=20
          <BR><BR>Thanks,<BR><BR>John<BR><BR>&gt; -----Original=20
          Message-----<BR>&gt; From: Eric Rosen=20
          [mailto:erosen@cisco.com]<BR>&gt; Sent: Friday, February 28, =
2003=20
          12:54 PM<BR>&gt; To: Varma, Eve L (Eve)<BR>&gt; Cc:=20
          'curtis@fictitious.org'; George Newsome; Stephen Trowbridge;=20
          Loa<BR>&gt; Andersson; mpls@UU.NET<BR>&gt; Subject: Re: I-D=20
          ACTION:draft-andersson-mpls-g-chng-proc-00.txt <BR>&gt; =
<BR>&gt;=20
          <BR>&gt; <BR>&gt; Eve&gt; For individual contributor drafts =
coming in,=20
          it's quite <BR>&gt; appropriate to<BR>&gt; Eve&gt; evaluate=20
          requirements and determine if they are <BR>&gt; legitimate. =
It's=20
          a<BR>&gt; Eve&gt; different case when another SDO, =
responsible for a=20
          <BR>&gt; non-IP applications<BR>&gt; Eve&gt; domain, has =
established a=20
          set of requirements related to <BR>&gt; that domain.<BR>&gt; =
<BR>&gt;=20
          I'd certainly disagree with that. Many of the <BR>&gt; =
"requirements"=20
          I see from<BR>&gt; other organizations are not requirements =
at all,=20
          but <BR>&gt; just dogmatic<BR>&gt; statements of =
connection-oriented=20
          religion. If the IETF <BR>&gt; were to accept<BR>&gt; =
requirements=20
          from other organizations, it would quickly be <BR>&gt; =
inundated=20
          with<BR>&gt; "requirements" to make IP behave exactly like =
ATM. In=20
          <BR>&gt; fact, anyone who<BR>&gt; works in the PWE3 group can =
testify=20
          that such "requirements" <BR>&gt; come in all the<BR>&gt; =
time.=20
          <BR>&gt; <BR>&gt; <BR>&gt; </P>
          <P><BR>
          <HR SIZE=3D1>
          Do you Yahoo!?<BR><A=20
          =
href=3D"http://rd.yahoo.com/finance/mailtagline/*http://taxes.yahoo.com/=
">Yahoo!=20
          Tax Center</A> - forms, calculators, tips, and=20
      =
more</BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></B=
ODY></HTML>

------_=_NextPart_001_01C2E278.A9CEF220--


From owner-mpls@UU.NET  Tue Mar  4 14:33:24 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06760
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 14:33:24 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepi28521
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 19:35:26 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoepi28469;
	Tue, 4 Mar 2003 19:35:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoepe25613
	for mpls-outgoing; Tue, 4 Mar 2003 18:35:50 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoepe25606
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 18:35:34 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoepe10609
	for <mpls@uu.net>; Tue, 4 Mar 2003 18:35:12 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepe04727
	for <mpls@uu.net>; Tue, 4 Mar 2003 18:35:12 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoepe04694
	for <mpls@uu.net>; Tue, 4 Mar 2003 18:35:08 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h24IZ6JR015928
	for <mpls@uu.net>; Tue, 4 Mar 2003 13:35:06 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA19817 for <mpls@uu.net>; Tue, 4 Mar 2003 13:35:05 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h24IZ5e13238 for mpls@uu.net; Tue, 4 Mar 2003 13:35:05 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoepe25502
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 18:34:04 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoepe22224
	for <mpls@UU.NET>; Tue, 4 Mar 2003 18:32:46 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepe01299
	for <mpls@UU.NET>; Tue, 4 Mar 2003 18:32:45 GMT
Received: from fig.isi.edu by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fig.isi.edu [128.9.160.78])
	id QQoepe01287
	for <mpls@UU.NET>; Tue, 4 Mar 2003 18:32:44 GMT
Received: from fig.isi.edu (localhost.localdomain [127.0.0.1])
	by fig.isi.edu (8.12.8/8.12.8) with ESMTP id h24IXJ1K014697;
	Tue, 4 Mar 2003 10:33:19 -0800
Received: from localhost (berson@localhost)
	by fig.isi.edu (8.12.8/8.12.5/Submit) with ESMTP id h24IXJQ0014693;
	Tue, 4 Mar 2003 10:33:19 -0800
X-Authentication-Warning: fig.isi.edu: berson owned process doing -bs
Date: Tue, 4 Mar 2003 10:33:19 -0800 (PST)
From: Steven Berson <berson@isi.edu>
To: David Charlap <David.Charlap@marconi.com>
cc: mpls@UU.NET, <rsvp@isi.edu>
Subject: Re: [Rsvp] Re: help
In-Reply-To: <Pine.LNX.4.44.0303040956310.14121-100000@fig.isi.edu>
Message-ID: <Pine.LNX.4.44.0303041029190.14121-100000@fig.isi.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

OK, I normally don't respond to my own messages, but I misunderstood 
the question.  I understood the question to be asking how to use RSVP 
to reserve resources for IPSEC data flows.  I don't recall seeing the 
original message, but as I read David's response carefully, it appears 
that the question really is about using IPSEC to protect the RSVP 
protocol messages themselves.  David gives a good answer to the latter
question.

Regards,
Steve

On Tue, 4 Mar 2003, Steven Berson wrote:

> Actually, RSVP can be used with IPSEC.  See RFC 2207, ``RSVP 
> Extensions for IPSEC Data Flows''.
> 
> Regards,
> Steve
> 
> On Tue, 4 Mar 2003, David Charlap wrote:
> 
> > Harish Kumtakar wrote:
> > > 
> > >      Why IPSEC can not be used in RSVP to care of security. Please throw 
> > > some light on this aspect.
> > 
> > The reason it isn't in classical RSVP is because IPSEC secures two 
> > endpoints.  But the nature of RSVP is such that packets are supposed to 
> > be intercepted and processed by transit routers.
> > 
> > An RSVP router does not send a Path message to his neighbor.  He sends 
> > it to the ultimate destination address, with the router-alert option, so 
> > that RSVP-aware routers along the way may intercept and process the 
> > packet.  This is fundamentally incompatible with IPSEC - where the 
> > packet is encrypted such that transit routers can not intercept anything.
> > 
> > If you want to use IPSEC with RSVP, then you must send packets directly 
> > to neighbors and abandon the use of router-alert.  This isn't a problem 
> > for RSVP-TE, since the presence of non-RSVP routers isn't permitted in 
> > an MPLS/RSVP-TE network.  But it eliminates the ability for classical 
> > RSVP to work over networks with non-RSVP nodes - something that is a key 
> > goal of the RSVP protocol.
> > 
> > IPSEC also makes multicast much more CPU intensive.  If every packet is 
> > encrypted, then you can't simply generate one Path message for 
> > transmission to all downstream nodes in a multicast group.  You have to 
> > generate multiple separate packets and encrypt them individually.
> > 
> > -- David
> > 
> > _______________________________________________
> > Rsvp mailing list
> > Rsvp@mailman.isi.edu
> > http://mailman.isi.edu/mailman/listinfo/rsvp
> > 
> 
> _______________________________________________
> Rsvp mailing list
> Rsvp@mailman.isi.edu
> http://mailman.isi.edu/mailman/listinfo/rsvp
> 



From owner-mpls@UU.NET  Tue Mar  4 14:40:26 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06969
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 14:40:25 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepi20486
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 19:42:26 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoepi20288;
	Tue, 4 Mar 2003 19:42:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoepe26217
	for mpls-outgoing; Tue, 4 Mar 2003 18:41:21 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoepe26209
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 18:41:19 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoepe04928
	for <mpls@uu.net>; Tue, 4 Mar 2003 18:41:05 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepe09630
	for <mpls@uu.net>; Tue, 4 Mar 2003 18:41:05 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoepe09623
	for <mpls@uu.net>; Tue, 4 Mar 2003 18:41:04 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h24If2Nh013128
	for <mpls@uu.net>; Tue, 4 Mar 2003 13:41:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA20376 for <mpls@uu.net>; Tue, 4 Mar 2003 13:41:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h24If2p14231 for mpls@uu.net; Tue, 4 Mar 2003 13:41:02 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoepe25935
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 18:38:42 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoepe25438
	for <mpls@UU.NET>; Tue, 4 Mar 2003 18:38:25 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepe08764
	for <mpls@UU.NET>; Tue, 4 Mar 2003 18:38:24 GMT
Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoepe08729
	for <mpls@UU.NET>; Tue, 4 Mar 2003 18:38:23 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id NAA00693;
	Tue, 4 Mar 2003 13:36:16 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303041836.NAA00693@workhorse.fictitious.org>
To: Stephen Trowbridge <sjtrowbridge@lucent.com>
cc: curtis@fictitious.org, Yangguang Xu <xuyg@lucent.com>,
        Kireeti Kompella <kireeti@juniper.net>,
        Zhi-Wei Lin <zwlin@comcast.net>, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: billing & call management (was Re: a propos of nothing at all) 
In-reply-to: Your message of "Tue, 04 Mar 2003 11:04:18 MST."
             <3E64EAA2.FDD36434@lucent.com> 
Date: Tue, 04 Mar 2003 13:36:16 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <3E64EAA2.FDD36434@lucent.com>, Stephen Trowbridge writes:
> Curtis,
> Working for an equipment manufacturer, I have never felt that it was
> my place to tell a SP how they should bill for their services. I don't
> think we should preclude any particular billing model by our architecture.
> It is the market that should decide what gets offered at a flat rate:
> not the equipment, and certainly not the standards.
> Steve


Steve,

This is no different from the 1995 argument that IP should go away
becasue there is no good way to bill on a per connection basis.

What you are asking for is customer initiated connections which can be
metered for billing purposes.

I used to work at two major ISPs in the architecture group.  There was
no such requirement.  Since leaving and being on the vendor side I
have not heard any such requirement from customers.

Well actually if you count Enron as a customer, Enron's bandwidth
brokering required customer initiated connections with AAA and
possibly metering.  They hadn't decided on the latter before they gave
up and switched their business plan to a QoS enabled backbone for VOD
(remember the Enron/Blockbuster announcement).  We all know how far
both of those ideas went.

It appears that you are not arguing that any SP wishes to repeat
Enron's folly (the first of the two), just that we should extend the
protocols to accommodate it just in case.  That doesn't sound like a
strong case for a set of requirements.

Curtis


> Curtis Villamizar wrote:
> > 
> > In message <3E64A690.D3BB8603@lucent.com>, Yangguang Xu writes:
> > >
> > >
> > > Kireeti,
> > >
> > > Yea, you are right. You pay flat rate for a DSL.  [...]
> > 
> > Lets look up and down the food chain.
> > 
> >   At consumer level, service is tiered flat rate.  DSL, cable IP, cell
> >   phone, now POTS.
> > 
> >   IP service at T1 or higher has always been flat rate or burstable
> >   tiered flat rate.
> > 
> >   Switched services such as FR and ATM have been flat rate PVC or
> >   SPVC.  SVC service is generally not available and where it is has
> >   almost negligible penetration.
> > 
> >   At the high end, leased lines, leased lambdas, and leased dark fiber
> >   is definitely not signaled dynamicly by the customer so there is not
> >   "call" or customer connection.
> > 
> > What has had a call model:
> > 
> >   X.25
> > 
> >   ISDN
> > 
> > Even ISDN, where it has been at all successful, is flat rate.  Where
> > it is metered, market penetration is zip.  (btw - Its still metered
> > where I live afaik and might as well not be offered).
> > 
> > > Furthermore, you are talking about billing. Indeed, one of the reasons op
> erto
> > > rs
> > > choose flat rate is to simplify billing because the control/management pl
> ane
> > > can't generate accurate information.
> > >
> > > The bottom line is that as the building block of the overall management
> > > functions, control plane should provide adequate function to support high
>  lev
> > > el
> > > services. Otherwise, everything becomes commodity.
> > 
> > So what does this billing and control/management plane nonsense mean
> > in a world with flat rate or tiered service with no customer initiated
> > connections to bill for?  It has absolutely no purpose except to try
> > to perpetuate a mindset and perpetuate a hope that services with the
> > X.25 and ISDN metered billing model will somehow gain penetration and
> > the SP will be able to milk huge profits from it.  Unfortunately the
> > customer isn't stupid enough, so short of a return to monopoly rule or
> > other exclusion of competition, it won't happen.
> > 
> > > Yangguang
> > 
> > Curtis
> 



From owner-mpls@UU.NET  Tue Mar  4 14:49:56 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07194
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 14:49:56 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepj08502
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 19:51:58 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoepj08381;
	Tue, 4 Mar 2003 19:51:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoepf27388
	for mpls-outgoing; Tue, 4 Mar 2003 18:52:53 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoepf27374
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 18:52:36 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoepf12248
	for <mpls@uu.net>; Tue, 4 Mar 2003 18:51:20 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepf25924
	for <mpls@uu.net>; Tue, 4 Mar 2003 18:51:19 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoepf25915
	for <mpls@uu.net>; Tue, 4 Mar 2003 18:51:19 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h24IpGNh013737
	for <mpls@uu.net>; Tue, 4 Mar 2003 13:51:16 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA21262 for <mpls@uu.net>; Tue, 4 Mar 2003 13:51:16 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h24IpGU15772 for mpls@uu.net; Tue, 4 Mar 2003 13:51:16 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoepe25834
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 18:36:54 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoepe14164
	for <mpls@UU.NET>; Tue, 4 Mar 2003 18:35:46 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepe02362
	for <mpls@UU.NET>; Tue, 4 Mar 2003 18:35:46 GMT
Received: from david.siemens.de by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: david.siemens.de [192.35.17.14])
	id QQoepe02333
	for <mpls@UU.NET>; Tue, 4 Mar 2003 18:35:45 GMT
Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14])
	by david.siemens.de (8.11.6/8.11.6) with ESMTP id h24IZfb13869;
	Tue, 4 Mar 2003 19:35:41 +0100 (MET)
Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99])
	by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id h24IZfr13590;
	Tue, 4 Mar 2003 19:35:41 +0100 (MET)
Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19)
	id <FMHXS3W4>; Tue, 4 Mar 2003 19:35:40 +0100
Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675EB4@mchp905a.mch.sbs.de>
From: Tschofenig Hannes <Hannes.Tschofenig@mchp.siemens.de>
To: "'Steven Berson'" <berson@ISI.EDU>,
        David Charlap
	 <David.Charlap@marconi.com>
Cc: mpls@UU.NET, rsvp@ISI.EDU
Subject: RE: [Rsvp] Re: help
Date: Tue, 4 Mar 2003 19:35:40 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

hi steve

this is something different. 

rfc 2207 addresses ipsec protected data traffic. with this rfc the authors
add the ability for rsvp to provide qos signaling for ipsec protected data
traffic based on the available fields (spi instead of the port and transport
protocol field). 

ciao
hannes


> -----Original Message-----
> From: Steven Berson [mailto:berson@ISI.EDU]
> Sent: Tuesday, March 04, 2003 7:00 PM
> To: David Charlap
> Cc: mpls@UU.NET; rsvp@ISI.EDU
> Subject: Re: [Rsvp] Re: help
> 
> 
> Actually, RSVP can be used with IPSEC.  See RFC 2207, ``RSVP 
> Extensions for IPSEC Data Flows''.
> 
> Regards,
> Steve
> 
> On Tue, 4 Mar 2003, David Charlap wrote:
> 
> > Harish Kumtakar wrote:
> > > 
> > >      Why IPSEC can not be used in RSVP to care of 
> security. Please throw 
> > > some light on this aspect.
> > 
> > The reason it isn't in classical RSVP is because IPSEC secures two 
> > endpoints.  But the nature of RSVP is such that packets are 
> supposed to 
> > be intercepted and processed by transit routers.
> > 
> > An RSVP router does not send a Path message to his 
> neighbor.  He sends 
> > it to the ultimate destination address, with the 
> router-alert option, so 
> > that RSVP-aware routers along the way may intercept and process the 
> > packet.  This is fundamentally incompatible with IPSEC - where the 
> > packet is encrypted such that transit routers can not 
> intercept anything.
> > 
> > If you want to use IPSEC with RSVP, then you must send 
> packets directly 
> > to neighbors and abandon the use of router-alert.  This 
> isn't a problem 
> > for RSVP-TE, since the presence of non-RSVP routers isn't 
> permitted in 
> > an MPLS/RSVP-TE network.  But it eliminates the ability for 
> classical 
> > RSVP to work over networks with non-RSVP nodes - something 
> that is a key 
> > goal of the RSVP protocol.
> > 
> > IPSEC also makes multicast much more CPU intensive.  If 
> every packet is 
> > encrypted, then you can't simply generate one Path message for 
> > transmission to all downstream nodes in a multicast group.  
> You have to 
> > generate multiple separate packets and encrypt them individually.
> > 
> > -- David
> > 
> > _______________________________________________
> > Rsvp mailing list
> > Rsvp@mailman.isi.edu
> > http://mailman.isi.edu/mailman/listinfo/rsvp
> > 
> 
> _______________________________________________
> Rsvp mailing list
> Rsvp@mailman.isi.edu
> http://mailman.isi.edu/mailman/listinfo/rsvp
> 



From owner-mpls@UU.NET  Tue Mar  4 15:12:47 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08652
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 15:12:47 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepk15423
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 20:14:49 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoepk15335;
	Tue, 4 Mar 2003 20:14:46 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoepg17256
	for mpls-outgoing; Tue, 4 Mar 2003 19:14:13 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoepg17238
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 19:14:01 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoepg20250
	for <mpls@uu.net>; Tue, 4 Mar 2003 19:13:12 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepg28940
	for <mpls@uu.net>; Tue, 4 Mar 2003 19:13:11 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoepg28928
	for <mpls@uu.net>; Tue, 4 Mar 2003 19:13:11 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h24JD8Nh015198
	for <mpls@uu.net>; Tue, 4 Mar 2003 14:13:08 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA23006 for <mpls@uu.net>; Tue, 4 Mar 2003 14:13:07 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h24JD7720169 for mpls@uu.net; Tue, 4 Mar 2003 14:13:07 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoepg01674
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 19:01:01 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoepg29264
	for <mpls@UU.NET>; Tue, 4 Mar 2003 19:00:46 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepg10616
	for <mpls@UU.NET>; Tue, 4 Mar 2003 19:00:45 GMT
Received: from david.siemens.de by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: david.siemens.de [192.35.17.14])
	id QQoepg10579
	for <mpls@UU.NET>; Tue, 4 Mar 2003 19:00:44 GMT
Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14])
	by david.siemens.de (8.11.6/8.11.6) with ESMTP id h24J0fb23200;
	Tue, 4 Mar 2003 20:00:41 +0100 (MET)
Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99])
	by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id h24J0fr22763;
	Tue, 4 Mar 2003 20:00:41 +0100 (MET)
Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19)
	id <FMHXS36J>; Tue, 4 Mar 2003 20:00:40 +0100
Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675EB5@mchp905a.mch.sbs.de>
From: Tschofenig Hannes <Hannes.Tschofenig@mchp.siemens.de>
To: "'David Charlap'" <David.Charlap@marconi.com>, mpls@UU.NET, rsvp@ISI.EDU
Subject: RE: [Rsvp] Re: help
Date: Tue, 4 Mar 2003 20:00:40 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

hi all, 

thanks for raising this issue.  please see my comments below:

> Harish Kumtakar wrote:
> > 
> >      Why IPSEC can not be used in RSVP to care of security. 
> Please throw 
> > some light on this aspect.
> 
> The reason it isn't in classical RSVP is because IPSEC secures two 
> endpoints.  But the nature of RSVP is such that packets are 
> supposed to 
> be intercepted and processed by transit routers.
> 
> An RSVP router does not send a Path message to his neighbor.  
> He sends 
> it to the ultimate destination address, with the router-alert 
> option, so 
> that RSVP-aware routers along the way may intercept and process the 
> packet.  This is fundamentally incompatible with IPSEC - where the 
> packet is encrypted such that transit routers can not 
> intercept anything.

may i summarize this issue:
the problem is the combination of signaling message delivery and discovery. 
(there is a relationship to the end-to-end addressing.)

using this combination is probably not the best idea since you have to know
your next rsvp aware router to select your security association to protect
it properly. 

> 
> If you want to use IPSEC with RSVP, then you must send 
> packets directly 
> to neighbors and abandon the use of router-alert.  This isn't 
> a problem 
> for RSVP-TE, since the presence of non-RSVP routers isn't 
> permitted in 
> an MPLS/RSVP-TE network.

i guess that there are more issues:

the rsvp-te signaling message is still addressed to the destination address
(rather than to the next rsvp node) although it might contain a route
object. hence you use a discovery although you do not really need it (you
know that your next node is rsvp capable and you might even know the entire
path.)

protecting a rsvp-te can only be done in ipsec tunnel mode. ipsec tunnel
mode modifies the routing of the signaling message. to protect an rsvp
signaling message (with ipsec) requires that you have have an spd entry
which says which traffic is going to be protected. if you have more than one
possible path (two possible neighboring routers) then you have two make your
spd entry accordingly. which is difficult since the source address and the
destination address is not the address of the nodes where the protected rsvp
message should travel. if you manage it to create this ipsec sa then you
need to change it once a route change happens to reflect the new path. 


  But it eliminates the ability for classical 
> RSVP to work over networks with non-RSVP nodes - something 
> that is a key 
> goal of the RSVP protocol.

for ipsec handling there are more difficulties.
the fact that you do not necessarily know your next rsvp capable router is a
bad thing (especially in case of non-rsvp cloudes/nodes or for applications
such as middlebox communication where nodes are sparsely distributed. 

> 
> IPSEC also makes multicast much more CPU intensive.  If every 
> packet is 
> encrypted, then you can't simply generate one Path message for 
> transmission to all downstream nodes in a multicast group.  
> You have to 
> generate multiple separate packets and encrypt them individually.

my 5-cents on the multicast handling. 
since the path message is addressed to the destination ip address (which is
a multicast address in this case) you have to use multicast security for
message security. if you sparate signaling message delivery from discovery i
guess that you could address individual rsvp nodes directly. 

btw, you might want to take a look at section 5 of 
http://www.tschofenig.com/drafts/draft-ietf-nsis-rsvp-sec-properties-01.txt.
i would highly appreciate your comments. 

ciao
hannes



> 
> -- David
> 
> _______________________________________________
> Rsvp mailing list
> Rsvp@mailman.isi.edu
> http://mailman.isi.edu/mailman/listinfo/rsvp
> 



From owner-mpls@UU.NET  Tue Mar  4 15:13:27 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08700
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 15:13:27 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepl05914
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 20:15:29 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoepl05740;
	Tue, 4 Mar 2003 20:15:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoepg17261
	for mpls-outgoing; Tue, 4 Mar 2003 19:14:16 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoepg17239
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 19:14:01 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoepg21263
	for <mpls@UU.NET>; Tue, 4 Mar 2003 19:13:48 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepg22584
	for <mpls@UU.NET>; Tue, 4 Mar 2003 19:13:47 GMT
Received: from auemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: auemail1.lucent.com [192.11.223.161])
	id QQoepg22563
	for <mpls@UU.NET>; Tue, 4 Mar 2003 19:13:46 GMT
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by auemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h24JDju25731;
	Tue, 4 Mar 2003 14:13:45 -0500 (EST)
Received: from lucent.com (sjtrowbridge-1.dr.lucent.com [135.4.20.16]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id NAA25214; Tue, 4 Mar 2003 13:13:43 -0600 (CST)
Message-ID: <3E64FAE6.AC5BC96@lucent.com>
Date: Tue, 04 Mar 2003 12:13:42 -0700
From: Stephen Trowbridge <sjtrowbridge@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5  (Windows NT 5.0; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: curtis@fictitious.org
CC: Yangguang Xu <xuyg@lucent.com>, Kireeti Kompella <kireeti@juniper.net>,
        Zhi-Wei Lin <zwlin@comcast.net>, mpls@UU.NET
Subject: Re: billing & call management (was Re: a propos of nothing at all)
References: <200303041836.NAA00693@workhorse.fictitious.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Curtis,
OK, so it is your place to tell SPs how to bill for their services rather
than mine.

No doubt that there are certain services at certain usage levels where it
is better for the SP and for the customer to bill at a flat rate. All I am
saying is that this is not necessarily the correct model in all cases.
Sure, I can pay a flat rate for ulimited long distance calling if I choose
to, but this flat rate is about 10x my normal long distance bill - so I
choose to pay per call instead. But if I follow your model, I can expect
what I pay for very few long distance calls to increase dramatically in
the near future, since nobody will be able to measure my usage for VoIP
and their only choice will be to charge me the amount that covers average
usage.

I pay a flat rate (~$45/mo with taxes) for my cable modem service. This is
a bargain since we have 4 computers (2 tech. industry professionals, 1 CS
major college student, one high school student) behind my router and we
make pretty heavy use of it. But would you blame a SP for wanting to provide a
metered service also to try to get more cable modem penetration among light
users?

Again, these are market related decisions to be made by the SPs. Not
technology related decisions to be made by the equipment designers.
Regards,
Steve

Curtis Villamizar wrote:
> 
> In message <3E64EAA2.FDD36434@lucent.com>, Stephen Trowbridge writes:
> > Curtis,
> > Working for an equipment manufacturer, I have never felt that it was
> > my place to tell a SP how they should bill for their services. I don't
> > think we should preclude any particular billing model by our architecture.
> > It is the market that should decide what gets offered at a flat rate:
> > not the equipment, and certainly not the standards.
> > Steve
> 
> Steve,
> 
> This is no different from the 1995 argument that IP should go away
> becasue there is no good way to bill on a per connection basis.
> 
> What you are asking for is customer initiated connections which can be
> metered for billing purposes.
> 
> I used to work at two major ISPs in the architecture group.  There was
> no such requirement.  Since leaving and being on the vendor side I
> have not heard any such requirement from customers.
> 
> Well actually if you count Enron as a customer, Enron's bandwidth
> brokering required customer initiated connections with AAA and
> possibly metering.  They hadn't decided on the latter before they gave
> up and switched their business plan to a QoS enabled backbone for VOD
> (remember the Enron/Blockbuster announcement).  We all know how far
> both of those ideas went.
> 
> It appears that you are not arguing that any SP wishes to repeat
> Enron's folly (the first of the two), just that we should extend the
> protocols to accommodate it just in case.  That doesn't sound like a
> strong case for a set of requirements.
> 
> Curtis
> 
> > Curtis Villamizar wrote:
> > >
> > > In message <3E64A690.D3BB8603@lucent.com>, Yangguang Xu writes:
> > > >
> > > >
> > > > Kireeti,
> > > >
> > > > Yea, you are right. You pay flat rate for a DSL.  [...]
> > >
> > > Lets look up and down the food chain.
> > >
> > >   At consumer level, service is tiered flat rate.  DSL, cable IP, cell
> > >   phone, now POTS.
> > >
> > >   IP service at T1 or higher has always been flat rate or burstable
> > >   tiered flat rate.
> > >
> > >   Switched services such as FR and ATM have been flat rate PVC or
> > >   SPVC.  SVC service is generally not available and where it is has
> > >   almost negligible penetration.
> > >
> > >   At the high end, leased lines, leased lambdas, and leased dark fiber
> > >   is definitely not signaled dynamicly by the customer so there is not
> > >   "call" or customer connection.
> > >
> > > What has had a call model:
> > >
> > >   X.25
> > >
> > >   ISDN
> > >
> > > Even ISDN, where it has been at all successful, is flat rate.  Where
> > > it is metered, market penetration is zip.  (btw - Its still metered
> > > where I live afaik and might as well not be offered).
> > >
> > > > Furthermore, you are talking about billing. Indeed, one of the reasons op
> > erto
> > > > rs
> > > > choose flat rate is to simplify billing because the control/management pl
> > ane
> > > > can't generate accurate information.
> > > >
> > > > The bottom line is that as the building block of the overall management
> > > > functions, control plane should provide adequate function to support high
> >  lev
> > > > el
> > > > services. Otherwise, everything becomes commodity.
> > >
> > > So what does this billing and control/management plane nonsense mean
> > > in a world with flat rate or tiered service with no customer initiated
> > > connections to bill for?  It has absolutely no purpose except to try
> > > to perpetuate a mindset and perpetuate a hope that services with the
> > > X.25 and ISDN metered billing model will somehow gain penetration and
> > > the SP will be able to milk huge profits from it.  Unfortunately the
> > > customer isn't stupid enough, so short of a return to monopoly rule or
> > > other exclusion of competition, it won't happen.
> > >
> > > > Yangguang
> > >
> > > Curtis
> >


From owner-mpls@UU.NET  Tue Mar  4 15:25:00 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09118
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 15:25:00 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepl12353
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 20:27:01 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoepl12098;
	Tue, 4 Mar 2003 20:26:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoepi19399
	for mpls-outgoing; Tue, 4 Mar 2003 19:36:49 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoepi19390
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 19:36:42 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoepi25085
	for <mpls@uu.net>; Tue, 4 Mar 2003 19:36:20 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepi08921
	for <mpls@uu.net>; Tue, 4 Mar 2003 19:36:18 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoepi08884
	for <mpls@uu.net>; Tue, 4 Mar 2003 19:36:16 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h24JaAJR020148
	for <mpls@uu.net>; Tue, 4 Mar 2003 14:36:14 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA24944 for <mpls@uu.net>; Tue, 4 Mar 2003 14:36:09 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h24Ja9424729 for mpls@uu.net; Tue, 4 Mar 2003 14:36:09 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoepi19130
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 19:34:57 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoepi25607
	for <mpls@UU.NET>; Tue, 4 Mar 2003 19:34:14 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepi06035
	for <mpls@UU.NET>; Tue, 4 Mar 2003 19:34:13 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoepi06020
	for <mpls@UU.NET>; Tue, 4 Mar 2003 19:34:12 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h24JY0Nh016408;
	Tue, 4 Mar 2003 14:34:01 -0500 (EST)
Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA24766; Tue, 4 Mar 2003 14:34:00 -0500 (EST)
Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA19202; Tue, 4 Mar 2003 14:34:00 -0500 (EST)
Message-Id: <200303041934.OAA19202@bifocal.cisco.com>
X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs
To: Steven Berson <berson@isi.edu>
cc: David Charlap <David.Charlap@marconi.com>, mpls@UU.NET, rsvp@isi.edu,
        swallow@cisco.com
Subject: Re: [Rsvp] Re: help 
In-reply-to: Your message of "Tue, 04 Mar 2003 10:00:12 PST."
             <Pine.LNX.4.44.0303040956310.14121-100000@fig.isi.edu> 
Date: Tue, 04 Mar 2003 14:34:00 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Steven -

I believe that 2207 deals with getting reservations for IPSEC flows.
The subject of this thread is using IPSEC to secure RSVP protocol
exchanges.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824



From owner-mpls@UU.NET  Tue Mar  4 15:30:19 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09339
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 15:30:19 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepm18915
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 20:32:18 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoepm18332;
	Tue, 4 Mar 2003 20:32:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoepj20689
	for mpls-outgoing; Tue, 4 Mar 2003 19:49:57 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoepj20661
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 19:49:43 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoepj24677
	for <mpls@uu.net>; Tue, 4 Mar 2003 19:49:11 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepj19594
	for <mpls@uu.net>; Tue, 4 Mar 2003 19:49:10 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoepj19578
	for <mpls@uu.net>; Tue, 4 Mar 2003 19:49:10 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h24Jn3Nh017500
	for <mpls@uu.net>; Tue, 4 Mar 2003 14:49:04 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA26031 for <mpls@uu.net>; Tue, 4 Mar 2003 14:49:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h24Jn3727442 for mpls@uu.net; Tue, 4 Mar 2003 14:49:03 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoepj20556
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 19:47:26 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoepj20442
	for <mpls@UU.NET>; Tue, 4 Mar 2003 19:47:04 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepj16296
	for <mpls@UU.NET>; Tue, 4 Mar 2003 19:47:03 GMT
Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoepj16223
	for <mpls@UU.NET>; Tue, 4 Mar 2003 19:47:01 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA01461;
	Tue, 4 Mar 2003 14:44:52 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303041944.OAA01461@workhorse.fictitious.org>
To: Stephen Trowbridge <sjtrowbridge@lucent.com>
cc: curtis@fictitious.org, Yangguang Xu <xuyg@lucent.com>,
        Kireeti Kompella <kireeti@juniper.net>,
        Zhi-Wei Lin <zwlin@comcast.net>, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: billing & call management (was Re: a propos of nothing at all) 
In-reply-to: Your message of "Tue, 04 Mar 2003 12:13:42 MST."
             <3E64FAE6.AC5BC96@lucent.com> 
Date: Tue, 04 Mar 2003 14:44:52 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <3E64FAE6.AC5BC96@lucent.com>, Stephen Trowbridge writes:
> Curtis,
> OK, so it is your place to tell SPs how to bill for their services rather
> than mine.

No.  It is the SPs business to tell us.  

> No doubt that there are certain services at certain usage levels where it
> is better for the SP and for the customer to bill at a flat rate. All I am
> saying is that this is not necessarily the correct model in all cases.
> Sure, I can pay a flat rate for ulimited long distance calling if I choose
> to, but this flat rate is about 10x my normal long distance bill - so I
> choose to pay per call instead. But if I follow your model, I can expect
> what I pay for very few long distance calls to increase dramatically in
> the near future, since nobody will be able to measure my usage for VoIP
> and their only choice will be to charge me the amount that covers average
> usage.

No SPs seem to be making credible requests for customer initiated MPLS
connections which are per bandwidth billable.

> I pay a flat rate (~$45/mo with taxes) for my cable modem service. This is
> a bargain since we have 4 computers (2 tech. industry professionals, 1 CS
> major college student, one high school student) behind my router and we
> make pretty heavy use of it. But would you blame a SP for wanting to provide 
> a
> metered service also to try to get more cable modem penetration among light
> users?

But they don't and they don't intend to.  AOL could also go back to
metered billing.  So could the cell phone providers.  Customers
disappear, so they don't meter.

> Again, these are market related decisions to be made by the SPs. Not
> technology related decisions to be made by the equipment designers.
> Regards,
> Steve

The discussion was about requirements and I am speaking on the basis
of my experience on the SP side and what requirements I have heard on
the vendor side and observations about very clear industry trends
(toward not away from flat rate billing).

Nice tactic though.  After you lose the argument, declare the argument
out of scope.  :-)

Curtis


> Curtis Villamizar wrote:
> > 
> > In message <3E64EAA2.FDD36434@lucent.com>, Stephen Trowbridge writes:
> > > Curtis,
> > > Working for an equipment manufacturer, I have never felt that it was
> > > my place to tell a SP how they should bill for their services. I don't
> > > think we should preclude any particular billing model by our architecture
> .
> > > It is the market that should decide what gets offered at a flat rate:
> > > not the equipment, and certainly not the standards.
> > > Steve
> > 
> > Steve,
> > 
> > This is no different from the 1995 argument that IP should go away
> > becasue there is no good way to bill on a per connection basis.
> > 
> > What you are asking for is customer initiated connections which can be
> > metered for billing purposes.
> > 
> > I used to work at two major ISPs in the architecture group.  There was
> > no such requirement.  Since leaving and being on the vendor side I
> > have not heard any such requirement from customers.
> > 
> > Well actually if you count Enron as a customer, Enron's bandwidth
> > brokering required customer initiated connections with AAA and
> > possibly metering.  They hadn't decided on the latter before they gave
> > up and switched their business plan to a QoS enabled backbone for VOD
> > (remember the Enron/Blockbuster announcement).  We all know how far
> > both of those ideas went.
> > 
> > It appears that you are not arguing that any SP wishes to repeat
> > Enron's folly (the first of the two), just that we should extend the
> > protocols to accommodate it just in case.  That doesn't sound like a
> > strong case for a set of requirements.
> > 
> > Curtis
> > 
> > > Curtis Villamizar wrote:
> > > >
> > > > In message <3E64A690.D3BB8603@lucent.com>, Yangguang Xu writes:
> > > > >
> > > > >
> > > > > Kireeti,
> > > > >
> > > > > Yea, you are right. You pay flat rate for a DSL.  [...]
> > > >
> > > > Lets look up and down the food chain.
> > > >
> > > >   At consumer level, service is tiered flat rate.  DSL, cable IP, cell
> > > >   phone, now POTS.
> > > >
> > > >   IP service at T1 or higher has always been flat rate or burstable
> > > >   tiered flat rate.
> > > >
> > > >   Switched services such as FR and ATM have been flat rate PVC or
> > > >   SPVC.  SVC service is generally not available and where it is has
> > > >   almost negligible penetration.
> > > >
> > > >   At the high end, leased lines, leased lambdas, and leased dark fiber
> > > >   is definitely not signaled dynamicly by the customer so there is not
> > > >   "call" or customer connection.
> > > >
> > > > What has had a call model:
> > > >
> > > >   X.25
> > > >
> > > >   ISDN
> > > >
> > > > Even ISDN, where it has been at all successful, is flat rate.  Where
> > > > it is metered, market penetration is zip.  (btw - Its still metered
> > > > where I live afaik and might as well not be offered).
> > > >
> > > > > Furthermore, you are talking about billing. Indeed, one of the reason
> s op
> > > erto
> > > > > rs
> > > > > choose flat rate is to simplify billing because the control/managemen
> t pl
> > > ane
> > > > > can't generate accurate information.
> > > > >
> > > > > The bottom line is that as the building block of the overall manageme
> nt
> > > > > functions, control plane should provide adequate function to support 
> high
> > >  lev
> > > > > el
> > > > > services. Otherwise, everything becomes commodity.
> > > >
> > > > So what does this billing and control/management plane nonsense mean
> > > > in a world with flat rate or tiered service with no customer initiated
> > > > connections to bill for?  It has absolutely no purpose except to try
> > > > to perpetuate a mindset and perpetuate a hope that services with the
> > > > X.25 and ISDN metered billing model will somehow gain penetration and
> > > > the SP will be able to milk huge profits from it.  Unfortunately the
> > > > customer isn't stupid enough, so short of a return to monopoly rule or
> > > > other exclusion of competition, it won't happen.
> > > >
> > > > > Yangguang
> > > >
> > > > Curtis
> > >
> 



From owner-mpls@UU.NET  Tue Mar  4 16:04:19 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10426
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 16:04:19 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepo10036
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 21:06:21 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoepo09980;
	Tue, 4 Mar 2003 21:06:18 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoepm13150
	for mpls-outgoing; Tue, 4 Mar 2003 20:39:50 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoepm13143
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 20:39:49 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoepm19401
	for <mpls@uu.net>; Tue, 4 Mar 2003 20:39:14 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepm29297
	for <mpls@uu.net>; Tue, 4 Mar 2003 20:39:13 GMT
Received: from psg.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: psg.com [147.28.0.62])
	id QQoepm29281
	for <mpls@uu.net>; Tue, 4 Mar 2003 20:39:13 GMT
Received: from psg.com ([147.28.0.62] helo=127.0.0.1)
	by psg.com with esmtp (Exim 3.36 #1)
	id 18qJBr-000MRI-00; Tue, 04 Mar 2003 12:39:07 -0800
Date: Tue, 4 Mar 2003 12:38:49 -0800
From: Alex Zinin <zinin@psg.com>
X-Mailer: The Bat! (v1.62i) Personal
Reply-To: Alex Zinin <zinin@psg.com>
X-Priority: 3 (Normal)
Message-ID: <1661912490.20030304123849@psg.com>
To: Kireeti Kompella <kireeti@juniper.net>
CC: Stephen Trowbridge <sjtrowbridge@lucent.com>, ccamp@ops.ietf.org,
        "" <mpls@UU.NET>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
In-Reply-To: <20030303140750.W51425@kummer.juniper.net>
References: <200303031648.h23GmwJO003841@newdev.harvard.edu>
 <3E638C95.167731F8@lucent.com> <20030303140750.W51425@kummer.juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


<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 owner-mpls@UU.NET  Tue Mar  4 17:04:11 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11980
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 17:04:11 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeps00663
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 22:06:13 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeps00497;
	Tue, 4 Mar 2003 22:06:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoepq05772
	for mpls-outgoing; Tue, 4 Mar 2003 21:39:58 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoepq05767
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 21:39:52 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoepq16124
	for <mpls@UU.NET>; Tue, 4 Mar 2003 21:39:48 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepq19038
	for <mpls@UU.NET>; Tue, 4 Mar 2003 21:39:48 GMT
Received: from zcars0m9.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157])
	id QQoepq19032
	for <mpls@UU.NET>; Tue, 4 Mar 2003 21:39:48 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h24Ldaw13892
	for <mpls@UU.NET>; Tue, 4 Mar 2003 16:39:36 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <GDF4S6XH>; Tue, 4 Mar 2003 16:39:36 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D016D2AA7@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: mpls@UU.NET
Subject: Draft-allan-y1711-and-lsp-ping
Date: Tue, 4 Mar 2003 16:39:34 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2E296.8BF672D2"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2E296.8BF672D2
Content-Type: text/plain;
	charset="iso-8859-1"

FYI, this draft was posted last week but not announced. Gives an
informational overview of the strengths of both Y.1711 and LSP-PING.

http://www.ietf.org/internet-drafts/draft-allan-y1711-and-lsp-ping-00.txt

Cheers
Dave

------_=_NextPart_001_01C2E296.8BF672D2
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>Draft-allan-y1711-and-lsp-ping</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>FYI, this draft was posted last week but not =
announced. Gives an informational overview of the strengths of both =
Y.1711 and LSP-PING.</FONT></P>

<P><FONT SIZE=3D2><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-allan-y1711-and-lsp-pi=
ng-00.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-allan-y1711-=
and-lsp-ping-00.txt</A></FONT>
</P>

<P><FONT SIZE=3D2>Cheers</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2E296.8BF672D2--


From owner-mpls@UU.NET  Tue Mar  4 17:19:42 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12474
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 17:19:41 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoept19851
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 22:21:44 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoept19776;
	Tue, 4 Mar 2003 22:21:39 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoepr07063
	for mpls-outgoing; Tue, 4 Mar 2003 21:55:30 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoepr07051
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 21:55:18 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoepr28119
	for <mpls@UU.NET>; Tue, 4 Mar 2003 21:54:36 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepr19411
	for <mpls@UU.NET>; Tue, 4 Mar 2003 21:54:36 GMT
Received: from zcars04f.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57])
	id QQoepr19407
	for <mpls@UU.NET>; Tue, 4 Mar 2003 21:54:35 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h24LsPS00426;
	Tue, 4 Mar 2003 16:54:25 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <GDF4S7AW>; Tue, 4 Mar 2003 16:54:25 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D016D2AAB@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'Alex Zinin'" <zinin@psg.com>, Kireeti Kompella <kireeti@juniper.net>
Cc: Stephen Trowbridge <sjtrowbridge@lucent.com>, ccamp@ops.ietf.org,
        mpls@UU.NET
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Tue, 4 Mar 2003 16:54:24 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2E298.9EB6D004"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2E298.9EB6D004
Content-Type: text/plain;
	charset="iso-8859-1"

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.

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.

>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?




------_=_NextPart_001_01C2E298.9EB6D004
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Alex:</FONT>
</P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>I would assume I'm not the only one to note this =
inconsistency.</FONT>
</P>

<P><FONT SIZE=3D2>Cheers</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&lt;snipped&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Bingo!</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;It seems to me that this is the only way to =
ensure fairness in the IETF, actually. Once </FONT>
<BR><FONT SIZE=3D2>&gt;we start introducing any sorts of preferences or =
&quot;weights&quot;, it may become a too </FONT>
<BR><FONT SIZE=3D2>&gt;attractive backdoor around the IETF =
process.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Also, what does &quot;weight&quot; of a liaison =
or an ID really mean in a _consensus_ based </FONT>
<BR><FONT SIZE=3D2>&gt;organization? That we should suddenly have a =
worm and fuzzy feeling about that doc? And </FONT>
<BR><FONT SIZE=3D2>&gt;how does this &quot;weight&quot; compare to, for =
example, the weight of the consensus within the </FONT>
<BR><FONT SIZE=3D2>&gt;IETF to not do what's proposed, if that =
happens?</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C2E298.9EB6D004--


From owner-mpls@UU.NET  Tue Mar  4 17:40:11 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12984
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 17:40:11 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepu04305
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 22:42:13 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoepu04231;
	Tue, 4 Mar 2003 22:42:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoept26911
	for mpls-outgoing; Tue, 4 Mar 2003 22:15:50 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoept26897
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 22:15:49 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoept19087
	for <mpls@UU.NET>; Tue, 4 Mar 2003 22:15:12 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoept14723
	for <mpls@UU.NET>; Tue, 4 Mar 2003 22:15:10 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQoept14648
	for <mpls@UU.NET>; Tue, 4 Mar 2003 22:15:09 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA17085;
	Tue, 4 Mar 2003 17:14:57 -0500 (EST)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA10005;
	Tue, 4 Mar 2003 17:14:58 -0500 (EST)
Message-ID: <3E652583.8070402@marconi.com>
Date: Tue, 04 Mar 2003 17:15:31 -0500
From: David Charlap <David.Charlap@marconi.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210
X-Accept-Language: en-us, en, he
MIME-Version: 1.0
To: mpls@UU.NET, rsvp@ISI.EDU
Subject: Re: [Rsvp] Re: help
References: <2A8DB02E3018D411901B009027FD3A3F03675EB5@mchp905a.mch.sbs.de>
In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03675EB5@mchp905a.mch.sbs.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Tschofenig Hannes wrote:
> 
> may i summarize this issue:
> the problem is the combination of signaling message delivery and discovery. 
> (there is a relationship to the end-to-end addressing.)
> 
> using this combination is probably not the best idea since you have to know
> your next rsvp aware router to select your security association to protect
> it properly. 

Absolutely.  In a classical-RSVP environment, you can't know your 
immediate next-RSVP-neighbor.  Your route-table next hop may not be 
running RSVP - meaning he'll forward the packet and the first router to 
actually process it will be someone else.

> the rsvp-te signaling message is still addressed to the destination address
> (rather than to the next rsvp node) although it might contain a route
> object. hence you use a discovery although you do not really need it (you
> know that your next node is rsvp capable and you might even know the entire
> path.)

Under some circumstances (such as using the hierarchical LSP draft with 
unicast LSPs), it is legal to compute the next-hop address from the 
local route table and set the destination address to it.  If this is 
done, IPSEC would be possible.

RFC 2205 doesn't allow this sort of behavior for two main reasons. 
First, it breaks in the presence of non-RSVP routers along the path to 
the destination.  Second, it creates the possibility that the Path 
message doesn't follow the same path as the data flow it represents. 
(Different addresses may result in different ECMP computation results.)

RFC 3209 doesn't say anything for or against this behavior (although it 
does mandate that Hello messages be sent directly to the next-hop.)  It 
may be reasonable to not assume that this requirement has been inherited 
from RFC 2205, because the arguments are not applicable.  Concern for 
non-RSVP routers doesn't exist in RSVP-TE, and the data will always 
follow the Path message, using the LSP that it has established.

In GMPLS, the reasons become even weaker, since part of GMPLS's 
capabilities involve explicitly signaling Path messages along a path 
separate from where the data will go.

But even here, it is far from certain if this should be legal in the 
first place.  The only draft I've read that actually requires Path 
messages to be sent directly to a next-hop is the hierarchical LSP 
draft.  It is perfectly logical to assume that this is the only 
situation where it should be legal.

Personally, I think the existing INTEGRITY object mechanism provides 
security that is good enough for RSVP signaling.  Messages are 
authenticated, even if the data is not encrypted.  But I'm not a 
security expert here - there may be a good reason why you'd want to 
prohibit a packet sniffer from looking at the content of RSVP control 
plane traffic.

-- David



From owner-mpls@UU.NET  Tue Mar  4 18:13:19 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14786
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 18:13:19 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepx18158
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 23:15:22 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoepx18006;
	Tue, 4 Mar 2003 23:15:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoepv29648
	for mpls-outgoing; Tue, 4 Mar 2003 22:48:51 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoepv29641
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 22:48:45 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoepv15460
	for <mpls@UU.NET>; Tue, 4 Mar 2003 22:48:04 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepv10079
	for <mpls@UU.NET>; Tue, 4 Mar 2003 22:48:03 GMT
Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQoepv10019
	for <mpls@UU.NET>; Tue, 4 Mar 2003 22:48:01 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h24Mm0S02408;
	Tue, 4 Mar 2003 14:48:01 -0800 (PST)
	(envelope-from kireeti@juniper.net)
Received: from localhost (kireeti@localhost)
	by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h24Mm0h57116;
	Tue, 4 Mar 2003 14:48:00 -0800 (PST)
	(envelope-from kireeti@juniper.net)
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
Date: Tue, 4 Mar 2003 14:48:00 -0800 (PST)
From: Kireeti Kompella <kireeti@juniper.net>
To: David Allan <dallan@nortelnetworks.com>
cc: ccamp@ops.ietf.org, "" <mpls@UU.NET>
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
In-Reply-To: <FFFC48AEAA5F7447929F4F0D93FCC12D016D2AAB@zcard031.ca.nortel.com>
Message-ID: <20030304143001.B57000@kummer.juniper.net>
References: <FFFC48AEAA5F7447929F4F0D93FCC12D016D2AAB@zcard031.ca.nortel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Dave,

On Tue, 4 Mar 2003, David Allan wrote:

> You are offering a compelling argument to eliminate crediting of any authors
> on I-Ds etc.

Entirely orthogonal.  Every ID is given weight 1, independent of where
it came from, who the authors are or even how many authors there are.
If the ID came from a design team chosen by the WG chairs, by the ADs,
even by the IETF chair himself, the weight is still 1.

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

If there are too many authors, they become contributors.  Simple.
No fuss, no mess, no struggle.  The main reason (I believe) is to
scale the RFC Editor process.

(To repeat, this is completely unrelated to the argument at hand,
viz., should liaisons and IDs from other SDOs have more weight than
individual submissions.)

> I would assume I'm not the only one to note this inconsistency.

You're the only one (so far) to see this as an inconsistency.  But
I'd rather not go down this (rathole) until we have settled more
important issues.

Kireeti.


From owner-mpls@UU.NET  Tue Mar  4 18:33:55 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15321
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 18:33:55 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepy13106
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 23:35:57 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoepy12876;
	Tue, 4 Mar 2003 23:35:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoepw18642
	for mpls-outgoing; Tue, 4 Mar 2003 23:08:31 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoepw18440
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 23:08:14 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoepw03542
	for <mpls@uu.net>; Tue, 4 Mar 2003 23:08:06 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepw07290
	for <mpls@uu.net>; Tue, 4 Mar 2003 23:08:05 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoepw07272
	for <mpls@uu.net>; Tue, 4 Mar 2003 23:08:04 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h24N82JR004574
	for <mpls@uu.net>; Tue, 4 Mar 2003 18:08:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA11868 for <mpls@uu.net>; Tue, 4 Mar 2003 18:08:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h24N81f16976 for mpls@uu.net; Tue, 4 Mar 2003 18:08:01 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoepw18024
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 23:05:59 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoepw28983
	for <mpls@UU.NET>; Tue, 4 Mar 2003 23:05:53 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepw03181
	for <mpls@UU.NET>; Tue, 4 Mar 2003 23:05:52 GMT
Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoepw03149
	for <mpls@UU.NET>; Tue, 4 Mar 2003 23:05:51 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id RAA05105;
	Tue, 4 Mar 2003 17:55:21 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303042255.RAA05105@workhorse.fictitious.org>
To: "David Allan" <dallan@nortelnetworks.com>
cc: "'Alex Zinin'" <zinin@psg.com>, Kireeti Kompella <kireeti@juniper.net>,
        Stephen Trowbridge <sjtrowbridge@lucent.com>, ccamp@ops.ietf.org,
        mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
In-reply-to: Your message of "Tue, 04 Mar 2003 16:54:24 EST."
             <FFFC48AEAA5F7447929F4F0D93FCC12D016D2AAB@zcard031.ca.nortel.com> 
Date: Tue, 04 Mar 2003 17:55:21 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <FFFC48AEAA5F7447929F4F0D93FCC12D016D2AAB@zcard031.ca.nortel.com>, "
David Allan" writes:
> 
> 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.

The author list was never supposed to be a factor in evaluating an i-d
so its just an indication that the authors don't get it.  Particularly
when it becomes obvious that some of the "authors" have never read the
draft.

> I would assume I'm not the only one to note this inconsistency.

I wouldn't call it an inconsistency.  Just a reflection that the real
authors did not understand that the process didn't consider the author
list to be a factor in evaluation.

> Cheers
> Dave

Curtis



From owner-mpls@UU.NET  Tue Mar  4 18:56:12 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15963
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 18:56:12 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepz18975
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 23:58:15 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoepz18850;
	Tue, 4 Mar 2003 23:58:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoepy21208
	for mpls-outgoing; Tue, 4 Mar 2003 23:32:12 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoepy21201
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 23:32:02 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoepy23912
	for <mpls@uu.net>; Tue, 4 Mar 2003 23:30:12 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepy17788
	for <mpls@uu.net>; Tue, 4 Mar 2003 23:30:12 GMT
Received: from psg.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: psg.com [147.28.0.62])
	id QQoepy17767
	for <mpls@uu.net>; Tue, 4 Mar 2003 23:30:11 GMT
Received: from psg.com ([147.28.0.62] helo=127.0.0.1)
	by psg.com with esmtp (Exim 3.36 #1)
	id 18qLnn-0005so-00; Tue, 04 Mar 2003 15:26:27 -0800
Date: Tue, 4 Mar 2003 15:26:15 -0800
From: Alex Zinin <zinin@psg.com>
X-Mailer: The Bat! (v1.62i) Personal
Reply-To: Alex Zinin <zinin@psg.com>
X-Priority: 3 (Normal)
Message-ID: <5811958585.20030304152615@psg.com>
To: "David Allan" <dallan@nortelnetworks.com>
CC: Kireeti Kompella <kireeti@juniper.net>,
        Stephen Trowbridge <sjtrowbridge@lucent.com>, <ccamp@ops.ietf.org>,
        <mpls@UU.NET>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
In-Reply-To: <FFFC48AEAA5F7447929F4F0D93FCC12D016D2AAB@zcard031.ca.nortel.com>
References: <FFFC48AEAA5F7447929F4F0D93FCC12D016D2AAB@zcard031.ca.nortel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

David,

  What Kireeti and Curtis said, and to make things worse, I for one
  review the documents that try to make their front page more
  convincing than their substance with additional scrutiny...

-- 
Alex

Tuesday, March 4, 2003, 1:54:24 PM, David Allan wrote:
> 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.

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

>>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?



From owner-mpls@UU.NET  Tue Mar  4 19:50:22 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17297
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 19:50:22 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeqd00483
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 00:52:24 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeqd00375;
	Wed, 5 Mar 2003 00:52:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeqb12864
	for mpls-outgoing; Wed, 5 Mar 2003 00:21:11 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoeqb12859
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 00:21:09 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoeqb12917
	for <mpls@uu.net>; Wed, 5 Mar 2003 00:20:42 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeqb00879
	for <mpls@uu.net>; Wed, 5 Mar 2003 00:20:41 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoeqb00874
	for <mpls@uu.net>; Wed, 5 Mar 2003 00:20:41 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h250KcNh008099
	for <mpls@uu.net>; Tue, 4 Mar 2003 19:20:39 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA16094 for <mpls@uu.net>; Tue, 4 Mar 2003 19:20:38 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h250Kc923342 for mpls@uu.net; Tue, 4 Mar 2003 19:20:38 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoepg01674
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 19:01:01 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoepg29264
	for <mpls@UU.NET>; Tue, 4 Mar 2003 19:00:46 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoepg10616
	for <mpls@UU.NET>; Tue, 4 Mar 2003 19:00:45 GMT
Received: from david.siemens.de by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: david.siemens.de [192.35.17.14])
	id QQoepg10579
	for <mpls@UU.NET>; Tue, 4 Mar 2003 19:00:44 GMT
Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14])
	by david.siemens.de (8.11.6/8.11.6) with ESMTP id h24J0fb23200;
	Tue, 4 Mar 2003 20:00:41 +0100 (MET)
Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99])
	by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id h24J0fr22763;
	Tue, 4 Mar 2003 20:00:41 +0100 (MET)
Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19)
	id <FMHXS36J>; Tue, 4 Mar 2003 20:00:40 +0100
Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675EB5@mchp905a.mch.sbs.de>
From: Tschofenig Hannes <Hannes.Tschofenig@mchp.siemens.de>
To: "'David Charlap'" <David.Charlap@marconi.com>, mpls@UU.NET, rsvp@ISI.EDU
Subject: RE: [Rsvp] Re: help
Date: Tue, 4 Mar 2003 20:00:40 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

hi all, 

thanks for raising this issue.  please see my comments below:

> Harish Kumtakar wrote:
> > 
> >      Why IPSEC can not be used in RSVP to care of security. 
> Please throw 
> > some light on this aspect.
> 
> The reason it isn't in classical RSVP is because IPSEC secures two 
> endpoints.  But the nature of RSVP is such that packets are 
> supposed to 
> be intercepted and processed by transit routers.
> 
> An RSVP router does not send a Path message to his neighbor.  
> He sends 
> it to the ultimate destination address, with the router-alert 
> option, so 
> that RSVP-aware routers along the way may intercept and process the 
> packet.  This is fundamentally incompatible with IPSEC - where the 
> packet is encrypted such that transit routers can not 
> intercept anything.

may i summarize this issue:
the problem is the combination of signaling message delivery and discovery. 
(there is a relationship to the end-to-end addressing.)

using this combination is probably not the best idea since you have to know
your next rsvp aware router to select your security association to protect
it properly. 

> 
> If you want to use IPSEC with RSVP, then you must send 
> packets directly 
> to neighbors and abandon the use of router-alert.  This isn't 
> a problem 
> for RSVP-TE, since the presence of non-RSVP routers isn't 
> permitted in 
> an MPLS/RSVP-TE network.

i guess that there are more issues:

the rsvp-te signaling message is still addressed to the destination address
(rather than to the next rsvp node) although it might contain a route
object. hence you use a discovery although you do not really need it (you
know that your next node is rsvp capable and you might even know the entire
path.)

protecting a rsvp-te can only be done in ipsec tunnel mode. ipsec tunnel
mode modifies the routing of the signaling message. to protect an rsvp
signaling message (with ipsec) requires that you have have an spd entry
which says which traffic is going to be protected. if you have more than one
possible path (two possible neighboring routers) then you have two make your
spd entry accordingly. which is difficult since the source address and the
destination address is not the address of the nodes where the protected rsvp
message should travel. if you manage it to create this ipsec sa then you
need to change it once a route change happens to reflect the new path. 


  But it eliminates the ability for classical 
> RSVP to work over networks with non-RSVP nodes - something 
> that is a key 
> goal of the RSVP protocol.

for ipsec handling there are more difficulties.
the fact that you do not necessarily know your next rsvp capable router is a
bad thing (especially in case of non-rsvp cloudes/nodes or for applications
such as middlebox communication where nodes are sparsely distributed. 

> 
> IPSEC also makes multicast much more CPU intensive.  If every 
> packet is 
> encrypted, then you can't simply generate one Path message for 
> transmission to all downstream nodes in a multicast group.  
> You have to 
> generate multiple separate packets and encrypt them individually.

my 5-cents on the multicast handling. 
since the path message is addressed to the destination ip address (which is
a multicast address in this case) you have to use multicast security for
message security. if you sparate signaling message delivery from discovery i
guess that you could address individual rsvp nodes directly. 

btw, you might want to take a look at section 5 of 
http://www.tschofenig.com/drafts/draft-ietf-nsis-rsvp-sec-properties-01.txt.
i would highly appreciate your comments. 

ciao
hannes



> 
> -- David
> 
> _______________________________________________
> Rsvp mailing list
> Rsvp@mailman.isi.edu
> http://mailman.isi.edu/mailman/listinfo/rsvp
> 



From owner-mpls@UU.NET  Tue Mar  4 19:51:20 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17344
	for <mpls-archive@lists.ietf.org>; Tue, 4 Mar 2003 19:51:19 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeqd24407
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 00:53:21 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeqd24347;
	Wed, 5 Mar 2003 00:53:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeqb12902
	for mpls-outgoing; Wed, 5 Mar 2003 00:22:32 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoeqb12895
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 00:22:26 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoeqb15984
	for <mpls@uu.net>; Wed, 5 Mar 2003 00:21:47 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeqb02352
	for <mpls@uu.net>; Wed, 5 Mar 2003 00:21:47 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoeqb02337
	for <mpls@uu.net>; Wed, 5 Mar 2003 00:21:46 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h250LhNh008187
	for <mpls@uu.net>; Tue, 4 Mar 2003 19:21:44 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA16156 for <mpls@uu.net>; Tue, 4 Mar 2003 19:21:43 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h250Lhj23402 for mpls@uu.net; Tue, 4 Mar 2003 19:21:43 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoept27480
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Mar 2003 22:23:03 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoept27857
	for <mpls@UU.NET>; Tue, 4 Mar 2003 22:22:00 GMT
From: Mark.Jones@mail.sprint.com
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoept20144
	for <mpls@UU.NET>; Tue, 4 Mar 2003 22:22:00 GMT
Received: from kcmgwp01.corp.sprint.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: parker1.sprint.com [208.18.122.165])
	id QQoept20136
	for <mpls@UU.NET>; Tue, 4 Mar 2003 22:21:59 GMT
Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93])
	by kcmgwp01.corp.sprint.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id h24MLsF18220;
	Tue, 4 Mar 2003 16:21:54 -0600 (CST)
Received: from kcopmp04.corp.sprint.com (kcopmp04m [10.79.2.196])
	by kcmgwp02.corp.sprint.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id h24MLrH11050;
	Tue, 4 Mar 2003 16:21:53 -0600 (CST)
Received: from localhost (root@localhost)
	by kcopmp04.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id QAA00329;
	Tue, 4 Mar 2003 16:21:52 -0600 (CST)
X-OpenMail-Hops: 1
Date: Tue, 4 Mar 2003 16:21:52 -0600
Message-Id: <H00017a81fcc548d.1046816511.kcopmp04@MHS>
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
MIME-Version: 1.0
TO: kireeti@juniper.net, zinin@psg.com
CC: ccamp@ops.ietf.org, mpls@UU.NET, sjtrowbridge@lucent.com
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline; filename="BDY.TXT"
	;Creation-Date="Tue, 4 Mar 2003 16:21:52 -0600"
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

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:zinin@psg.com]
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 owner-mpls@UU.NET  Wed Mar  5 06:59:53 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27895
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 06:59:53 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoerw12326
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 12:01:57 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoerw12259;
	Wed, 5 Mar 2003 12:01:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeru17427
	for mpls-outgoing; Wed, 5 Mar 2003 11:36:34 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoeru17422
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 11:36:23 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoeru10641
	for <mpls@uu.net>; Wed, 5 Mar 2003 11:36:09 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeru04929
	for <mpls@uu.net>; Wed, 5 Mar 2003 11:36:09 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoeru04821
	for <mpls@uu.net>; Wed, 5 Mar 2003 11:36:07 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h25Ba4Nh007848
	for <mpls@uu.net>; Wed, 5 Mar 2003 06:36:04 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA16836 for <mpls@uu.net>; Wed, 5 Mar 2003 06:36:04 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h25Ba4Z00579 for mpls@uu.net; Wed, 5 Mar 2003 06:36:04 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoeru17196
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 11:34:32 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoeru02145
	for <mpls@uu.net>; Wed, 5 Mar 2003 11:34:19 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeru28072
	for <mpls@uu.net>; Wed, 5 Mar 2003 11:34:18 GMT
Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQoeru28068
	for <mpls@uu.net>; Wed, 5 Mar 2003 11:34:18 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26544;
	Wed, 5 Mar 2003 06:32:13 -0500 (EST)
Message-Id: <200303051132.GAA26544@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-mgmt-overview-03.txt
Date: Wed, 05 Mar 2003 06:32:13 -0500
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title		: Multiprotocol Label Switching (MPLS) Management 
                          Overview
	Author(s)	: T. Nadeau, C. Srinivasan, A. Farrel
	Filename	: draft-ietf-mpls-mgmt-overview-03.txt
	Pages		: 29
	Date		: 2003-3-4
	
A range of management Information Bases (MIBs) has been
developed to help model and manage the various aspects of
Multiprotocol Label Switching (MPLS) networks.  These MIBs
are defined in separate drafts and RFCs that focus on the
specific areas of responsibility of their MIBs.
This memo describes the management architecture for MPLS
and indicates the inter-relationships between the different
MIBs used for MPLS network management.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-mgmt-overview-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-mgmt-overview-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-mgmt-overview-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-3-4174437.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-mgmt-overview-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-mgmt-overview-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-3-4174437.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Wed Mar  5 10:45:13 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06986
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 10:45:13 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoesl12944
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 15:47:11 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoesl12885;
	Wed, 5 Mar 2003 15:47:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoesj13239
	for mpls-outgoing; Wed, 5 Mar 2003 15:21:28 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoesj13234
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 15:21:20 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoesj23403
	for <mpls@uu.net>; Wed, 5 Mar 2003 15:21:07 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoesj10129
	for <mpls@uu.net>; Wed, 5 Mar 2003 15:21:06 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoesj10120
	for <mpls@uu.net>; Wed, 5 Mar 2003 15:21:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h25FL3JR003028
	for <mpls@uu.net>; Wed, 5 Mar 2003 10:21:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA29310 for <mpls@uu.net>; Wed, 5 Mar 2003 10:21:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h25FL2e13647 for mpls@uu.net; Wed, 5 Mar 2003 10:21:02 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoesj13177
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 15:18:58 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoesj26199
	for <mpls@UU.NET>; Wed, 5 Mar 2003 15:18:32 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoesj07558
	for <mpls@UU.NET>; Wed, 5 Mar 2003 15:18:31 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoesj07545
	for <mpls@UU.NET>; Wed, 5 Mar 2003 15:18:31 GMT
Received: from bucket.cisco.com (IDENT:mirapoint@bucket.cisco.com [161.44.167.72])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h25FBcNh020360;
	Wed, 5 Mar 2003 10:11:39 -0500 (EST)
Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-1-65.cisco.com [10.86.240.65])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ACR56281;
	Wed, 5 Mar 2003 10:11:37 -0500 (EST)
Message-Id: <5.2.0.9.2.20030305100939.02ba6530@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 05 Mar 2003 10:11:25 -0500
To: "David Allan" <dallan@nortelnetworks.com>, "'Alex Zinin'" <zinin@psg.com>,
        Kireeti Kompella <kireeti@juniper.net>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Cc: Stephen Trowbridge <sjtrowbridge@lucent.com>, ccamp@ops.ietf.org,
        mpls@UU.NET
In-Reply-To: <FFFC48AEAA5F7447929F4F0D93FCC12D016D2AAB@zcard031.ca.norte
 l.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


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




From owner-mpls@UU.NET  Wed Mar  5 13:18:28 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19042
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 13:18:28 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoesv15754
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 18:20:32 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoesv15674;
	Wed, 5 Mar 2003 18:20:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoest29687
	for mpls-outgoing; Wed, 5 Mar 2003 17:55:22 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoest29677
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 17:55:17 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoest17468
	for <mpls@UU.NET>; Wed, 5 Mar 2003 17:54:30 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoest17189
	for <mpls@UU.NET>; Wed, 5 Mar 2003 17:54:29 GMT
Received: from atlntex01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: exchange.movaz.com [65.205.166.141])
	id QQoest17171
	for <mpls@UU.NET>; Wed, 5 Mar 2003 17:54:29 GMT
Received: from BLIULAPTOP ([172.16.24.104]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Wed, 5 Mar 2003 12:54:28 -0500
Message-ID: <00d701c2e340$4439dc90$681810ac@movaz.com>
From: "Adrian Farrel" <afarrel@movaz.com>
To: <mpls@UU.NET>
References: <200303051132.GAA26544@ietf.org>
Subject: Re: I-D ACTION:draft-ietf-mpls-mgmt-overview-03.txt
Date: Wed, 5 Mar 2003 12:54:26 -0500
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-OriginalArrivalTime: 05 Mar 2003 17:54:28.0821 (UTC) FILETIME=[449AE850:01C2E340]
Sender: owner-mpls@UU.NET
Precedence: bulk

All,

This version of the draft includes (intends to include) all changes as a result
of the MPLS MIB Meeting held before the last IETF gathering in Atlanta with two
exceptions:

1. The document has not been updated to reflect changes to
    the MPLS MIBs as a result of the meeting since it seems
    reasonable to wait for those updates to be published and
    progress to last call.

2. Contributory text was requested from the author of the
    TEWG TE MIB on how it may be used for MPLS TE
    and how it links to the other MIBs. This text has not
    been forthcoming, so the authors of this draft have made
    a best effort attempt.

As usual, all comments are very welcome on or off the list.
In particular, I am interested in the views of people trying to understand how
to use the MIBs and how they fit together.

Thanks,
Adrian
----- Original Message -----
From: <Internet-Drafts@ietf.org>
To: <IETF-Announce: ;>
Cc: <mpls@UU.NET>
Sent: Wednesday, March 05, 2003 6:32 AM
Subject: I-D ACTION:draft-ietf-mpls-mgmt-overview-03.txt


> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Multiprotocol Label Switching Working Group
of the IETF.
>
> Title : Multiprotocol Label Switching (MPLS) Management
>                           Overview
> Author(s) : T. Nadeau, C. Srinivasan, A. Farrel
> Filename : draft-ietf-mpls-mgmt-overview-03.txt
> Pages : 29
> Date : 2003-3-4
>
> A range of management Information Bases (MIBs) has been
> developed to help model and manage the various aspects of
> Multiprotocol Label Switching (MPLS) networks.  These MIBs
> are defined in separate drafts and RFCs that focus on the
> specific areas of responsibility of their MIBs.
> This memo describes the management architecture for MPLS
> and indicates the inter-relationships between the different
> MIBs used for MPLS network management.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-mgmt-overview-03.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-ietf-mpls-mgmt-overview-03.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> mailserv@ietf.org.
> In the body type:
> "FILE /internet-drafts/draft-ietf-mpls-mgmt-overview-03.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>




From owner-mpls@UU.NET  Wed Mar  5 14:46:54 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24879
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 14:46:54 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetb27258
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 19:48:52 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoetb27179;
	Wed, 5 Mar 2003 19:48:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoesz11676
	for mpls-outgoing; Wed, 5 Mar 2003 19:15:22 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoesz11671
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 19:15:08 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoesy09433
	for <mpls@uu.net>; Wed, 5 Mar 2003 19:14:07 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoesy26900
	for <mpls@uu.net>; Wed, 5 Mar 2003 19:14:06 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoesy26882
	for <mpls@uu.net>; Wed, 5 Mar 2003 19:14:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h25JE2JR024195
	for <mpls@uu.net>; Wed, 5 Mar 2003 14:14:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA21795 for <mpls@uu.net>; Wed, 5 Mar 2003 14:14:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h25JE2s28829 for mpls@uu.net; Wed, 5 Mar 2003 14:14:02 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoesy11398
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 19:13:15 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoesy08112
	for <mpls@UU.NET>; Wed, 5 Mar 2003 19:12:30 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoesy15234
	for <mpls@UU.NET>; Wed, 5 Mar 2003 19:12:30 GMT
Received: from mother.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12])
	id QQoesy15213
	for <mpls@UU.NET>; Wed, 5 Mar 2003 19:12:29 GMT
Received: (qmail 17201 invoked by uid 104); 5 Mar 2003 19:12:18 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4250.  Clear:. 
 Processed in 0.4651 secs); 05 Mar 2003 19:12:18 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by mother.pmc-sierra.bc.ca with SMTP; 5 Mar 2003 19:12:17 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h25JCDh25671;
	Wed, 5 Mar 2003 11:12:17 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <DCP4H10F>; Wed, 5 Mar 2003 11:12:13 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03D60@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Mark.Jones@mail.sprint.com'" <Mark.Jones@mail.sprint.com>
Cc: ccamp@ops.ietf.org, mpls@UU.NET
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Wed, 5 Mar 2003 11:12:10 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

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

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



From owner-mpls@UU.NET  Wed Mar  5 15:39:15 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27508
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 15:39:14 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoete22992
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 20:41:17 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoete22911;
	Wed, 5 Mar 2003 20:41:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeta13156
	for mpls-outgoing; Wed, 5 Mar 2003 19:33:02 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoeta13139
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 19:32:47 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoeta03495
	for <mpls@uu.net>; Wed, 5 Mar 2003 19:32:28 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeta26435
	for <mpls@uu.net>; Wed, 5 Mar 2003 19:32:27 GMT
Received: from psg.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: psg.com [147.28.0.62])
	id QQoeta26422
	for <mpls@uu.net>; Wed, 5 Mar 2003 19:32:27 GMT
Received: from psg.com ([147.28.0.62] helo=127.0.0.1)
	by psg.com with esmtp (Exim 3.36 #1)
	id 18qecl-0007kU-00; Wed, 05 Mar 2003 11:32:19 -0800
Date: Wed, 5 Mar 2003 11:31:26 -0800
From: Alex Zinin <zinin@psg.com>
X-Mailer: The Bat! (v1.62i) Personal
Reply-To: Alex Zinin <zinin@psg.com>
X-Priority: 3 (Normal)
Message-ID: <11057338428.20030305113126@psg.com>
To: Jonathan Sadler <jonathan.sadler@tellabs.com>
CC: Kireeti Kompella <kireeti@juniper.net>,
        Stephen Trowbridge <sjtrowbridge@lucent.com>, <ccamp@ops.ietf.org>,
        <mpls@UU.NET>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
In-Reply-To: <3E663A99.438409C2@tellabs.com>
References: <H0000c080672abb9.1046813316.mailw02@MHS>
 <3E663A99.438409C2@tellabs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

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:

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

> ============================================================
> 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 owner-mpls@UU.NET  Wed Mar  5 15:42:38 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27598
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 15:42:38 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoete12269
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 20:44:40 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoete10263;
	Wed, 5 Mar 2003 20:43:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeta13237
	for mpls-outgoing; Wed, 5 Mar 2003 19:34:22 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoeta13229
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 19:34:12 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoeta22231
	for <mpls@uu.net>; Wed, 5 Mar 2003 19:34:07 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeta28958
	for <mpls@uu.net>; Wed, 5 Mar 2003 19:34:07 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoeta28942
	for <mpls@uu.net>; Wed, 5 Mar 2003 19:34:06 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h25JY4JR026899
	for <mpls@uu.net>; Wed, 5 Mar 2003 14:34:04 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA23622 for <mpls@uu.net>; Wed, 5 Mar 2003 14:34:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h25JY3q01746 for mpls@uu.net; Wed, 5 Mar 2003 14:34:03 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoeta13137
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 19:32:47 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoeta14883
	for <mpls@uu.net>; Wed, 5 Mar 2003 19:32:31 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeta17161
	for <mpls@uu.net>; Wed, 5 Mar 2003 19:32:30 GMT
Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQoeta17149
	for <mpls@uu.net>; Wed, 5 Mar 2003 19:32:30 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23796;
	Wed, 5 Mar 2003 14:30:26 -0500 (EST)
Message-Id: <200303051930.OAA23796@ietf.org>
To: IETF-Announce:;
Cc: mpls@UU.NET
From: The IESG <iesg-secretary@ietf.org>
SUBJECT: Last Call: Fast Reroute Extensions to RSVP-TE for LSP Tunnels 
	   to Proposed Standard
Reply-to: iesg@ietf.org
Date: Wed, 05 Mar 2003 14:30:26 -0500
Sender: owner-mpls@UU.NET
Precedence: bulk


The IESG has received a request from the Multiprotocol Label Switching 
Working Group to consider Fast Reroute Extensions to RSVP-TE for LSP 
Tunnels <draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt> as a Proposed 
Standard.  

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the 
iesg@ietf.org or ietf@ietf.org mailing lists by 2003-3-25.

Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt





From owner-mpls@UU.NET  Wed Mar  5 15:54:34 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27848
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 15:54:34 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetf19650
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 20:56:37 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoetf19517;
	Wed, 5 Mar 2003 20:56:33 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeta13628
	for mpls-outgoing; Wed, 5 Mar 2003 19:39:40 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoeta13599
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 19:39:23 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoeta22479
	for <mpls@uu.net>; Wed, 5 Mar 2003 19:38:44 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeta24401
	for <mpls@uu.net>; Wed, 5 Mar 2003 19:38:43 GMT
Received: from psg.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: psg.com [147.28.0.62])
	id QQoeta24385
	for <mpls@uu.net>; Wed, 5 Mar 2003 19:38:42 GMT
Received: from psg.com ([147.28.0.62] helo=127.0.0.1)
	by psg.com with esmtp (Exim 3.36 #1)
	id 18qeil-0008Il-00; Wed, 05 Mar 2003 11:38:31 -0800
Date: Wed, 5 Mar 2003 11:37:34 -0800
From: Alex Zinin <zinin@psg.com>
X-Mailer: The Bat! (v1.62i) Personal
Reply-To: Alex Zinin <zinin@psg.com>
X-Priority: 3 (Normal)
Message-ID: <18057706577.20030305113734@psg.com>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
CC: "'Mark.Jones@mail.sprint.com'" <Mark.Jones@mail.sprint.com>,
        ccamp@ops.ietf.org, <mpls@UU.NET>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03D60@nt-exch-yow.pmc-sierra.bc.ca>
References: 
 <4B6D09F3B826D411A67300D0B706EFDEB03D60@nt-exch-yow.pmc-sierra.bc.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Wednesday, March 5, 2003, 11:12:10 AM, Shahram Davari wrote:
[...]
> 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.

Ouch... draft-iesg-vendor-extensions-00.txt

Alex



From owner-mpls@UU.NET  Wed Mar  5 16:05:52 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28658
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 16:05:52 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetg06101
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 21:07:55 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoetg05977;
	Wed, 5 Mar 2003 21:07:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoetb14720
	for mpls-outgoing; Wed, 5 Mar 2003 19:49:43 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoetb14700
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 19:49:22 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoetb26833
	for <mpls@uu.net>; Wed, 5 Mar 2003 19:49:11 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetb22721
	for <mpls@uu.net>; Wed, 5 Mar 2003 19:49:10 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoetb22705
	for <mpls@uu.net>; Wed, 5 Mar 2003 19:49:10 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h25Jn6JR029052
	for <mpls@uu.net>; Wed, 5 Mar 2003 14:49:07 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA24861 for <mpls@uu.net>; Wed, 5 Mar 2003 14:49:06 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h25Jn6604056 for mpls@uu.net; Wed, 5 Mar 2003 14:49:06 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoetb14611
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 19:47:39 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoetb17580
	for <mpls@UU.NET>; Wed, 5 Mar 2003 19:46:57 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetb19367
	for <mpls@UU.NET>; Wed, 5 Mar 2003 19:46:57 GMT
Received: from sj-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-core-1.cisco.com [171.71.177.237])
	id QQoetb19360
	for <mpls@UU.NET>; Wed, 5 Mar 2003 19:46:56 GMT
Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34])
	by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h25Jkov2013078;
	Wed, 5 Mar 2003 11:46:50 -0800 (PST)
Received: from cisco.com (sjc-vpn3-502.cisco.com [10.21.65.246])
	by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA)
	with SMTP id AEN52927;
	Wed, 5 Mar 2003 11:29:04 -0800 (PST)
Received: by cisco.com (sSMTP sendmail emulation); Wed, 5 Mar 2003 14:46:48 -0500
Date: Wed, 5 Mar 2003 14:46:48 -0500
From: Scott W Brim <sbrim@cisco.com>
To: Alex Zinin <zinin@psg.com>
Cc: Shahram Davari <Shahram_Davari@pmc-sierra.com>,
        "'Mark.Jones@mail.sprint.com'" <Mark.Jones@mail.sprint.com>,
        ccamp@ops.ietf.org, mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Message-ID: <20030305194647.GY2400@sbrim-w2k>
Mail-Followup-To: Scott W Brim <sbrim@cisco.com>,
	Alex Zinin <zinin@psg.com>,
	Shahram Davari <Shahram_Davari@pmc-sierra.com>,
	"'Mark.Jones@mail.sprint.com'" <Mark.Jones@mail.sprint.com>,
	ccamp@ops.ietf.org, mpls@UU.NET
References: <4B6D09F3B826D411A67300D0B706EFDEB03D60@nt-exch-yow.pmc-sierra.bc.ca> <18057706577.20030305113734@psg.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <18057706577.20030305113734@psg.com>
User-Agent: Mutt/1.4i
Sender: owner-mpls@UU.NET
Precedence: bulk

On Wed, Mar 05, 2003 11:37:34AM -0800, Alex Zinin allegedly wrote:
> Wednesday, March 5, 2003, 11:12:10 AM, Shahram Davari wrote:
> [...]
> > 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.
> 
> Ouch... draft-iesg-vendor-extensions-00.txt

But that doesn't solve the problem.  There are some protocol
requirements that can't be met just by extra semantics.



From owner-mpls@UU.NET  Wed Mar  5 16:26:11 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29734
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 16:26:11 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeth11846
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 21:28:14 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeth11740;
	Wed, 5 Mar 2003 21:28:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoetd04925
	for mpls-outgoing; Wed, 5 Mar 2003 20:28:21 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoetd04741
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 20:27:50 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoetb17136
	for <mpls@uu.net>; Wed, 5 Mar 2003 19:57:14 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetb10116
	for <mpls@uu.net>; Wed, 5 Mar 2003 19:57:13 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoetb10108
	for <mpls@uu.net>; Wed, 5 Mar 2003 19:57:13 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h25JvANh013676
	for <mpls@uu.net>; Wed, 5 Mar 2003 14:57:11 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA25466 for <mpls@uu.net>; Wed, 5 Mar 2003 14:57:09 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h25Jv9M05394 for mpls@uu.net; Wed, 5 Mar 2003 14:57:09 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoetb15027
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 19:55:12 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoetb20260
	for <mpls@UU.NET>; Wed, 5 Mar 2003 19:54:42 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetb00855
	for <mpls@UU.NET>; Wed, 5 Mar 2003 19:54:41 GMT
Received: from mother.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12])
	id QQoetb00828
	for <mpls@UU.NET>; Wed, 5 Mar 2003 19:54:40 GMT
Received: (qmail 1287 invoked by uid 104); 5 Mar 2003 19:54:39 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4250.  Clear:. 
 Processed in 0.807691 secs); 05 Mar 2003 19:54:39 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by mother.pmc-sierra.bc.ca with SMTP; 5 Mar 2003 19:54:36 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h25Jsah12849;
	Wed, 5 Mar 2003 11:54:36 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <DCP4HGCA>; Wed, 5 Mar 2003 11:54:36 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03D61@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Scott W Brim'" <sbrim@cisco.com>, Alex Zinin <zinin@psg.com>
Cc: "'Mark.Jones@mail.sprint.com'" <Mark.Jones@mail.sprint.com>,
        ccamp@ops.ietf.org, mpls@UU.NET
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Wed, 5 Mar 2003 11:54:34 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

>> > 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.
>> 
>> Ouch... draft-iesg-vendor-extensions-00.txt
>
>But that doesn't solve the problem.  There are some protocol
>requirements that can't be met just by extra semantics.
>

Could you please give an example. 

-Shahram



From owner-mpls@UU.NET  Wed Mar  5 16:27:41 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29821
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 16:27:40 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeth11688
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 21:29:38 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeth11489;
	Wed, 5 Mar 2003 21:29:33 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoete05387
	for mpls-outgoing; Wed, 5 Mar 2003 20:32:47 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoete05376
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 20:32:40 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoete04369
	for <mpls@uu.net>; Wed, 5 Mar 2003 20:32:11 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoete07314
	for <mpls@uu.net>; Wed, 5 Mar 2003 20:32:10 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoete07279
	for <mpls@uu.net>; Wed, 5 Mar 2003 20:32:10 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h25KW7Nh016606
	for <mpls@uu.net>; Wed, 5 Mar 2003 15:32:08 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA28393 for <mpls@uu.net>; Wed, 5 Mar 2003 15:32:07 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h25KW7T09904 for mpls@uu.net; Wed, 5 Mar 2003 15:32:07 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoete05133
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 20:30:31 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoetd24290
	for <mpls@UU.NET>; Wed, 5 Mar 2003 20:29:56 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetd02485
	for <mpls@UU.NET>; Wed, 5 Mar 2003 20:29:53 GMT
Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoetd02308
	for <mpls@UU.NET>; Wed, 5 Mar 2003 20:29:49 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA28678;
	Wed, 5 Mar 2003 15:27:11 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303052027.PAA28678@workhorse.fictitious.org>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
cc: "'Mark.Jones@mail.sprint.com'" <Mark.Jones@mail.sprint.com>,
        ccamp@ops.ietf.org, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
In-reply-to: Your message of "Wed, 05 Mar 2003 11:12:10 PST."
             <4B6D09F3B826D411A67300D0B706EFDEB03D60@nt-exch-yow.pmc-sierra.bc.ca> 
Date: Wed, 05 Mar 2003 15:27:11 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <4B6D09F3B826D411A67300D0B706EFDEB03D60@nt-exch-yow.pmc-sierra.bc.ca
>, Shahram Davari writes:
> >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.  
> 
> 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.

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

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.

Curtis



From owner-mpls@UU.NET  Wed Mar  5 16:31:24 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00187
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 16:31:24 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeti20160
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 21:33:27 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeti20110;
	Wed, 5 Mar 2003 21:33:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoetf06931
	for mpls-outgoing; Wed, 5 Mar 2003 20:48:14 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoetf06915
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 20:48:06 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoetf10419
	for <mpls@uu.net>; Wed, 5 Mar 2003 20:47:41 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetf03438
	for <mpls@uu.net>; Wed, 5 Mar 2003 20:47:40 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoetf03409
	for <mpls@uu.net>; Wed, 5 Mar 2003 20:47:39 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h25KlaJR008047
	for <mpls@uu.net>; Wed, 5 Mar 2003 15:47:36 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA29594 for <mpls@uu.net>; Wed, 5 Mar 2003 15:47:36 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h25Klad12394 for mpls@uu.net; Wed, 5 Mar 2003 15:47:36 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoete06292
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 20:44:22 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoete23326
	for <mpls@UU.NET>; Wed, 5 Mar 2003 20:42:56 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoete00915
	for <mpls@UU.NET>; Wed, 5 Mar 2003 20:42:56 GMT
Received: from mother.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12])
	id QQoete00900
	for <mpls@UU.NET>; Wed, 5 Mar 2003 20:42:55 GMT
Received: (qmail 16445 invoked by uid 104); 5 Mar 2003 20:42:55 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4250.  Clear:. 
 Processed in 0.458665 secs); 05 Mar 2003 20:42:55 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by mother.pmc-sierra.bc.ca with SMTP; 5 Mar 2003 20:42:54 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h25Kgrh01799;
	Wed, 5 Mar 2003 12:42:53 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <DCP4HHCB>; Wed, 5 Mar 2003 12:42:53 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03D62@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>
Cc: "'Mark.Jones@mail.sprint.com'" <Mark.Jones@mail.sprint.com>,
        ccamp@ops.ietf.org, mpls@UU.NET
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
Date: Wed, 5 Mar 2003 12:42:51 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk



>-----Original Message-----
>From: Curtis Villamizar [mailto:curtis@fictitious.org]
>Sent: Wednesday, March 05, 2003 3:27 PM
>To: Shahram Davari
>Cc: 'Mark.Jones@mail.sprint.com'; ccamp@ops.ietf.org; mpls@UU.NET
>Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
>
>
>
>In message 
><4B6D09F3B826D411A67300D0B706EFDEB03D60@nt-exch-yow.pmc-sierra.bc.ca
>>, Shahram Davari writes:
>> >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.  
>> 
>> 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 owner-mpls@UU.NET  Wed Mar  5 16:56:41 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01772
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 16:56:40 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetj21027
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 21:58:44 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoetj20983;
	Wed, 5 Mar 2003 21:58:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeti29301
	for mpls-outgoing; Wed, 5 Mar 2003 21:30:29 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoeti29258
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 21:30:14 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoeth11707
	for <mpls@UU.NET>; Wed, 5 Mar 2003 21:28:02 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeth08151
	for <mpls@UU.NET>; Wed, 5 Mar 2003 21:28:01 GMT
Received: from lightwave.chromisys.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: lightwave.chromisys.com [63.102.55.206])
	id QQoeth08120
	for <mpls@UU.NET>; Wed, 5 Mar 2003 21:28:01 GMT
Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19)
	id <4GJZGQTT>; Wed, 5 Mar 2003 13:27:50 -0800
Message-ID: <9D42C6E086250248810DCADA39CE7EFC9722B4@nimbus>
From: John Drake <jdrake@calient.net>
To: "'Zhi-Wei Lin'" <zwlin@comcast.net>, mpls@UU.NET
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Wed, 5 Mar 2003 13:27:41 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk



> -----Original Message-----
> From: Zhi-Wei Lin [mailto:zwlin@comcast.net]
> Sent: Wednesday, March 05, 2003 11:56 AM
> To: mpls@UU.NET
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> 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 owner-mpls@UU.NET  Wed Mar  5 17:07:36 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02263
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 17:07:36 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetk06161
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 22:09:39 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoetk06043;
	Wed, 5 Mar 2003 22:09:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeti00140
	for mpls-outgoing; Wed, 5 Mar 2003 21:41:01 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoeti00064
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 21:40:53 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoeti20886
	for <mpls@UU.NET>; Wed, 5 Mar 2003 21:40:39 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeti27680
	for <mpls@UU.NET>; Wed, 5 Mar 2003 21:40:38 GMT
Received: from bt0g2p.god.bel.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alc136.alcatel.be [195.207.101.136])
	id QQoeti27666
	for <mpls@UU.NET>; Wed, 5 Mar 2003 21:40:38 GMT
Received: from bemail05.net.alcatel.be (relay3 [127.0.0.1])
	by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id h25LeXb09099;
	Wed, 5 Mar 2003 22:40:33 +0100
Received: from alcatel.be ([138.203.64.155])
          by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11)
          with ESMTP id 2003030522403201:5050 ;
          Wed, 5 Mar 2003 22:40:32 +0100 
Message-ID: <3E666E91.43E017FB@alcatel.be>
Date: Wed, 05 Mar 2003 22:39:29 +0100
From: Dimitri.Papadimitriou@alcatel.be
Organization: optical network architecture (nta - antwerpen)
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Zhi-Wei Lin <zwlin@comcast.net>
CC: mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <15e5d16eb2.16eb215e5d@icomcast.net>
X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 03/05/2003 22:40:32,
	Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 03/05/2003 22:40:32,
	Serialize complete at 03/05/2003 22:40:32
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

zhi,

some comments in-line (i hope this will open the discussion
on this):

Zhi-Wei Lin wrote:
> 
> 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. 

1) yep, and this is why i try to open a discussion here

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

three things here:

1) well i am surprised because in both directions there are problems
   - if what's in the current document doesn't do the job for full 
     call/connection separation you will be obliged to have a new
     mechanism
   - if what's in the current document does the job and the message is 
     received by a non-compliant gmpls node you will setup the
connection 
     without prior establishment of the call !

2) you say that call controllers do not need to be co-located to 
     connection controllers but then how using the current mechanism
     you can simultaneously setup the call and connection ?

3) you say in this "Note that although the CALL_ID object is optional
for GMPLS 
   signaling, this object is mandatory for ASON-compliant networks, 
   i.e., the Resv message MUST include the CALL_ID object."
   so if you mandate it's usage at edges, following this an operator
   that doesn't implement these extensions is not capable to setup an 
   lsp through an ason network... this is a major problem in case edge
   devices are lsr's that will be for most of them gmpls compliant

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

1) the notify mechanism allows for setting a call w/o connections
2) we do not need new object or extension to name a bunch of lsp's 
  (just using session name)
  
> 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...

1) let's hope not ;-)
 
> 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.

1) this doesn't preclude the other and i am very concerned
   today by the separate specifications we have, the first
   step in a good collaboration is by having a common spec
   on signalling 
 
> Let's try and start working based on a more collaborative mode instead
> of simply making these noise.

1) of course but let me point out something here, i think
   the source noise come when people claim to cover full
   call/connection separation when section 10 in the current
   version of the document suffers from the problem indicated
   here above 
 
> Looking forward to hearing your responses!

1) hope this clarifies a bit 

- dimitri.

> Zhi

-- 
Papadimitriou Dimitri 
E-mail : dimitri.papadimitriou@alcatel.be 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491


From owner-mpls@UU.NET  Wed Mar  5 17:23:26 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02719
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 17:23:26 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetl07225
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 22:25:28 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoetl07128;
	Wed, 5 Mar 2003 22:25:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoetj01607
	for mpls-outgoing; Wed, 5 Mar 2003 21:57:27 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoetj01593
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 21:57:19 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoetj02481
	for <mpls@uu.net>; Wed, 5 Mar 2003 21:57:12 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetj21743
	for <mpls@uu.net>; Wed, 5 Mar 2003 21:57:12 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoetj21723
	for <mpls@uu.net>; Wed, 5 Mar 2003 21:57:11 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h25Lv8JR019670
	for <mpls@uu.net>; Wed, 5 Mar 2003 16:57:09 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA05841 for <mpls@uu.net>; Wed, 5 Mar 2003 16:57:06 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h25Lv6q25406 for mpls@uu.net; Wed, 5 Mar 2003 16:57:06 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoetj01352
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 21:55:44 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoetj28992
	for <mpls@UU.NET>; Wed, 5 Mar 2003 21:55:30 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetj19392
	for <mpls@UU.NET>; Wed, 5 Mar 2003 21:55:29 GMT
Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoetj19388
	for <mpls@UU.NET>; Wed, 5 Mar 2003 21:55:29 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA29138;
	Wed, 5 Mar 2003 16:53:07 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303052153.QAA29138@workhorse.fictitious.org>
To: Alex Zinin <zinin@psg.com>
cc: Shahram Davari <Shahram_Davari@pmc-sierra.com>,
        "'Mark.Jones@mail.sprint.com'" <Mark.Jones@mail.sprint.com>,
        ccamp@ops.ietf.org, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
In-reply-to: Your message of "Wed, 05 Mar 2003 11:37:34 PST."
             <18057706577.20030305113734@psg.com> 
Date: Wed, 05 Mar 2003 16:53:07 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <18057706577.20030305113734@psg.com>, Alex Zinin writes:
> Wednesday, March 5, 2003, 11:12:10 AM, Shahram Davari wrote:
> [...]
> > 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.
> 
> Ouch... draft-iesg-vendor-extensions-00.txt
> 
> Alex


Looks like the IESG doesn't agree with Shahram on this.

Curtis



From owner-mpls@UU.NET  Wed Mar  5 18:20:05 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05869
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 18:20:05 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetp09733
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 23:22:08 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoetp09659;
	Wed, 5 Mar 2003 23:22:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoetl22341
	for mpls-outgoing; Wed, 5 Mar 2003 22:28:45 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoetl22332
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 22:28:37 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoetl17537
	for <mpls@UU.NET>; Wed, 5 Mar 2003 22:28:36 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetl12186
	for <mpls@UU.NET>; Wed, 5 Mar 2003 22:28:35 GMT
Received: from lightwave.chromisys.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: lightwave.chromisys.com [63.102.55.206])
	id QQoetl12167
	for <mpls@UU.NET>; Wed, 5 Mar 2003 22:28:35 GMT
Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19)
	id <4GJZGQYJ>; Wed, 5 Mar 2003 14:28:32 -0800
Message-ID: <9D42C6E086250248810DCADA39CE7EFC9722B9@nimbus>
From: John Drake <jdrake@calient.net>
To: "'Dimitri.Papadimitriou@alcatel.be'"
	 <Dimitri.Papadimitriou@alcatel.be>,
        Zhi-Wei Lin <zwlin@comcast.net>
Cc: mpls@UU.NET
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Wed, 5 Mar 2003 14:28:27 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Snipped...

> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be
> [mailto:Dimitri.Papadimitriou@alcatel.be]
> Sent: Wednesday, March 05, 2003 1:39 PM
> To: Zhi-Wei Lin
> Cc: mpls@UU.NET
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 3) you say in this "Note that although the CALL_ID object is optional
> for GMPLS 
>    signaling, this object is mandatory for ASON-compliant networks, 
>    i.e., the Resv message MUST include the CALL_ID object."
>    so if you mandate it's usage at edges, following this an operator
>    that doesn't implement these extensions is not capable to setup an 
>    lsp through an ason network... this is a major problem in case edge
>    devices are lsr's that will be for most of them gmpls compliant
> 

JD:  There is the same issue wrt Generalized UNI


From owner-mpls@UU.NET  Wed Mar  5 18:45:31 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06488
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 18:45:30 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetr12132
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 23:47:34 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoetr12059;
	Wed, 5 Mar 2003 23:47:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoetm23022
	for mpls-outgoing; Wed, 5 Mar 2003 22:38:43 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoetm23010
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 22:38:39 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoetm22396
	for <mpls@uu.net>; Wed, 5 Mar 2003 22:38:06 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetm23729
	for <mpls@uu.net>; Wed, 5 Mar 2003 22:38:05 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoetm23711
	for <mpls@uu.net>; Wed, 5 Mar 2003 22:38:04 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h25Mc2JR026146
	for <mpls@uu.net>; Wed, 5 Mar 2003 17:38:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA09018 for <mpls@uu.net>; Wed, 5 Mar 2003 17:38:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h25Mc2300624 for mpls@uu.net; Wed, 5 Mar 2003 17:38:02 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoetm22924
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 22:36:55 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoetm25414
	for <mpls@UU.NET>; Wed, 5 Mar 2003 22:36:28 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetm22287
	for <mpls@UU.NET>; Wed, 5 Mar 2003 22:36:28 GMT
Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoetm22273
	for <mpls@UU.NET>; Wed, 5 Mar 2003 22:36:27 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id RAA29708;
	Wed, 5 Mar 2003 17:34:04 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303052234.RAA29708@workhorse.fictitious.org>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
cc: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        Alex Zinin <zinin@psg.com>,
        "'Mark.Jones@mail.sprint.com'" <Mark.Jones@mail.sprint.com>,
        ccamp@ops.ietf.org, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
In-reply-to: Your message of "Wed, 05 Mar 2003 14:12:59 PST."
             <4B6D09F3B826D411A67300D0B706EFDEB03D65@nt-exch-yow.pmc-sierra.bc.ca> 
Date: Wed, 05 Mar 2003 17:34:04 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <4B6D09F3B826D411A67300D0B706EFDEB03D65@nt-exch-yow.pmc-sierra.bc.ca
>, 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


> >-----Original Message-----
> >From: Curtis Villamizar [mailto:curtis@fictitious.org]
> >Sent: Wednesday, March 05, 2003 4:53 PM
> >To: Alex Zinin
> >Cc: Shahram Davari; 'Mark.Jones@mail.sprint.com'; ccamp@ops.ietf.org;
> >mpls@UU.NET
> >Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
> >
> >
> >
> >In message <18057706577.20030305113734@psg.com>, Alex Zinin writes:
> >> Wednesday, March 5, 2003, 11:12:10 AM, Shahram Davari wrote:
> >> [...]
> >> > 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.
> >> 
> >> Ouch... draft-iesg-vendor-extensions-00.txt
> >> 
> >> Alex
> >
> >
> >Looks like the IESG doesn't agree with Shahram on this.
> >
> >Curtis
> >
> 



From owner-mpls@UU.NET  Wed Mar  5 18:49:58 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06805
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 18:49:58 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetr25050
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 23:52:01 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoetr24638;
	Wed, 5 Mar 2003 23:51:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoetm23295
	for mpls-outgoing; Wed, 5 Mar 2003 22:41:37 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoetm23277
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 22:41:28 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoetm11531
	for <mpls@uu.net>; Wed, 5 Mar 2003 22:41:11 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetm26796
	for <mpls@uu.net>; Wed, 5 Mar 2003 22:41:10 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoetm26782
	for <mpls@uu.net>; Wed, 5 Mar 2003 22:41:10 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h25Mf7JR026568
	for <mpls@uu.net>; Wed, 5 Mar 2003 17:41:07 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA09230 for <mpls@uu.net>; Wed, 5 Mar 2003 17:41:06 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h25Mf6m00853 for mpls@uu.net; Wed, 5 Mar 2003 17:41:06 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoetk21054
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 22:14:38 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoetk14494
	for <mpls@UU.NET>; Wed, 5 Mar 2003 22:13:08 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetk14549
	for <mpls@UU.NET>; Wed, 5 Mar 2003 22:13:07 GMT
Received: from father.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13])
	id QQoetk14545
	for <mpls@UU.NET>; Wed, 5 Mar 2003 22:13:07 GMT
Received: (qmail 4863 invoked by uid 104); 5 Mar 2003 22:13:02 -0000
Received: from Shahram_Davari@pmc-sierra.com by father by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4250.  Clear:. 
 Processed in 0.77537 secs); 05 Mar 2003 22:13:02 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by father.pmc-sierra.bc.ca with SMTP; 5 Mar 2003 22:13:01 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h25MD0h07790;
	Wed, 5 Mar 2003 14:13:00 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <DCP4HJDW>; Wed, 5 Mar 2003 14:13:00 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03D65@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        Alex Zinin
	 <zinin@psg.com>
Cc: "'Mark.Jones@mail.sprint.com'" <Mark.Jones@mail.sprint.com>,
        ccamp@ops.ietf.org, mpls@UU.NET
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
Date: Wed, 5 Mar 2003 14:12:59 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Is IESG=Curtis?

-Shahram

>-----Original Message-----
>From: Curtis Villamizar [mailto:curtis@fictitious.org]
>Sent: Wednesday, March 05, 2003 4:53 PM
>To: Alex Zinin
>Cc: Shahram Davari; 'Mark.Jones@mail.sprint.com'; ccamp@ops.ietf.org;
>mpls@UU.NET
>Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
>
>
>
>In message <18057706577.20030305113734@psg.com>, Alex Zinin writes:
>> Wednesday, March 5, 2003, 11:12:10 AM, Shahram Davari wrote:
>> [...]
>> > 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.
>> 
>> Ouch... draft-iesg-vendor-extensions-00.txt
>> 
>> Alex
>
>
>Looks like the IESG doesn't agree with Shahram on this.
>
>Curtis
>



From owner-mpls@UU.NET  Wed Mar  5 18:57:41 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07101
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 18:57:41 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetr16240
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 23:59:44 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoetr15689;
	Wed, 5 Mar 2003 23:59:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoetn24347
	for mpls-outgoing; Wed, 5 Mar 2003 22:49:12 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoetn24314
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 22:48:55 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoetn21378
	for <mpls@uu.net>; Wed, 5 Mar 2003 22:48:08 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetn03193
	for <mpls@uu.net>; Wed, 5 Mar 2003 22:48:08 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoetn03175
	for <mpls@uu.net>; Wed, 5 Mar 2003 22:48:07 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h25Mm5JR027468
	for <mpls@uu.net>; Wed, 5 Mar 2003 17:48:05 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA09736 for <mpls@uu.net>; Wed, 5 Mar 2003 17:48:04 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h25Mm4S02087 for mpls@uu.net; Wed, 5 Mar 2003 17:48:04 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoetn23780
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 22:45:45 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoetn28453
	for <mpls@UU.NET>; Wed, 5 Mar 2003 22:45:11 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetn00441
	for <mpls@UU.NET>; Wed, 5 Mar 2003 22:45:11 GMT
Received: from mother.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12])
	id QQoetn00434
	for <mpls@UU.NET>; Wed, 5 Mar 2003 22:45:10 GMT
Received: (qmail 28574 invoked by uid 104); 5 Mar 2003 22:45:09 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4250.  Clear:. 
 Processed in 0.469928 secs); 05 Mar 2003 22:45:09 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by mother.pmc-sierra.bc.ca with SMTP; 5 Mar 2003 22:45:08 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h25Mj8h23017;
	Wed, 5 Mar 2003 14:45:08 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <DCP4HJ84>; Wed, 5 Mar 2003 14:45:07 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03D68@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>
Cc: Alex Zinin <zinin@psg.com>,
        "'Mark.Jones@mail.sprint.com'"
	 <Mark.Jones@mail.sprint.com>,
        ccamp@ops.ietf.org, mpls@UU.NET
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
Date: Wed, 5 Mar 2003 14:45:05 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Thanks for your clarification. A couple of points:

1) Is the decision on how to deal with extension requests, an IESG
decision or an IETF consensus is required?

2) No one can stop other SDOs from extending any IETF protocol

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.

-Shahram

>-----Original Message-----
>From: Curtis Villamizar [mailto:curtis@fictitious.org]
>Sent: Wednesday, March 05, 2003 5:34 PM
>To: Shahram Davari
>Cc: 'curtis@fictitious.org'; Alex Zinin; 'Mark.Jones@mail.sprint.com';
>ccamp@ops.ietf.org; mpls@UU.NET
>Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
>
>
>
>In message 
><4B6D09F3B826D411A67300D0B706EFDEB03D65@nt-exch-yow.pmc-sierra.bc.ca
>>, 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
>
>
>> >-----Original Message-----
>> >From: Curtis Villamizar [mailto:curtis@fictitious.org]
>> >Sent: Wednesday, March 05, 2003 4:53 PM
>> >To: Alex Zinin
>> >Cc: Shahram Davari; 'Mark.Jones@mail.sprint.com'; 
>ccamp@ops.ietf.org;
>> >mpls@UU.NET
>> >Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
>> >
>> >
>> >
>> >In message <18057706577.20030305113734@psg.com>, Alex Zinin writes:
>> >> Wednesday, March 5, 2003, 11:12:10 AM, Shahram Davari wrote:
>> >> [...]
>> >> > 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.
>> >> 
>> >> Ouch... draft-iesg-vendor-extensions-00.txt
>> >> 
>> >> Alex
>> >
>> >
>> >Looks like the IESG doesn't agree with Shahram on this.
>> >
>> >Curtis
>> >
>> 
>



From owner-mpls@UU.NET  Wed Mar  5 19:02:02 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07319
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 19:02:01 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoets29633
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 00:04:05 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoets29220;
	Thu, 6 Mar 2003 00:03:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoetn24809
	for mpls-outgoing; Wed, 5 Mar 2003 22:53:30 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoetn24769
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 22:53:11 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoetn11499
	for <mpls@UU.NET>; Wed, 5 Mar 2003 22:52:58 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetn08375
	for <mpls@UU.NET>; Wed, 5 Mar 2003 22:52:58 GMT
Received: from auemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: auemail2.lucent.com [192.11.223.163])
	id QQoetn08343
	for <mpls@UU.NET>; Wed, 5 Mar 2003 22:52:57 GMT
Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58])
	by auemail2.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h25MqtP22604;
	Wed, 5 Mar 2003 17:52:55 -0500 (EST)
Received: from lucent.com (cc316.mv.lucent.com [135.13.162.152]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id RAA08652; Wed, 5 Mar 2003 17:52:54 -0500 (EST)
Message-ID: <3E66802A.A56B54C@lucent.com>
Date: Wed, 05 Mar 2003 17:54:34 -0500
From: Yangguang Xu <xuyg@lucent.com>
Organization: Lucent Technologies ,  Optical Networking Group, MV
X-Mailer: Mozilla 4.76C-CCK-MCD EMS-1.5 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Dimitri.Papadimitriou@alcatel.be, Zhi-Wei Lin <zwlin@comcast.net>
CC: mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <15e5d16eb2.16eb215e5d@icomcast.net> <3E666E91.43E017FB@alcatel.be>
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

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.

In a specific GMPLS cloud, call can be view as an edge-directly to-edge
operation. It indeed skips the intemediate NEs which are used to only to pass
the call information. The edge NE (with the call capability) decides when to
trigger the connection operation between the edges. Even call/connection can
happen at the same time, they are two different logical steps. 

So, 
-- if a call has no connection, it doesn't allocate resources in the
intermediate nodes. (Indeed, can the incoming edge send directly to the egress
edge if it decides only setting up any connection? ) 
-- connection can only be set up by NEs be able to handle call. So the
connection before call shouldn't happen in this mode of operation. 
-- Where call controller and connection controller locate has nothing to do the
call/connection operation sequence
-- If your NE is not ASON/G.7713 compliant, you can use other mechanisms to
trigger connection. Yet, if your NE is ASON/G.7713 compliant, the NE MUST
support CALL_ID.

Regards,

Yangguang


> three things here:
> 
> 1) well i am surprised because in both directions there are problems
>    - if what's in the current document doesn't do the job for full
>      call/connection separation you will be obliged to have a new
>      mechanism
>    - if what's in the current document does the job and the message is
>      received by a non-compliant gmpls node you will setup the
> connection
>      without prior establishment of the call !
> 
> 2) you say that call controllers do not need to be co-located to
>      connection controllers but then how using the current mechanism
>      you can simultaneously setup the call and connection ?
> 
> 3) you say in this "Note that although the CALL_ID object is optional
> for GMPLS
>    signaling, this object is mandatory for ASON-compliant networks,
>    i.e., the Resv message MUST include the CALL_ID object."
>    so if you mandate it's usage at edges, following this an operator
>    that doesn't implement these extensions is not capable to setup an
>    lsp through an ason network... this is a major problem in case edge
>    devices are lsr's that will be for most of them gmpls compliant
>


From owner-mpls@UU.NET  Wed Mar  5 19:14:09 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07523
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 19:14:09 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoett25358
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 00:16:13 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoett25132;
	Thu, 6 Mar 2003 00:16:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoetp15183
	for mpls-outgoing; Wed, 5 Mar 2003 23:18:11 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoetp15173
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 23:18:06 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoetp22591
	for <mpls@uu.net>; Wed, 5 Mar 2003 23:16:19 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetp15496
	for <mpls@uu.net>; Wed, 5 Mar 2003 23:16:17 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoetp15186
	for <mpls@uu.net>; Wed, 5 Mar 2003 23:16:07 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h25NG4JR000634
	for <mpls@uu.net>; Wed, 5 Mar 2003 18:16:04 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA11561 for <mpls@uu.net>; Wed, 5 Mar 2003 18:16:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h25NG3G06742 for mpls@uu.net; Wed, 5 Mar 2003 18:16:03 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoeto14553
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 23:13:15 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoeto29985
	for <mpls@UU.NET>; Wed, 5 Mar 2003 23:12:40 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeto06603
	for <mpls@UU.NET>; Wed, 5 Mar 2003 23:12:39 GMT
Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoeto06588
	for <mpls@UU.NET>; Wed, 5 Mar 2003 23:12:38 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id SAA30203;
	Wed, 5 Mar 2003 18:10:15 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303052310.SAA30203@workhorse.fictitious.org>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
cc: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        Alex Zinin <zinin@psg.com>,
        "'Mark.Jones@mail.sprint.com'" <Mark.Jones@mail.sprint.com>,
        ccamp@ops.ietf.org, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
In-reply-to: Your message of "Wed, 05 Mar 2003 14:45:05 PST."
             <4B6D09F3B826D411A67300D0B706EFDEB03D68@nt-exch-yow.pmc-sierra.bc.ca> 
Date: Wed, 05 Mar 2003 18:10:15 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <4B6D09F3B826D411A67300D0B706EFDEB03D68@nt-exch-yow.pmc-sierra.bc.ca
>, Shahram Davari writes:
> Thanks for your clarification. A couple of points:
> 
> 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.

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

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

> -Shahram

Curtis


> >-----Original Message-----
> >From: Curtis Villamizar [mailto:curtis@fictitious.org]
> >Sent: Wednesday, March 05, 2003 5:34 PM
> >To: Shahram Davari
> >Cc: 'curtis@fictitious.org'; Alex Zinin; 'Mark.Jones@mail.sprint.com';
> >ccamp@ops.ietf.org; mpls@UU.NET
> >Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
> >
> >
> >
> >In message 
> ><4B6D09F3B826D411A67300D0B706EFDEB03D65@nt-exch-yow.pmc-sierra.bc.ca
> >>, 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
> >
> >
> >> >-----Original Message-----
> >> >From: Curtis Villamizar [mailto:curtis@fictitious.org]
> >> >Sent: Wednesday, March 05, 2003 4:53 PM
> >> >To: Alex Zinin
> >> >Cc: Shahram Davari; 'Mark.Jones@mail.sprint.com'; 
> >ccamp@ops.ietf.org;
> >> >mpls@UU.NET
> >> >Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
> >> >
> >> >
> >> >
> >> >In message <18057706577.20030305113734@psg.com>, Alex Zinin writes:
> >> >> Wednesday, March 5, 2003, 11:12:10 AM, Shahram Davari wrote:
> >> >> [...]
> >> >> > 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.
> >> >> 
> >> >> Ouch... draft-iesg-vendor-extensions-00.txt
> >> >> 
> >> >> Alex
> >> >
> >> >
> >> >Looks like the IESG doesn't agree with Shahram on this.
> >> >
> >> >Curtis
> >> >
> >> 
> >
> 



From owner-mpls@UU.NET  Wed Mar  5 20:50:48 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09837
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 20:50:47 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetz12125
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 01:52:50 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoetz12010;
	Thu, 6 Mar 2003 01:52:47 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoetx01609
	for mpls-outgoing; Thu, 6 Mar 2003 01:26:28 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoetx01596
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 01:26:16 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoetx04433
	for <mpls@UU.NET>; Thu, 6 Mar 2003 01:25:16 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetx29577
	for <mpls@UU.NET>; Thu, 6 Mar 2003 01:25:15 GMT
Received: from almso2.proxy.att.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: almso2.att.com [192.128.166.71])
	id QQoetx29565
	for <mpls@UU.NET>; Thu, 6 Mar 2003 01:25:15 GMT
Received: from attrh3i.attrh.att.com ([135.71.62.12])
	by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h261GpXh024616
	for <mpls@UU.NET>; Wed, 5 Mar 2003 20:25:15 -0500 (EST)
Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.032)
        id 3E637D67001CD601; Wed, 5 Mar 2003 20:25:14 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Wed, 5 Mar 2003 20:25:13 -0500
Message-ID: <28F05913385EAC43AF019413F674A01704A1782E@OCCLUST04EVS1.ugd.att.com>
Thread-Topic: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Thread-Index: AcLdei7OCiKqDIIjQ0SYJfNrsPJQbQAHvIogAXZulfA=
From: "Ash, Gerald R (Jerry), ALABS" <gash@att.com>
To: <mpls@UU.NET>, <ccamp@ops.ietf.org>
Cc: "Ash, Gerald R (Jerry), ALABS" <gash@att.com>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA09837

It seems that progress has been made on this thread in initiating a liaison process, etc.

However, a problem still not addressed is:

'problem ga': GMPLS/ASON requirements were put forward by ITU-T but did not get adequate attention/evaluation in IETF, with the unfortunate outcome that now 2 'GMPLS/ASON signaling' (RSVP-TE) standards have emerged, 'itu-gmpls' & 'ietf-gmpls', most likely with interoperability issues.

'itu-gmpls' would appear to be a 'major extension' in the context of http://www.ietf.org/internet-drafts/draft-iesg-vendor-extensions-00.txt.  As such, none of the following recommendations seem to have been followed:

"- All major extensions to IETF protocols should be done with direct involvement of the IETF
-  The decision on whether an extension is major or minor should be done with the direct involvement of the IETF
- Extensions should be done by IETF working groups using normal IETF processes
- Major extensions should be ... checked by the IETF community to be sure that the extension does not defeat safeguards designed into the protocol, such as security functions, or undermine its architectural integrity
- No individual, vendor, SDO or forum should be able to 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."

Could these recommendations now be addressed, perhaps by a team of SMEs, to evaluate/recommend a course of action?  It doesn't matter whether or not this is a formally sanctioned design-team, or a self-organized team of SME's who represent the component SDO interests, as long as a good technical solution emerges.  I've observed that a 'team' of SME's has now 'organized' on this list (on this thread), and in a sense is addressing problem ga, although they're somewhat adversarial in tone at the moment :-).  Could this energy/creativity be targeted at positive technical solutions in terms of the above recommendations?

It's unclear if this kind of problem fits within the scope of the 'problem statement' of draft-andersson-mpls-g-chng-proc, which BTW provides no 'problem statement' as the I-D itself requires.

In any case, problem ga is still there, and to me should at worst not be repeated, and at best be solved & not repeated.

Jerry Ash


From owner-mpls@UU.NET  Wed Mar  5 21:09:34 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10157
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 21:09:34 -0500 (EST)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoetg17324;
	Wed, 5 Mar 2003 21:13:15 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoetb15100
	for mpls-outgoing; Wed, 5 Mar 2003 19:56:11 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoetb15095
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 19:56:07 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoetb13460
	for <mpls@uu.net>; Wed, 5 Mar 2003 19:56:02 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetb08907
	for <mpls@uu.net>; Wed, 5 Mar 2003 19:56:02 GMT
Received: from smtp.comcast.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp.comcast.net [24.153.64.2])
	id QQoetb08887
	for <mpls@uu.net>; Wed, 5 Mar 2003 19:56:02 GMT
Received: from icomcast.net (lb-ldap-155.icomcast.net [172.20.3.155])
 by mtaout03.icomcast.net
 (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003))
 with ESMTP id <0HBA00K5HKPDHZ@mtaout03.icomcast.net> for mpls@uu.net; Wed,
 05 Mar 2003 14:56:01 -0500 (EST)
Received: from [172.20.3.11] by msgstore03.icomcast.net (mshttpd); Wed,
 05 Mar 2003 14:56:01 -0500
Date: Wed, 05 Mar 2003 14:56:01 -0500
From: Zhi-Wei Lin <zwlin@comcast.net>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
To: mpls@UU.NET
Message-id: <15e5d16eb2.16eb215e5d@icomcast.net>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.12 (built Feb 13 2003)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7BIT

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

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

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

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 owner-mpls@UU.NET  Wed Mar  5 21:18:49 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10366
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 21:18:49 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeub28420
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 02:20:51 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeub28395;
	Thu, 6 Mar 2003 02:20:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoetz03599
	for mpls-outgoing; Thu, 6 Mar 2003 01:51:29 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoetz03589
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 01:51:16 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoetz07794
	for <mpls@UU.NET>; Thu, 6 Mar 2003 01:51:03 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetz02692
	for <mpls@UU.NET>; Thu, 6 Mar 2003 01:51:03 GMT
Received: from newdev.harvard.edu by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: newdev.eecs.harvard.edu [140.247.60.212])
	id QQoetz02671
	for <mpls@UU.NET>; Thu, 6 Mar 2003 01:51:02 GMT
Received: from newdev.harvard.edu (localhost [127.0.0.1])
	by newdev.harvard.edu (8.12.7/8.12.2) with ESMTP id h261oVe3015751;
	Wed, 5 Mar 2003 20:50:31 -0500 (EST)
Received: (from sob@localhost)
	by newdev.harvard.edu (8.12.7/8.12.2/Submit) id h261oV9A015750;
	Wed, 5 Mar 2003 20:50:31 -0500 (EST)
Date: Wed, 5 Mar 2003 20:50:31 -0500 (EST)
From: Scott  Bradner <sob@harvard.edu>
Message-Id: <200303060150.h261oV9A015750@newdev.harvard.edu>
To: curtis@fictitious.org
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Cc: ccamp@ops.ietf.org, mpls@UU.NET
In-Reply-To: <200303052310.SAA30203@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk

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

this text was well discussed in the IESG before it was turned into
an ID

I expect that the IESG will do a IETF Last-Call on the ID before
publishing it as an RFC to verify if the IETF community concensus
supports the statement that this ID makes

Scott


From owner-mpls@UU.NET  Wed Mar  5 21:19:25 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10384
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 21:19:25 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeub29031
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 02:21:28 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeub29008;
	Thu, 6 Mar 2003 02:21:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoetz03620
	for mpls-outgoing; Thu, 6 Mar 2003 01:51:49 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoetz03611
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 01:51:47 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoetz09424
	for <mpls@UU.NET>; Thu, 6 Mar 2003 01:51:37 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetz03675
	for <mpls@UU.NET>; Thu, 6 Mar 2003 01:51:36 GMT
Received: from newdev.harvard.edu by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: newdev.eecs.harvard.edu [140.247.60.212])
	id QQoetz03636
	for <mpls@UU.NET>; Thu, 6 Mar 2003 01:51:35 GMT
Received: from newdev.harvard.edu (localhost [127.0.0.1])
	by newdev.harvard.edu (8.12.7/8.12.2) with ESMTP id h261pWe3015756;
	Wed, 5 Mar 2003 20:51:32 -0500 (EST)
Received: (from sob@localhost)
	by newdev.harvard.edu (8.12.7/8.12.2/Submit) id h261pWY5015755;
	Wed, 5 Mar 2003 20:51:32 -0500 (EST)
Date: Wed, 5 Mar 2003 20:51:32 -0500 (EST)
From: Scott  Bradner <sob@harvard.edu>
Message-Id: <200303060151.h261pWY5015755@newdev.harvard.edu>
To: ccamp@ops.ietf.org, gash@att.com, mpls@UU.NET
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
In-Reply-To: <28F05913385EAC43AF019413F674A01704A1782E@OCCLUST04EVS1.ugd.att.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

> In any case, problem ga is still there, and to me should at worst not be 
> repeated , and at best be solved & not repeated.

agree

Scott


From owner-mpls@UU.NET  Wed Mar  5 22:07:14 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11076
	for <mpls-archive@lists.ietf.org>; Wed, 5 Mar 2003 22:07:14 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeue23758
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 03:09:17 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeue23732;
	Thu, 6 Mar 2003 03:09:15 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeuc25766
	for mpls-outgoing; Thu, 6 Mar 2003 02:43:11 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoeuc25761
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 02:43:09 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoeuc00924
	for <mpls@UU.NET>; Thu, 6 Mar 2003 02:43:03 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeuc23008
	for <mpls@UU.NET>; Thu, 6 Mar 2003 02:43:02 GMT
Received: from smtp.comcast.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp.comcast.net [24.153.64.2])
	id QQoeuc22957
	for <mpls@UU.NET>; Thu, 6 Mar 2003 02:43:01 GMT
Received: from LINPORTEGE
 (pcp03191818pcs.midltn01.nj.comcast.net [68.36.136.113])
 by mtaout04.icomcast.net
 (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003))
 with SMTP id <0HBB00C973JPAT@mtaout04.icomcast.net> for mpls@UU.NET; Wed,
 05 Mar 2003 21:43:01 -0500 (EST)
Date: Wed, 05 Mar 2003 21:43:00 -0500
From: Zhi-Wei Lin <zwlin@comcast.net>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
To: mpls@UU.NET
Message-id: <002701c2e38a$1a51b6b0$6e00a8c0@na01.lucent.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <9D42C6E086250248810DCADA39CE7EFC9722B9@nimbus>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7BIT

Hi John, Dimitri,

I guess this is another misconception? How an operator will use this, the
operator already knows. This means that if an operator is going to offer
ASON service then they will be expecting their customers to come in with
ASON capable requests. However, if operator is also at the same time
offering GMPLS service, that's fine as well because they will be expecting
to see a GMPLS request.

There is nowhere that says that an operator must only support ASON and
nothing else. What is said is that if an operator is offering ASON service
and not GMPLS, then the request has to come in with an ASON request. I think
this makes sense since the operator has chosen only to support that model.
Alternatively the operator can choose to support both models, or only GMPLS
models.

Hope this explains...

Zhi



----- Original Message -----
From: "John Drake" <jdrake@calient.net>
To: <Dimitri.Papadimitriou@alcatel.be>; "Zhi-Wei Lin" <zwlin@comcast.net>
Cc: <mpls@UU.NET>
Sent: Wednesday, March 05, 2003 5:28 PM
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt


> Snipped...
>
> > -----Original Message-----
> > From: Dimitri.Papadimitriou@alcatel.be
> > [mailto:Dimitri.Papadimitriou@alcatel.be]
> > Sent: Wednesday, March 05, 2003 1:39 PM
> > To: Zhi-Wei Lin
> > Cc: mpls@UU.NET
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > 3) you say in this "Note that although the CALL_ID object is optional
> > for GMPLS
> >    signaling, this object is mandatory for ASON-compliant networks,
> >    i.e., the Resv message MUST include the CALL_ID object."
> >    so if you mandate it's usage at edges, following this an operator
> >    that doesn't implement these extensions is not capable to setup an
> >    lsp through an ason network... this is a major problem in case edge
> >    devices are lsr's that will be for most of them gmpls compliant
> >
>
> JD:  There is the same issue wrt Generalized UNI



From owner-mpls@UU.NET  Thu Mar  6 06:15:27 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01902
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 06:15:27 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoevl23051
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 11:17:28 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoevl22875;
	Thu, 6 Mar 2003 11:17:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoevj24275
	for mpls-outgoing; Thu, 6 Mar 2003 10:51:52 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoevj24270
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 10:51:44 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoevj18099
	for <mpls@UU.NET>; Thu, 6 Mar 2003 10:51:21 GMT
Received: from lightwave.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: lightwave.chromisys.com [63.102.55.206])
	id QQoets00144
	for <mpls@UU.NET>; Thu, 6 Mar 2003 00:10:07 GMT
Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19)
	id <4GJZGQ9S>; Wed, 5 Mar 2003 16:09:48 -0800
Message-ID: <9D42C6E086250248810DCADA39CE7EFC9722BB@nimbus>
From: John Drake <jdrake@calient.net>
To: "'Yangguang Xu'" <xuyg@lucent.com>, Dimitri.Papadimitriou@alcatel.be,
        Zhi-Wei Lin <zwlin@comcast.net>
Cc: mpls@UU.NET
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Wed, 5 Mar 2003 16:09:41 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="GB2312"
Sender: owner-mpls@UU.NET
Precedence: bulk



> -----Original Message-----
> From: Yangguang Xu [mailto:xuyg@lucent.com]
> Sent: Wednesday, March 05, 2003 2:55 PM
> To: Dimitri.Papadimitriou@alcatel.be; Zhi-Wei Lin
> Cc: mpls@UU.NET
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> 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?

> 
> In a specific GMPLS cloud, call can be view as an 
> edge-directly to-edge
> operation. It indeed skips the intemediate NEs which are used 
> to only to pass
> the call information. The edge NE (with the call capability) 
> decides when to
> trigger the connection operation between the edges. Even 
> call/connection can
> happen at the same time, they are two different logical steps. 
> 
> So, 
> -- if a call has no connection, it doesn't allocate resources in the
> intermediate nodes. 

JD:  How is this prevented?

> (Indeed, can the incoming edge send 
> directly to the egress
> edge if it decides only setting up any connection? )

JD:  The technical term for this is Notify.  (Presumably 'any connection'
is a typo for 'a call'?)
 
> -- connection can only be set up by NEs be able to handle call. So the
> connection before call shouldn't happen in this mode of operation.

JD:  How is this prevented?
 
> -- Where call controller and connection controller locate has 
> nothing to do the
> call/connection operation sequence
> -- If your NE is not ASON/G.7713 compliant, you can use other 
> mechanisms to
> trigger connection. Yet, if your NE is ASON/G.7713 compliant, 
> the NE MUST
> support CALL_ID.

JD:  And the right way to do this is the 'Session Name' attribute of
the SESSION_ATTRIBUTE Object, as Dimitri mentioned

> 
> Regards,
> 
> Yangguang
> 
> 
> > three things here:
> > 
> > 1) well i am surprised because in both directions there are problems
> >    - if what's in the current document doesn't do the job for full
> >      call/connection separation you will be obliged to have a new
> >      mechanism
> >    - if what's in the current document does the job and the 
> message is
> >      received by a non-compliant gmpls node you will setup the
> > connection
> >      without prior establishment of the call !
> > 
> > 2) you say that call controllers do not need to be co-located to
> >      connection controllers but then how using the current mechanism
> >      you can simultaneously setup the call and connection ?
> > 
> > 3) you say in this "Note that although the CALL_ID object 
> is optional
> > for GMPLS
> >    signaling, this object is mandatory for ASON-compliant networks,
> >    i.e., the Resv message MUST include the CALL_ID object."
> >    so if you mandate it's usage at edges, following this an operator
> >    that doesn't implement these extensions is not capable 
> to setup an
> >    lsp through an ason network... this is a major problem 
> in case edge
> >    devices are lsr's that will be for most of them gmpls compliant
> >
> 


From owner-mpls@UU.NET  Thu Mar  6 09:10:08 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15392
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 09:10:08 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoevw13172
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 14:12:11 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoevw13071;
	Thu, 6 Mar 2003 14:12:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoevv00766
	for mpls-outgoing; Thu, 6 Mar 2003 13:45:52 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoevv00761
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 13:45:48 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoevv22611
	for <mpls@UU.NET>; Thu, 6 Mar 2003 13:45:09 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoevv06583
	for <mpls@UU.NET>; Thu, 6 Mar 2003 13:45:09 GMT
Received: from zcars04f.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57])
	id QQoevv06563
	for <mpls@UU.NET>; Thu, 6 Mar 2003 13:45:08 GMT
Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67])
	by zcars04f.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26DiwX23788;
	Thu, 6 Mar 2003 08:44:58 -0500 (EST)
Received: from zcard0ke.ca.nortel.com ([47.129.242.166]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id GDFBFD0C; Thu, 6 Mar 2003 08:44:59 -0500
Received: from nortelnetworks.com (artpt5nw.us.nortel.com [47.140.52.81]) by zcard0ke.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id FSM4P151; Thu, 6 Mar 2003 08:44:59 -0500
Message-ID: <3E6751B4.4020208@nortelnetworks.com>
Date: Thu, 06 Mar 2003 08:48:36 -0500
X-Sybari-Space: 00000000 00000000 00000000
From: Don Fedyk <dwfedyk@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Ash, Gerald R (Jerry), ALABS" <gash@att.com>
CC: mpls@UU.NET, ccamp@ops.ietf.org
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <28F05913385EAC43AF019413F674A01704A1782E@OCCLUST04EVS1.ugd.att.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

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 owner-mpls@UU.NET  Thu Mar  6 09:59:50 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17916
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 09:59:50 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewa18822
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 15:01:53 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewa18706;
	Thu, 6 Mar 2003 15:01:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoevy22994
	for mpls-outgoing; Thu, 6 Mar 2003 14:35:53 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoevy22989
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 14:35:49 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoevy12686
	for <mpls@UU.NET>; Thu, 6 Mar 2003 14:35:38 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoevy07838
	for <mpls@UU.NET>; Thu, 6 Mar 2003 14:35:37 GMT
Received: from bt0g2p.god.bel.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alc136.alcatel.be [195.207.101.136])
	id QQoevy07828
	for <mpls@UU.NET>; Thu, 6 Mar 2003 14:35:37 GMT
Received: from bemail05.net.alcatel.be (relay3 [127.0.0.1])
	by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id h26EZZj24375;
	Thu, 6 Mar 2003 15:35:35 +0100
Received: from alcatel.be ([138.203.137.2])
          by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11)
          with ESMTP id 2003030615353426:3459 ;
          Thu, 6 Mar 2003 15:35:34 +0100 
Message-ID: <3E675C75.E773F870@alcatel.be>
Date: Thu, 06 Mar 2003 15:34:30 +0100
From: Dimitri.Papadimitriou@alcatel.be
Organization: optical network architecture (nta - antwerpen)
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Zhi-Wei Lin <zwlin@comcast.net>
CC: mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <9D42C6E086250248810DCADA39CE7EFC9722B9@nimbus> <002701c2e38a$1a51b6b0$6e00a8c0@na01.lucent.com>
X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 03/06/2003 15:35:34,
	Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 03/06/2003 15:35:35,
	Serialize complete at 03/06/2003 15:35:35
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

zhi, i am not sure to understand here, gmpls specifies a
suite of protocols while ason specifies ditto 

"the set of control plane components that are used to manipulate
transport network resources in order to provide the functionality of
setting up, maintaining and releasing connections. The use of components
allows for the separation of call control from connection control and
the separation of routing and signalling."

i don't see indicated "the set of control plane protocol
implementation..."

thus ason can be seen as a control plane model where a set 
of control plane functional mechanisms has been identified, 
and gmpls can be used to implement them, this has been clearly 
identified in the gmpls architecture i-d:

"the architecture presented in this document covers the main building
blocks needed to build a consistent control plane for multiple
switching layers. It does not restrict the way that these layers
work together. Different models can be applied: e.g. overlay,
augmented or integrated."

taking a look at your below e-mail, you have merged this
model with its implementation (i.e. you assimilate ason 
with the set of extensions defined in G.7713.2) and infer 
that this model can only be implemented with these itu
extensions but where have you seen such a restriction
indicated or mentioned in one of the ietf gmpls documents ?

therefore the point that we have reached is much more 
complex than you seem to indicate we will be confronted
in a very short term future to itu extensions for ason 
model and gmpls extensions for ason model (that supports
full call/connection sep.) and i am not sure this is a 
satisfactory outcome for the user community as other 
seems to indicate as well

thanks,
- dimitri.
 
Zhi-Wei Lin wrote:
> 
> Hi John, Dimitri,
> 
> I guess this is another misconception? How an operator will use this, the
> operator already knows. This means that if an operator is going to offer
> ASON service then they will be expecting their customers to come in with
> ASON capable requests. However, if operator is also at the same time
> offering GMPLS service, that's fine as well because they will be expecting
> to see a GMPLS request.
> 
> There is nowhere that says that an operator must only support ASON and
> nothing else. What is said is that if an operator is offering ASON service
> and not GMPLS, then the request has to come in with an ASON request. I think
> this makes sense since the operator has chosen only to support that model.
> Alternatively the operator can choose to support both models, or only GMPLS
> models.
> 
> Hope this explains...
> 
> Zhi
> 
> ----- Original Message -----
> From: "John Drake" <jdrake@calient.net>
> To: <Dimitri.Papadimitriou@alcatel.be>; "Zhi-Wei Lin" <zwlin@comcast.net>
> Cc: <mpls@UU.NET>
> Sent: Wednesday, March 05, 2003 5:28 PM
> Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> > Snipped...
> >
> > > -----Original Message-----
> > > From: Dimitri.Papadimitriou@alcatel.be
> > > [mailto:Dimitri.Papadimitriou@alcatel.be]
> > > Sent: Wednesday, March 05, 2003 1:39 PM
> > > To: Zhi-Wei Lin
> > > Cc: mpls@UU.NET
> > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > > 3) you say in this "Note that although the CALL_ID object is optional
> > > for GMPLS
> > >    signaling, this object is mandatory for ASON-compliant networks,
> > >    i.e., the Resv message MUST include the CALL_ID object."
> > >    so if you mandate it's usage at edges, following this an operator
> > >    that doesn't implement these extensions is not capable to setup an
> > >    lsp through an ason network... this is a major problem in case edge
> > >    devices are lsr's that will be for most of them gmpls compliant
> > >
> >
> > JD:  There is the same issue wrt Generalized UNI

-- 
Papadimitriou Dimitri 
E-mail : dimitri.papadimitriou@alcatel.be 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491


From owner-mpls@UU.NET  Thu Mar  6 10:14:20 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19516
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 10:14:20 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewb11217
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 15:16:23 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewb11148;
	Thu, 6 Mar 2003 15:16:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoevz24534
	for mpls-outgoing; Thu, 6 Mar 2003 14:50:28 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoevz24521
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 14:50:26 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoevz22688
	for <mpls@uu.net>; Thu, 6 Mar 2003 14:49:11 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoevz27798
	for <mpls@uu.net>; Thu, 6 Mar 2003 14:49:10 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoevz27642
	for <mpls@uu.net>; Thu, 6 Mar 2003 14:49:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h26En2ws015028
	for <mpls@uu.net>; Thu, 6 Mar 2003 09:49:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA24526 for <mpls@uu.net>; Thu, 6 Mar 2003 09:49:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h26En2v01464 for mpls@uu.net; Thu, 6 Mar 2003 09:49:02 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoetq16477
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Mar 2003 23:36:00 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoetq08346
	for <mpls@uu.net>; Wed, 5 Mar 2003 23:35:34 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoetq21167
	for <mpls@uu.net>; Wed, 5 Mar 2003 23:35:27 GMT
Received: from pfepc.post.tele.dk by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pfepc.post.tele.dk [193.162.153.4])
	id QQoetq20895
	for <mpls@uu.net>; Wed, 5 Mar 2003 23:35:18 GMT
Received: from oemcomputer (0x503f5b2d.boanxx13.adsl.tele.dk [80.63.91.45])
	by pfepc.post.tele.dk (Postfix) with ESMTP
	id 714BE262A46; Thu,  6 Mar 2003 00:35:14 +0100 (CET)
From: "Per Hansen" <perflemming@hansen.mail.dk>
To: <zinin@psg.com>, <ppvpn@nortelnetworks.com>, <sob@harvard.edu>,
        <mpls@UU.NET>
Subject: VPLS and martini Ethernet encapsulation via MPLS and control word
Date: Thu, 6 Mar 2003 00:26:21 +0100
Message-ID: <000001c2e36e$a20d8d20$0601a8c0@oemcomputer>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0001_01C2E377.03D1F520"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-mpls@UU.NET
Precedence: bulk

Dette er en flerdels meddelelse i MIME-format.

------=_NextPart_000_0001_01C2E377.03D1F520
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

There seem to be a need for a technical check of whether the following
will fly
Together:
=20
    1) VPLS    (virtual Ethernet switching via MPLS)
    2) Martini Encapsulation of Ethernet packets via MPLS as
pseudo-wire.
    3) Flat MPLS room in an MPLS switch and MPLS/VPLS switch.=20
         (label room per switch, instead of per port).
=20
Do any have comments on this ?.
=20
Argument:
Martini Encapsulation specify both a tunnel MPLS label and a VC MPLS
label, where
The VC label default value is 5 for Ethernet packets. The last 5 value
(or more correct that
If the VC label value is the same for different martini tunnels), seem
potential to be
an implementation issue for martini tunnels if many of them needs to be
terminated
in a VPLS/MPLS switch with a flat MPLS room. =20
=20
Should it be stated somewhere, that the martiny VC label needs to be
different in an VPLS/MPLS
Switch with a flat MPLS room, or is this already clear enough ?.
=20
Furthermore martini encapsulation of Ethernet packets over MPLS also
introduce an control word, which is optional, and which is not a label.
Should it be stated somewhere, that remote ends,
Should be able not to send this to a VPLS/MPLS switch which terminate
the martini tunnel =96 or
Should it be stated that it is a requirement that a VPLS/MPLS switch
shall be configurable on
Each pseudo-wire with whether a  control word in the martini
encapsulation is included or not ?
=20
=20
------=_NextPart_000_0001_01C2E377.03D1F520--


From owner-mpls@UU.NET  Thu Mar  6 10:56:15 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22185
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 10:56:15 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewd18622
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 15:58:16 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewd17488;
	Thu, 6 Mar 2003 15:57:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoewb14936
	for mpls-outgoing; Thu, 6 Mar 2003 15:15:52 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoewb14928
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 15:15:40 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoewb18219
	for <mpls@uu.net>; Thu, 6 Mar 2003 15:15:10 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewb09059
	for <mpls@uu.net>; Thu, 6 Mar 2003 15:15:09 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoewb08922
	for <mpls@uu.net>; Thu, 6 Mar 2003 15:15:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h26FF2ws018568
	for <mpls@uu.net>; Thu, 6 Mar 2003 10:15:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA26440 for <mpls@uu.net>; Thu, 6 Mar 2003 10:15:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h26FF2i05186 for mpls@uu.net; Thu, 6 Mar 2003 10:15:02 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoewa14266
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 15:13:05 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoewa20709
	for <mpls@UU.NET>; Thu, 6 Mar 2003 15:10:36 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewa27388
	for <mpls@UU.NET>; Thu, 6 Mar 2003 15:10:36 GMT
Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13])
	id QQoewa27372
	for <mpls@UU.NET>; Thu, 6 Mar 2003 15:10:35 GMT
Received: (qmail 17707 invoked by uid 104); 6 Mar 2003 15:10:34 -0000
Received: from Shahram_Davari@pmc-sierra.com by father by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4251.  Clear:. 
 Processed in 1.240018 secs); 06 Mar 2003 15:10:34 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by father.pmc-sierra.bc.ca with SMTP; 6 Mar 2003 15:10:32 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h26FASh19950;
	Thu, 6 Mar 2003 07:10:28 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <DCP4HV25>; Thu, 6 Mar 2003 07:10:28 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03D69@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>
Cc: Alex Zinin <zinin@psg.com>,
        "'Mark.Jones@mail.sprint.com'"
	 <Mark.Jones@mail.sprint.com>,
        ccamp@ops.ietf.org, mpls@UU.NET
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
Date: Thu, 6 Mar 2003 07:10:19 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

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


>
>> -Shahram
>
>Curtis
>
>
>> >-----Original Message-----
>> >From: Curtis Villamizar [mailto:curtis@fictitious.org]
>> >Sent: Wednesday, March 05, 2003 5:34 PM
>> >To: Shahram Davari
>> >Cc: 'curtis@fictitious.org'; Alex Zinin; 
>'Mark.Jones@mail.sprint.com';
>> >ccamp@ops.ietf.org; mpls@UU.NET
>> >Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
>> >
>> >
>> >
>> >In message 
>> ><4B6D09F3B826D411A67300D0B706EFDEB03D65@nt-exch-yow.pmc-sierra.bc.ca
>> >>, 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
>> >
>> >
>> >> >-----Original Message-----
>> >> >From: Curtis Villamizar [mailto:curtis@fictitious.org]
>> >> >Sent: Wednesday, March 05, 2003 4:53 PM
>> >> >To: Alex Zinin
>> >> >Cc: Shahram Davari; 'Mark.Jones@mail.sprint.com'; 
>> >ccamp@ops.ietf.org;
>> >> >mpls@UU.NET
>> >> >Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
>> >> >
>> >> >
>> >> >
>> >> >In message <18057706577.20030305113734@psg.com>, Alex 
>Zinin writes:
>> >> >> Wednesday, March 5, 2003, 11:12:10 AM, Shahram Davari wrote:
>> >> >> [...]
>> >> >> > 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.
>> >> >> 
>> >> >> Ouch... draft-iesg-vendor-extensions-00.txt
>> >> >> 
>> >> >> Alex
>> >> >
>> >> >
>> >> >Looks like the IESG doesn't agree with Shahram on this.
>> >> >
>> >> >Curtis
>> >> >
>> >> 
>> >
>> 
>



From owner-mpls@UU.NET  Thu Mar  6 11:16:20 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24346
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 11:16:20 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewf28099
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 16:18:23 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewf27387;
	Thu, 6 Mar 2003 16:17:59 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoewb15668
	for mpls-outgoing; Thu, 6 Mar 2003 15:23:00 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoewb15653
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 15:22:58 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoewb18791
	for <mpls@uu.net>; Thu, 6 Mar 2003 15:21:46 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewb17913
	for <mpls@uu.net>; Thu, 6 Mar 2003 15:21:45 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoewb17901
	for <mpls@uu.net>; Thu, 6 Mar 2003 15:21:45 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h26FLbkD026349
	for <mpls@uu.net>; Thu, 6 Mar 2003 10:21:37 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA26997 for <mpls@uu.net>; Thu, 6 Mar 2003 10:21:37 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h26FLb906272 for mpls@uu.net; Thu, 6 Mar 2003 10:21:37 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoewa14654
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 15:14:51 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoewa18345
	for <mpls@UU.NET>; Thu, 6 Mar 2003 15:14:39 GMT
From: Mark.Jones@mail.sprint.com
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewa01118
	for <mpls@UU.NET>; Thu, 6 Mar 2003 15:14:39 GMT
Received: from damgwp01.corp.sprint.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: parker2.sprint.com [199.14.91.106])
	id QQoewa01107
	for <mpls@UU.NET>; Thu, 6 Mar 2003 15:14:38 GMT
Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93])
	by damgwp01.corp.sprint.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h26FOHI19787;
	Thu, 6 Mar 2003 09:24:17 -0600 (CST)
Received: from kcopmp04.corp.sprint.com (kcopmp04m [10.79.2.196])
	by kcmgwp02.corp.sprint.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id h26FEPH07510;
	Thu, 6 Mar 2003 09:14:25 -0600 (CST)
Received: from localhost (root@localhost)
	by kcopmp04.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id JAA10154;
	Thu, 6 Mar 2003 09:14:23 -0600 (CST)
X-OpenMail-Hops: 1
Date: Thu, 6 Mar 2003 09:14:23 -0600
Message-Id: <H00017a81fd38c71.1046963662.kcopmp04@MHS>
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
MIME-Version: 1.0
TO: dwfedyk@nortelnetworks.com, gash@att.com
CC: ccamp@ops.ietf.org, mpls@UU.NET
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline; filename="BDY.TXT"
	;Creation-Date="Thu, 6 Mar 2003 09:14:23 -0600"
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

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
Optical Transport and Networking
Sprint - Wireline Technology Development
913-794-2139
 

-----Original Message-----
From: dwfedyk [mailto:dwfedyk@nortelnetworks.com]
Sent: Thursday, March 06, 2003 7:49 AM
To: gash
Cc: mpls; ccamp
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt


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 owner-mpls@UU.NET  Thu Mar  6 11:29:28 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25127
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 11:29:28 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewg02212
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 16:31:31 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewg01316;
	Thu, 6 Mar 2003 16:31:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoewc16442
	for mpls-outgoing; Thu, 6 Mar 2003 15:31:31 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoewc16426
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 15:31:20 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoewc27033
	for <mpls@uu.net>; Thu, 6 Mar 2003 15:31:07 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewc03217
	for <mpls@uu.net>; Thu, 6 Mar 2003 15:31:06 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoewc03192
	for <mpls@uu.net>; Thu, 6 Mar 2003 15:31:06 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h26FV3kD028806
	for <mpls@uu.net>; Thu, 6 Mar 2003 10:31:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA27838 for <mpls@uu.net>; Thu, 6 Mar 2003 10:31:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h26FV2a08215 for mpls@uu.net; Thu, 6 Mar 2003 10:31:02 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoewb16040
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 15:26:39 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoewb02548
	for <mpls@UU.NET>; Thu, 6 Mar 2003 15:26:09 GMT
From: Mark.Jones@mail.sprint.com
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewb26194
	for <mpls@UU.NET>; Thu, 6 Mar 2003 15:26:08 GMT
Received: from damgwp01.corp.sprint.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: parker2.sprint.com [199.14.91.106])
	id QQoewb26164
	for <mpls@UU.NET>; Thu, 6 Mar 2003 15:26:07 GMT
Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93])
	by damgwp01.corp.sprint.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h26FZjI00635;
	Thu, 6 Mar 2003 09:35:45 -0600 (CST)
Received: from kcopmp04.corp.sprint.com (kcopmp04m [10.79.2.196])
	by kcmgwp02.corp.sprint.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id h26FPpH25671;
	Thu, 6 Mar 2003 09:25:53 -0600 (CST)
Received: from localhost (root@localhost)
	by kcopmp04.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id JAA19334;
	Thu, 6 Mar 2003 09:25:10 -0600 (CST)
X-OpenMail-Hops: 1
Date: Thu, 6 Mar 2003 09:25:10 -0600
Message-Id: <H00017a81fd38c75.1046964310.kcopmp04@MHS>
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
MIME-Version: 1.0
TO: curtis@fictitious.org, Shahram_Davari@pmc-sierra.com
CC: ccamp@ops.ietf.org, mpls@UU.NET, zinin@psg.com
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline; filename="BDY.TXT"
	;Creation-Date="Thu, 6 Mar 2003 09:25:10 -0600"
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

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
Optical Transport and Networking
Sprint - Wireline Technology Development
913-794-2139
 

-----Original Message-----
From: Shahram.Davari [mailto:Shahram_Davari@pmc-sierra.com]
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


>
>> -Shahram
>
>Curtis
>
>
>> >-----Original Message-----
>> >From: Curtis Villamizar [mailto:curtis@fictitious.org]
>> >Sent: Wednesday, March 05, 2003 5:34 PM
>> >To: Shahram Davari
>> >Cc: 'curtis@fictitious.org'; Alex Zinin; 
>'Mark.Jones@mail.sprint.com';
>> >ccamp@ops.ietf.org; mpls@UU.NET
>> >Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
>> >
>> >
>> >
>> >In message 
>> ><4B6D09F3B826D411A67300D0B706EFDEB03D65@nt-exch-yow.pmc-sierra.bc.ca
>> >>, 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
>> >
>> >
>> >> >-----Original Message-----
>> >> >From: Curtis Villamizar [mailto:curtis@fictitious.org]
>> >> >Sent: Wednesday, March 05, 2003 4:53 PM
>> >> >To: Alex Zinin
>> >> >Cc: Shahram Davari; 'Mark.Jones@mail.sprint.com'; 
>> >ccamp@ops.ietf.org;
>> >> >mpls@UU.NET
>> >> >Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
>> >> >
>> >> >
>> >> >
>> >> >In message <18057706577.20030305113734@psg.com>, Alex 
>Zinin writes:
>> >> >> Wednesday, March 5, 2003, 11:12:10 AM, Shahram Davari wrote:
>> >> >> [...]
>> >> >> > 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.
>> >> >> 
>> >> >> Ouch... draft-iesg-vendor-extensions-00.txt
>> >> >> 
>> >> >> Alex
>> >> >
>> >> >
>> >> >Looks like the IESG doesn't agree with Shahram on this.
>> >> >
>> >> >Curtis
>> >> >
>> >> 
>> >
>> 
>



From owner-mpls@UU.NET  Thu Mar  6 11:41:36 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26125
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 11:41:35 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewg12932
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 16:43:38 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewg12613;
	Thu, 6 Mar 2003 16:43:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoewc17091
	for mpls-outgoing; Thu, 6 Mar 2003 15:40:23 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoewc17072
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 15:40:17 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoewc29468
	for <mpls@uu.net>; Thu, 6 Mar 2003 15:40:14 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewc17746
	for <mpls@uu.net>; Thu, 6 Mar 2003 15:40:13 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoewc17739
	for <mpls@uu.net>; Thu, 6 Mar 2003 15:40:13 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h26FeAws021935
	for <mpls@uu.net>; Thu, 6 Mar 2003 10:40:10 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA28714 for <mpls@uu.net>; Thu, 6 Mar 2003 10:40:09 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h26Fe9a10456 for mpls@uu.net; Thu, 6 Mar 2003 10:40:09 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoewc16986
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 15:38:19 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoewc20609
	for <mpls@UU.NET>; Thu, 6 Mar 2003 15:38:01 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewc13050
	for <mpls@UU.NET>; Thu, 6 Mar 2003 15:38:00 GMT
Received: from sj-core-5-cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-core-5.cisco.com [171.71.177.238])
	id QQoewc13032
	for <mpls@UU.NET>; Thu, 6 Mar 2003 15:38:00 GMT
Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34])
	by sj-core-5-cisco.com (8.12.6/8.12.6) with ESMTP id h26FbtP8028695;
	Thu, 6 Mar 2003 07:37:56 -0800 (PST)
Received: from cisco.com (sjc-vpn3-502.cisco.com [10.21.65.246])
	by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA)
	with SMTP id AEO02007;
	Thu, 6 Mar 2003 07:20:00 -0800 (PST)
Received: by cisco.com (sSMTP sendmail emulation); Thu, 6 Mar 2003 10:37:53 -0500
Date: Thu, 6 Mar 2003 10:37:53 -0500
From: "'Scott W Brim'" <sbrim@cisco.com>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
Cc: ccamp@ops.ietf.org, mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Message-ID: <20030306153753.GE2208@sbrim-w2k>
Mail-Followup-To: 'Scott W Brim' <sbrim@cisco.com>,
	Shahram Davari <Shahram_Davari@pmc-sierra.com>, ccamp@ops.ietf.org,
	mpls@UU.NET
References: <4B6D09F3B826D411A67300D0B706EFDEB03D61@nt-exch-yow.pmc-sierra.bc.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03D61@nt-exch-yow.pmc-sierra.bc.ca>
User-Agent: Mutt/1.4i
Sender: owner-mpls@UU.NET
Precedence: bulk

On Wed, Mar 05, 2003 11:54:34AM -0800, Shahram Davari allegedly wrote:
> >> > 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.
> >> 
> >> Ouch... draft-iesg-vendor-extensions-00.txt
> >
> >But that doesn't solve the problem.  There are some protocol
> >requirements that can't be met just by extra semantics.
> >
> 
> Could you please give an example. 

Obviously, something that involves extensions to the protocol machinery.  



From owner-mpls@UU.NET  Thu Mar  6 11:53:52 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27963
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 11:53:51 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewh04041
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 16:55:54 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewh03308;
	Thu, 6 Mar 2003 16:55:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoewd18221
	for mpls-outgoing; Thu, 6 Mar 2003 15:49:23 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoewd18198
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 15:49:13 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoewd19677
	for <mpls@UU.NET>; Thu, 6 Mar 2003 15:48:49 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewd27656
	for <mpls@UU.NET>; Thu, 6 Mar 2003 15:48:49 GMT
Received: from newdev.harvard.edu by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: newdev.eecs.harvard.edu [140.247.60.212])
	id QQoewd27632
	for <mpls@UU.NET>; Thu, 6 Mar 2003 15:48:48 GMT
Received: from newdev.harvard.edu (localhost [127.0.0.1])
	by newdev.harvard.edu (8.12.7/8.12.2) with ESMTP id h26FmYe3024429;
	Thu, 6 Mar 2003 10:48:34 -0500 (EST)
Received: (from sob@localhost)
	by newdev.harvard.edu (8.12.7/8.12.2/Submit) id h26FmYdx024428;
	Thu, 6 Mar 2003 10:48:34 -0500 (EST)
Date: Thu, 6 Mar 2003 10:48:34 -0500 (EST)
From: Scott  Bradner <sob@harvard.edu>
Message-Id: <200303061548.h26FmYdx024428@newdev.harvard.edu>
To: curtis@fictitious.org, Shahram_Davari@pmc-sierra.com
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Cc: ccamp@ops.ietf.org, Mark.Jones@mail.sprint.com, mpls@UU.NET, zinin@psg.com
In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03D69@nt-exch-yow.pmc-sierra.bc.ca>
Sender: owner-mpls@UU.NET
Precedence: bulk

> 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 owner-mpls@UU.NET  Thu Mar  6 12:03:46 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28739
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 12:03:46 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewi18666
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 17:05:49 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewi18253;
	Thu, 6 Mar 2003 17:05:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoewe24503
	for mpls-outgoing; Thu, 6 Mar 2003 16:01:23 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoewe24446
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 16:01:21 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoewe24322
	for <mpls@uu.net>; Thu, 6 Mar 2003 16:00:09 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewe21199
	for <mpls@uu.net>; Thu, 6 Mar 2003 16:00:09 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoewe21182
	for <mpls@uu.net>; Thu, 6 Mar 2003 16:00:08 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h26G06kD005245
	for <mpls@uu.net>; Thu, 6 Mar 2003 11:00:06 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA00522 for <mpls@uu.net>; Thu, 6 Mar 2003 11:00:05 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h26G05A14704 for mpls@uu.net; Thu, 6 Mar 2003 11:00:05 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoewd18652
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 15:56:58 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoewd08677
	for <mpls@UU.NET>; Thu, 6 Mar 2003 15:56:43 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewd07059
	for <mpls@UU.NET>; Thu, 6 Mar 2003 15:56:42 GMT
Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoewd07040
	for <mpls@UU.NET>; Thu, 6 Mar 2003 15:56:41 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id KAA34859;
	Thu, 6 Mar 2003 10:53:46 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303061553.KAA34859@workhorse.fictitious.org>
To: John Drake <jdrake@calient.net>
cc: "'Yangguang Xu'" <xuyg@lucent.com>, Dimitri.Papadimitriou@alcatel.be,
        Zhi-Wei Lin <zwlin@comcast.net>, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
In-reply-to: Your message of "Wed, 05 Mar 2003 16:09:41 PST."
             <9D42C6E086250248810DCADA39CE7EFC9722BB@nimbus> 
Date: Thu, 06 Mar 2003 10:53:46 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <9D42C6E086250248810DCADA39CE7EFC9722BB@nimbus>, John Drake writes:
> 
> 
> > -----Original Message-----
> > From: Yangguang Xu [mailto:xuyg@lucent.com]
> > Sent: Wednesday, March 05, 2003 2:55 PM
> > To: Dimitri.Papadimitriou@alcatel.be; Zhi-Wei Lin
> > Cc: mpls@UU.NET
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > 
> > 
> > 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 owner-mpls@UU.NET  Thu Mar  6 12:19:53 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00443
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 12:19:53 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewj18659
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 17:21:56 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewj17657;
	Thu, 6 Mar 2003 17:21:30 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoewf09028
	for mpls-outgoing; Thu, 6 Mar 2003 16:27:37 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoewf09003
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 16:27:31 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoewf11396
	for <mpls@uu.net>; Thu, 6 Mar 2003 16:26:17 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewf21347
	for <mpls@uu.net>; Thu, 6 Mar 2003 16:26:16 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoewf21128
	for <mpls@uu.net>; Thu, 6 Mar 2003 16:26:11 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h26GQ5kD011543
	for <mpls@uu.net>; Thu, 6 Mar 2003 11:26:05 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA02706 for <mpls@uu.net>; Thu, 6 Mar 2003 11:26:04 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h26GQ4420189 for mpls@uu.net; Thu, 6 Mar 2003 11:26:04 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoewf08589
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 16:23:34 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoewf08918
	for <mpls@UU.NET>; Thu, 6 Mar 2003 16:23:32 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewf15665
	for <mpls@UU.NET>; Thu, 6 Mar 2003 16:23:31 GMT
Received: from father.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13])
	id QQoewf15646
	for <mpls@UU.NET>; Thu, 6 Mar 2003 16:23:30 GMT
Received: (qmail 14275 invoked by uid 104); 6 Mar 2003 16:23:20 -0000
Received: from Shahram_Davari@pmc-sierra.com by father by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4251.  Clear:. 
 Processed in 0.601461 secs); 06 Mar 2003 16:23:20 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by father.pmc-sierra.bc.ca with SMTP; 6 Mar 2003 16:23:18 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h26GNIh19013;
	Thu, 6 Mar 2003 08:23:18 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <DCP4HWTW>; Thu, 6 Mar 2003 08:23:18 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03D6B@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Scott  Bradner'" <sob@harvard.edu>, curtis@fictitious.org
Cc: ccamp@ops.ietf.org, Mark.Jones@mail.sprint.com, mpls@UU.NET, zinin@psg.com
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Thu, 6 Mar 2003 08:23:11 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Scott,

What is the best mailing list to discuss this draft?

-Shahram

>-----Original Message-----
>From: Scott Bradner [mailto:sob@harvard.edu]
>Sent: Thursday, March 06, 2003 10:49 AM
>To: curtis@fictitious.org; Shahram Davari
>Cc: ccamp@ops.ietf.org; Mark.Jones@mail.sprint.com; mpls@UU.NET;
>zinin@psg.com
>Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
>
>> 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 owner-mpls@UU.NET  Thu Mar  6 12:22:55 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00727
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 12:22:55 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewj19683
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 17:25:00 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewj19197;
	Thu, 6 Mar 2003 17:24:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoewg09423
	for mpls-outgoing; Thu, 6 Mar 2003 16:31:07 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoewg09342
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 16:31:03 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoewf05233
	for <mpls@UU.NET>; Thu, 6 Mar 2003 16:29:34 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewf21692
	for <mpls@UU.NET>; Thu, 6 Mar 2003 16:29:34 GMT
Received: from hoemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail1.lucent.com [192.11.226.161])
	id QQoewf21679
	for <mpls@UU.NET>; Thu, 6 Mar 2003 16:29:34 GMT
Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58])
	by hoemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26GTVL15388;
	Thu, 6 Mar 2003 11:29:31 -0500 (EST)
Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.58.32]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id LAA11020; Thu, 6 Mar 2003 11:29:30 -0500 (EST)
Message-ID: <3E67776A.1EAABAE@lucent.com>
Date: Thu, 06 Mar 2003 11:29:30 -0500
From: Yangguang Xu <xuyg@lucent.com>
Organization: Lucent Technologies, Inc.
X-Mailer: Mozilla 4.7 [en]C-EMS-1.4  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Mark.Jones@mail.sprint.com
CC: dwfedyk@nortelnetworks.com, gash@att.com, ccamp@ops.ietf.org, mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <H00017a81fd38c71.1046963662.kcopmp04@MHS>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

You are right on the point!

Mark.Jones@mail.sprint.com 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
> 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
> Optical Transport and Networking
> Sprint - Wireline Technology Development
> 913-794-2139
> 
> 
> -----Original Message-----
> From: dwfedyk [mailto:dwfedyk@nortelnetworks.com]
> Sent: Thursday, March 06, 2003 7:49 AM
> To: gash
> Cc: mpls; ccamp
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 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 owner-mpls@UU.NET  Thu Mar  6 12:36:18 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01928
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 12:36:18 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewk13002
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 17:38:22 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewk10844;
	Thu, 6 Mar 2003 17:37:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoewg10410
	for mpls-outgoing; Thu, 6 Mar 2003 16:43:17 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoewg10404
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 16:43:06 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoewg13130
	for <mpls@uu.net>; Thu, 6 Mar 2003 16:41:18 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewg14527
	for <mpls@uu.net>; Thu, 6 Mar 2003 16:41:18 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoewg14519
	for <mpls@uu.net>; Thu, 6 Mar 2003 16:41:17 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h26Gf9kD014938
	for <mpls@uu.net>; Thu, 6 Mar 2003 11:41:10 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA03975 for <mpls@uu.net>; Thu, 6 Mar 2003 11:41:09 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h26Gf9723745 for mpls@uu.net; Thu, 6 Mar 2003 11:41:09 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoewg10090
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 16:39:08 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoewg12594
	for <mpls@UU.NET>; Thu, 6 Mar 2003 16:38:32 GMT
From: Mark.Jones@mail.sprint.com
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewg06680
	for <mpls@UU.NET>; Thu, 6 Mar 2003 16:38:32 GMT
Received: from kcmgwp01.corp.sprint.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: parker1.sprint.com [208.18.122.165])
	id QQoewg06667
	for <mpls@UU.NET>; Thu, 6 Mar 2003 16:38:32 GMT
Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93])
	by kcmgwp01.corp.sprint.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h26GcKu22424;
	Thu, 6 Mar 2003 10:38:20 -0600 (CST)
Received: from kcopmp04.corp.sprint.com (kcopmp04m [10.79.2.196])
	by kcmgwp02.corp.sprint.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id h26GcHH03314;
	Thu, 6 Mar 2003 10:38:18 -0600 (CST)
Received: from localhost (root@localhost)
	by kcopmp04.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id KAA17314;
	Thu, 6 Mar 2003 10:38:15 -0600 (CST)
X-OpenMail-Hops: 1
Date: Thu, 6 Mar 2003 10:38:14 -0600
Message-Id: <H00017a81fd4100a.1046968694.kcopmp04@MHS>
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
MIME-Version: 1.0
TO: Gert.Grammel@alcatel.de
CC: ccamp@ops.ietf.org, dwfedyk@nortelnetworks.com, gash@att.com, mpls@UU.NET
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline; filename="BDY.TXT"
	;Creation-Date="Thu, 6 Mar 2003 10:38:14 -0600"
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

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
Optical Transport and Networking
Sprint - Wireline Technology Development
913-794-2139
 

-----Original Message-----
From: Gert.Grammel [mailto:Gert.Grammel@alcatel.de]
Sent: Thursday, March 06, 2003 10:17 AM
To: Mark.Jones
Cc: dwfedyk; gash; ccamp; mpls
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt


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

Mark.Jones@mail.sprint.com 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
> 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
> Optical Transport and Networking
> Sprint - Wireline Technology Development
> 913-794-2139
>
>
> -----Original Message-----
> From: dwfedyk [mailto:dwfedyk@nortelnetworks.com]
> Sent: Thursday, March 06, 2003 7:49 AM
> To: gash
> Cc: mpls; ccamp
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> 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

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de





From owner-mpls@UU.NET  Thu Mar  6 13:49:21 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05998
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 13:49:21 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewp00181
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 18:51:25 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewp29651;
	Thu, 6 Mar 2003 18:51:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoewj02825
	for mpls-outgoing; Thu, 6 Mar 2003 17:23:37 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoewj02807
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 17:23:23 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoewj08483
	for <mpls@UU.NET>; Thu, 6 Mar 2003 17:23:12 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewj21324
	for <mpls@UU.NET>; Thu, 6 Mar 2003 17:23:11 GMT
Received: from newdev.harvard.edu by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: newdev.eecs.harvard.edu [140.247.60.212])
	id QQoewj21261
	for <mpls@UU.NET>; Thu, 6 Mar 2003 17:23:10 GMT
Received: from newdev.harvard.edu (localhost [127.0.0.1])
	by newdev.harvard.edu (8.12.7/8.12.2) with ESMTP id h26HLre3025205;
	Thu, 6 Mar 2003 12:21:53 -0500 (EST)
Received: (from sob@localhost)
	by newdev.harvard.edu (8.12.7/8.12.2/Submit) id h26HLrEc025204;
	Thu, 6 Mar 2003 12:21:53 -0500 (EST)
Date: Thu, 6 Mar 2003 12:21:53 -0500 (EST)
From: Scott  Bradner <sob@harvard.edu>
Message-Id: <200303061721.h26HLrEc025204@newdev.harvard.edu>
To: bwijnen@lucent.com, kireeti@juniper.net
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Cc: ccamp@ops.ietf.org, mpls@UU.NET, sbrim@cisco.com
In-Reply-To: <20030227005743.X28581@kummer.juniper.net>
Sender: owner-mpls@UU.NET
Precedence: bulk

> 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 owner-mpls@UU.NET  Thu Mar  6 13:53:30 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06225
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 13:53:29 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewp11908
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 18:55:34 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewp11359;
	Thu, 6 Mar 2003 18:55:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoewj02957
	for mpls-outgoing; Thu, 6 Mar 2003 17:25:57 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoewj02950
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 17:25:51 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoewj02546
	for <mpls@UU.NET>; Thu, 6 Mar 2003 17:25:37 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewj26916
	for <mpls@UU.NET>; Thu, 6 Mar 2003 17:25:37 GMT
Received: from newdev.harvard.edu by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: newdev.eecs.harvard.edu [140.247.60.212])
	id QQoewj26831
	for <mpls@UU.NET>; Thu, 6 Mar 2003 17:25:36 GMT
Received: from newdev.harvard.edu (localhost [127.0.0.1])
	by newdev.harvard.edu (8.12.7/8.12.2) with ESMTP id h26HOme3025237;
	Thu, 6 Mar 2003 12:24:48 -0500 (EST)
Received: (from sob@localhost)
	by newdev.harvard.edu (8.12.7/8.12.2/Submit) id h26HOmxE025236;
	Thu, 6 Mar 2003 12:24:48 -0500 (EST)
Date: Thu, 6 Mar 2003 12:24:48 -0500 (EST)
From: Scott  Bradner <sob@harvard.edu>
Message-Id: <200303061724.h26HOmxE025236@newdev.harvard.edu>
To: bwijnen@lucent.com, sbrim@cisco.com
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Cc: ccamp@ops.ietf.org, mpls@UU.NET
In-Reply-To: <20030227131336.GK2572@sbrim-w2k>
Sender: owner-mpls@UU.NET
Precedence: bulk

> 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 owner-mpls@UU.NET  Thu Mar  6 14:14:42 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07180
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 14:14:42 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewr22800
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 19:16:47 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewr22205;
	Thu, 6 Mar 2003 19:16:30 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoewl04815
	for mpls-outgoing; Thu, 6 Mar 2003 17:46:38 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoewl04808
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 17:46:35 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoewl14359
	for <mpls@UU.NET>; Thu, 6 Mar 2003 17:45:47 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewl05040
	for <mpls@UU.NET>; Thu, 6 Mar 2003 17:45:46 GMT
Received: from lightwave.chromisys.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: lightwave.chromisys.com [63.102.55.206])
	id QQoewl05022
	for <mpls@UU.NET>; Thu, 6 Mar 2003 17:45:45 GMT
Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19)
	id <4GJZGSFD>; Thu, 6 Mar 2003 09:45:40 -0800
Message-ID: <9D42C6E086250248810DCADA39CE7EFC9722BE@nimbus>
From: John Drake <jdrake@calient.net>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>
Cc: "'Yangguang Xu'" <xuyg@lucent.com>, Dimitri.Papadimitriou@alcatel.be,
        Zhi-Wei Lin <zwlin@comcast.net>, mpls@UU.NET
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
Date: Thu, 6 Mar 2003 09:45:31 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

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

> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@fictitious.org]
> Sent: Thursday, March 06, 2003 7:54 AM
> To: John Drake
> Cc: 'Yangguang Xu'; Dimitri.Papadimitriou@alcatel.be; Zhi-Wei Lin;
> mpls@UU.NET
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
> 
> 
> 
> In message <9D42C6E086250248810DCADA39CE7EFC9722BB@nimbus>, 
> John Drake writes:
> > 
> > 
> > > -----Original Message-----
> > > From: Yangguang Xu [mailto:xuyg@lucent.com]
> > > Sent: Wednesday, March 05, 2003 2:55 PM
> > > To: Dimitri.Papadimitriou@alcatel.be; Zhi-Wei Lin
> > > Cc: mpls@UU.NET
> > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > > 
> > > 
> > > 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 owner-mpls@UU.NET  Thu Mar  6 14:16:02 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07244
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 14:16:02 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewr25915
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 19:18:07 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewr24918;
	Thu, 6 Mar 2003 19:17:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoewl04933
	for mpls-outgoing; Thu, 6 Mar 2003 17:48:28 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoewl04904
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 17:48:02 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoewl08737
	for <mpls@UU.NET>; Thu, 6 Mar 2003 17:47:42 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewl06453
	for <mpls@UU.NET>; Thu, 6 Mar 2003 17:47:41 GMT
Received: from lightwave.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: lightwave.chromisys.com [63.102.55.206])
	id QQoewl06325
	for <mpls@UU.NET>; Thu, 6 Mar 2003 17:47:38 GMT
Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19)
	id <4GJZGSF2>; Thu, 6 Mar 2003 09:47:30 -0800
Message-ID: <9D42C6E086250248810DCADA39CE7EFC9722BF@nimbus>
From: John Drake <jdrake@calient.net>
To: "'Zhi-Wei Lin'" <zwlin@comcast.net>, mpls@UU.NET
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Thu, 6 Mar 2003 09:47:24 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

I think the point was that one would not be able to establish an LSP on a
path containing both ASON and GMPLS networks

> -----Original Message-----
> From: Zhi-Wei Lin [mailto:zwlin@comcast.net]
> Sent: Wednesday, March 05, 2003 6:43 PM
> To: mpls@UU.NET
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> Hi John, Dimitri,
> 
> I guess this is another misconception? How an operator will 
> use this, the
> operator already knows. This means that if an operator is 
> going to offer
> ASON service then they will be expecting their customers to 
> come in with
> ASON capable requests. However, if operator is also at the same time
> offering GMPLS service, that's fine as well because they will 
> be expecting
> to see a GMPLS request.
> 
> There is nowhere that says that an operator must only support ASON and
> nothing else. What is said is that if an operator is offering 
> ASON service
> and not GMPLS, then the request has to come in with an ASON 
> request. I think
> this makes sense since the operator has chosen only to 
> support that model.
> Alternatively the operator can choose to support both models, 
> or only GMPLS
> models.
> 
> Hope this explains...
> 
> Zhi
> 
> 
> 
> ----- Original Message -----
> From: "John Drake" <jdrake@calient.net>
> To: <Dimitri.Papadimitriou@alcatel.be>; "Zhi-Wei Lin" 
> <zwlin@comcast.net>
> Cc: <mpls@UU.NET>
> Sent: Wednesday, March 05, 2003 5:28 PM
> Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> > Snipped...
> >
> > > -----Original Message-----
> > > From: Dimitri.Papadimitriou@alcatel.be
> > > [mailto:Dimitri.Papadimitriou@alcatel.be]
> > > Sent: Wednesday, March 05, 2003 1:39 PM
> > > To: Zhi-Wei Lin
> > > Cc: mpls@UU.NET
> > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > > 3) you say in this "Note that although the CALL_ID object 
> is optional
> > > for GMPLS
> > >    signaling, this object is mandatory for ASON-compliant 
> networks,
> > >    i.e., the Resv message MUST include the CALL_ID object."
> > >    so if you mandate it's usage at edges, following this 
> an operator
> > >    that doesn't implement these extensions is not capable 
> to setup an
> > >    lsp through an ason network... this is a major problem 
> in case edge
> > >    devices are lsr's that will be for most of them gmpls compliant
> > >
> >
> > JD:  There is the same issue wrt Generalized UNI
> 


From owner-mpls@UU.NET  Thu Mar  6 14:17:01 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07282
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 14:17:01 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewr27989
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 19:19:05 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewr26981;
	Thu, 6 Mar 2003 19:18:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoewl04872
	for mpls-outgoing; Thu, 6 Mar 2003 17:47:31 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoewl04832
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 17:47:12 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoewl04229
	for <mpls@uu.net>; Thu, 6 Mar 2003 17:46:39 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewl06529
	for <mpls@uu.net>; Thu, 6 Mar 2003 17:46:39 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoewl06509
	for <mpls@uu.net>; Thu, 6 Mar 2003 17:46:38 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h26HkUkD028964
	for <mpls@uu.net>; Thu, 6 Mar 2003 12:46:30 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA09763 for <mpls@uu.net>; Thu, 6 Mar 2003 12:46:30 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h26HkUR05836 for mpls@uu.net; Thu, 6 Mar 2003 12:46:30 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoewf08172
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 16:18:48 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoewf20109
	for <mpls@uu.net>; Thu, 6 Mar 2003 16:18:32 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewf28283
	for <mpls@uu.net>; Thu, 6 Mar 2003 16:18:32 GMT
Received: from mailrelay1.alcatel.de by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailrelay2.alcatel.de [194.113.59.71])
	id QQoewf28268
	for <mpls@uu.net>; Thu, 6 Mar 2003 16:18:31 GMT
Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10])
	by mailrelay1.alcatel.de (8.9.3/8.9.3) with ESMTP id RAA09495;
	Thu, 6 Mar 2003 17:16:55 +0100 (MET)
Received: from slsv7at ([149.204.245.107] helo=slsv7a.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 18qy3d-0006RH-00; Thu, 06 Mar 2003 17:17:21 +0100
Received: from sls3on.stgl.sel.alcatel.de ([149.204.30.251] helo=alcatel.de) by slsv7a.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 18qy3d-0004tY-00; Thu, 06 Mar 2003 17:17:21 +0100
Message-ID: <3E677482.2963B70F@alcatel.de>
Date: Thu, 06 Mar 2003 17:17:06 +0100
From: Gert Grammel <Gert.Grammel@alcatel.de>
Organization: Alcatel TND Product Strategy
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en,de
MIME-Version: 1.0
To: Mark.Jones@mail.sprint.com
CC: dwfedyk@nortelnetworks.com, gash@att.com, ccamp@ops.ietf.org, mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <H00017a81fd38c71.1046963662.kcopmp04@MHS>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

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

Mark.Jones@mail.sprint.com 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
> 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
> Optical Transport and Networking
> Sprint - Wireline Technology Development
> 913-794-2139
>
>
> -----Original Message-----
> From: dwfedyk [mailto:dwfedyk@nortelnetworks.com]
> Sent: Thursday, March 06, 2003 7:49 AM
> To: gash
> Cc: mpls; ccamp
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> 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

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de




From owner-mpls@UU.NET  Thu Mar  6 14:17:50 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07348
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 14:17:50 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewr29747
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 19:19:55 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewr29053;
	Thu, 6 Mar 2003 19:19:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoewl04866
	for mpls-outgoing; Thu, 6 Mar 2003 17:47:28 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoewl04831
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 17:47:11 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoewl03359
	for <mpls@UU.NET>; Thu, 6 Mar 2003 17:46:27 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewl18036
	for <mpls@UU.NET>; Thu, 6 Mar 2003 17:46:26 GMT
Received: from bt0g2p.god.bel.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alc136.alcatel.be [195.207.101.136])
	id QQoewl17999
	for <mpls@UU.NET>; Thu, 6 Mar 2003 17:46:25 GMT
Received: from bemail05.net.alcatel.be (relay3 [127.0.0.1])
	by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id h26HkI207521;
	Thu, 6 Mar 2003 18:46:18 +0100
Received: from alcatel.be ([138.203.137.2])
          by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11)
          with ESMTP id 2003030618461645:5179 ;
          Thu, 6 Mar 2003 18:46:16 +0100 
Message-ID: <3E678926.6A865244@alcatel.be>
Date: Thu, 06 Mar 2003 18:45:10 +0100
From: Dimitri.Papadimitriou@alcatel.be
Organization: optical network architecture (nta - antwerpen)
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: curtis@fictitious.org
Cc: John Drake <jdrake@calient.net>, "'Yangguang Xu'" <xuyg@lucent.com>,
        Zhi-Wei Lin <zwlin@comcast.net>, mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <200303061553.KAA34859@workhorse.fictitious.org>
X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 03/06/2003 18:46:16,
	Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 03/06/2003 18:46:17,
	Serialize complete at 03/06/2003 18:46:17
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

curtis,

> > > -----Original Message-----
> > > From: Yangguang Xu [mailto:xuyg@lucent.com]
> > > Sent: Wednesday, March 05, 2003 2:55 PM
> > > To: Dimitri.Papadimitriou@alcatel.be; Zhi-Wei Lin
> > > Cc: mpls@UU.NET
> > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > >
> > >
> > > 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.

the charter says 
"Define signalling protocols and measurement protocols such that 
they support multiple physical path and tunnel technologies"
 
> GMPLS is not intended for end to end connections according to the WG
> charter.

please indicate in the charter where this has been said (i don't
see this, but may be i missed it) ? of course today the scope is 
limited to tackle single carrier control plane aspects (and we
are also waiting for tewg guidelines in order to move a step 
beyond) 
 
> 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.

well here the charter says:

"- Define signalling protocols and measurement protocols such that they
support multiple physical path and tunnel technologies (e.g. O-O and
O-E-O optical switches, ATM and Frame Relay switches, MPLS, GRE) using
input from technology-specific working groups such as MPLS, IPO, etc"

if "optical" switching techno's such as sdh and oth are not 
connection oriented technologies then you should tell me your 
definition of connection oriented technology ? 

also nothing has been said that we want to work on "ASON
requirements" but just give an ietf implementation answer

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

in my view the best that can be done is to "analyze" the ason 
model at the ccamp and deliver our ietf gmpls implementation 
answer, clearly it will be to the user community to tell us
if this answer is satisfactory or not 

also, i am not sure we have to completely re-evaluate and 
re-discuss the work that has been accomplished at q12/sg15 
(even if i strongly believe in some kind of phasing here as 
also mentioned here above) note that q12 himself delivers
updates on ason work (since an outcome is always perfectible)

imho in between do everything and let everything done by others
(and just assign code-points) there is more than certainly a 
consensus that we can find here
 
thanks,
- dimitri.

> Curtis

-- 
Papadimitriou Dimitri 
E-mail : dimitri.papadimitriou@alcatel.be 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491


From owner-mpls@UU.NET  Thu Mar  6 14:44:48 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08528
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 14:44:47 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewt01634
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 19:46:52 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewt00959;
	Thu, 6 Mar 2003 19:46:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoewo26594
	for mpls-outgoing; Thu, 6 Mar 2003 18:34:35 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoewo26570
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 18:34:21 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoewo12393
	for <mpls@uu.net>; Thu, 6 Mar 2003 18:33:15 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewo10571
	for <mpls@uu.net>; Thu, 6 Mar 2003 18:33:14 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoewo10526
	for <mpls@uu.net>; Thu, 6 Mar 2003 18:33:10 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h26IX4ws014408
	for <mpls@uu.net>; Thu, 6 Mar 2003 13:33:05 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA13646 for <mpls@uu.net>; Thu, 6 Mar 2003 13:33:04 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h26IX4412089 for mpls@uu.net; Thu, 6 Mar 2003 13:33:04 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoewo26447
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 18:31:26 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoewo23946
	for <mpls@UU.NET>; Thu, 6 Mar 2003 18:30:31 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewo26124
	for <mpls@UU.NET>; Thu, 6 Mar 2003 18:30:30 GMT
Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoewo26094
	for <mpls@UU.NET>; Thu, 6 Mar 2003 18:30:29 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id NAA36905;
	Thu, 6 Mar 2003 13:27:42 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303061827.NAA36905@workhorse.fictitious.org>
To: Dimitri.Papadimitriou@alcatel.be
cc: curtis@fictitious.org, John Drake <jdrake@calient.net>,
        "'Yangguang Xu'" <xuyg@lucent.com>, Zhi-Wei Lin <zwlin@comcast.net>,
        mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
In-reply-to: Your message of "Thu, 06 Mar 2003 18:45:10 +0100."
             <3E678926.6A865244@alcatel.be> 
Date: Thu, 06 Mar 2003 13:27:41 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <3E678926.6A865244@alcatel.be>, Dimitri.Papadimitriou@alcatel.be wri
tes:
> curtis,
> 
> > > > -----Original Message-----
> > > > From: Yangguang Xu [mailto:xuyg@lucent.com]
> > > > Sent: Wednesday, March 05, 2003 2:55 PM
> > > > To: Dimitri.Papadimitriou@alcatel.be; Zhi-Wei Lin
> > > > Cc: mpls@UU.NET
> > > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > > >
> > > >
> > > > 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.
> 
> the charter says 
> "Define signalling protocols and measurement protocols such that 
> they support multiple physical path and tunnel technologies"
>  
> > GMPLS is not intended for end to end connections according to the WG
> > charter.
> 
> please indicate in the charter where this has been said (i don't
> see this, but may be i missed it) ? of course today the scope is 
> limited to tackle single carrier control plane aspects (and we
> are also waiting for tewg guidelines in order to move a step 
> beyond) 
>  
> > 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.
> 
> well here the charter says:
> 
> "- Define signalling protocols and measurement protocols such that they
> support multiple physical path and tunnel technologies (e.g. O-O and
> O-E-O optical switches, ATM and Frame Relay switches, MPLS, GRE) using
> input from technology-specific working groups such as MPLS, IPO, etc"
> 
> if "optical" switching techno's such as sdh and oth are not 
> connection oriented technologies then you should tell me your 
> definition of connection oriented technology ? 
> 
> also nothing has been said that we want to work on "ASON
> requirements" but just give an ietf implementation answer

None of the technologies above require end-2-end GMPLS signaling.
Tunneling ATM and FR is fine.  Operating GMPLS over ATM and FR is
fine.

> > 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.
> 
> in my view the best that can be done is to "analyze" the ason 
> model at the ccamp and deliver our ietf gmpls implementation 
> answer, clearly it will be to the user community to tell us
> if this answer is satisfactory or not 
> 
> also, i am not sure we have to completely re-evaluate and 
> re-discuss the work that has been accomplished at q12/sg15 
> (even if i strongly believe in some kind of phasing here as 
> also mentioned here above) note that q12 himself delivers
> updates on ason work (since an outcome is always perfectible)
> 
> imho in between do everything and let everything done by others
> (and just assign code-points) there is more than certainly a 
> consensus that we can find here
>  
> thanks,
> - dimitri.

ASON has not been accepted as a set of requirements for GMPLS
therefore work on implementing it should not be undertaken.

Curtis



From owner-mpls@UU.NET  Thu Mar  6 14:55:43 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08975
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 14:55:43 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewt08713
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 19:57:47 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewt07948;
	Thu, 6 Mar 2003 19:57:18 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoewp28904
	for mpls-outgoing; Thu, 6 Mar 2003 18:57:35 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoewp28897
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 18:57:21 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoewp17538
	for <mpls@UU.NET>; Thu, 6 Mar 2003 18:57:09 GMT
From: neil.2.harrison@bt.com
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewp14656
	for <mpls@UU.NET>; Thu, 6 Mar 2003 18:57:09 GMT
Received: from cbibipnt05.hc.bt.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: saturn.bt.com [193.113.57.20])
	id QQoewp14637
	for <mpls@UU.NET>; Thu, 6 Mar 2003 18:57:08 GMT
Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89)
	id <F5QY5Y70>; Thu, 6 Mar 2003 18:57:23 -0000
Message-ID: <0536FC9B908BEC4597EE721BE6A35389014D0082@i2km07-ukbr.domain1.systemhost.net>
To: Mark.Jones@mail.sprint.com, dwfedyk@nortelnetworks.com, gash@att.com
Cc: ccamp@ops.ietf.org, mpls@UU.NET
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Thu, 6 Mar 2003 18:51:45 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

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

> -----Original Message-----
> From: Mark.Jones@mail.sprint.com [mailto:Mark.Jones@mail.sprint.com]
> Sent: 06 March 2003 15:14
> To: dwfedyk@nortelnetworks.com; gash@att.com
> Cc: ccamp@ops.ietf.org; mpls@UU.NET
> Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> 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
> Optical Transport and Networking
> Sprint - Wireline Technology Development
> 913-794-2139
>  
> 
> -----Original Message-----
> From: dwfedyk [mailto:dwfedyk@nortelnetworks.com]
> Sent: Thursday, March 06, 2003 7:49 AM
> To: gash
> Cc: mpls; ccamp
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> 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 owner-mpls@UU.NET  Thu Mar  6 14:55:56 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08996
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 14:55:56 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewt09094
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 19:58:01 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewt08594;
	Thu, 6 Mar 2003 19:57:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoewp28968
	for mpls-outgoing; Thu, 6 Mar 2003 18:58:35 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoewp28952
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 18:58:23 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoewp14489
	for <mpls@UU.NET>; Thu, 6 Mar 2003 18:57:10 GMT
From: neil.2.harrison@bt.com
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewp14674
	for <mpls@UU.NET>; Thu, 6 Mar 2003 18:57:10 GMT
Received: from cbibipnt05.hc.bt.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: saturn.bt.com [193.113.57.20])
	id QQoewp14655
	for <mpls@UU.NET>; Thu, 6 Mar 2003 18:57:09 GMT
Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89)
	id <F5QY5Y8A>; Thu, 6 Mar 2003 18:57:23 -0000
Message-ID: <0536FC9B908BEC4597EE721BE6A35389014D0083@i2km07-ukbr.domain1.systemhost.net>
To: Gert.Grammel@alcatel.de, Mark.Jones@mail.sprint.com
Cc: dwfedyk@nortelnetworks.com, gash@att.com, ccamp@ops.ietf.org, mpls@UU.NET
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Thu, 6 Mar 2003 18:51:47 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Gert....its not a nice feature if you don't want to use the forced
functional component set.

Ignoring the commercial vertical (client/server) and horizontal (same layer
partitioning) requirements for functional decoupling, there are certain
behaviours an operator may wish to use at L1/0 that are different to those
the operator may wish to use in a L3/2 network.  Operators may want the
freedom to choose what they consider (whether others agree with them or not)
what they perceive as best-of-breed components.  For example, why should an
operator be forced to use v4 addressing for the user-plane access points at
L1/0?  Why should they be forced to use RSVP-TE signalling if they believe
pnni signalling is better?  Why should they be forced to run a routing
protocol at L1/0 (they may want discovery aspects however and the ability to
hold a routing cache) when they need access to centralised records (eg duct
records), and moreover they want their management system to retain
absolute/overriding control?  It's not clear to me operators have such
degrees of freedom here.

regards, Neil

> -----Original Message-----
> From: Gert Grammel [mailto:Gert.Grammel@alcatel.de]
> Sent: 06 March 2003 16:17
> To: Mark.Jones@mail.sprint.com
> Cc: dwfedyk@nortelnetworks.com; gash@att.com; ccamp@ops.ietf.org;
> mpls@UU.NET
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> 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
> 
> Mark.Jones@mail.sprint.com 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
> > 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
> > Optical Transport and Networking
> > Sprint - Wireline Technology Development
> > 913-794-2139
> >
> >
> > -----Original Message-----
> > From: dwfedyk [mailto:dwfedyk@nortelnetworks.com]
> > Sent: Thursday, March 06, 2003 7:49 AM
> > To: gash
> > Cc: mpls; ccamp
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> > 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
> 
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de
> 
> 
> 
> 


From owner-mpls@UU.NET  Thu Mar  6 15:01:33 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09188
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 15:01:32 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewu29186
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 20:03:37 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewu28499;
	Thu, 6 Mar 2003 20:03:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoewr18861
	for mpls-outgoing; Thu, 6 Mar 2003 19:17:09 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoewr18825
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 19:16:59 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoewq26357
	for <mpls@UU.NET>; Thu, 6 Mar 2003 19:14:19 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewq17980
	for <mpls@UU.NET>; Thu, 6 Mar 2003 19:14:18 GMT
Received: from auemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: auemail1.lucent.com [192.11.223.161])
	id QQoewq17958
	for <mpls@UU.NET>; Thu, 6 Mar 2003 19:14:18 GMT
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by auemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26JEGm04455;
	Thu, 6 Mar 2003 14:14:16 -0500 (EST)
Received: from lucent.com (sjtrowbridge.lra.lucent.com [192.11.157.214]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id NAA11291; Thu, 6 Mar 2003 13:14:08 -0600 (CST)
Message-ID: <3E679DFC.61CCEAE5@lucent.com>
Date: Thu, 06 Mar 2003 12:14:04 -0700
From: Stephen Trowbridge <sjtrowbridge@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5  (Windows NT 5.0; U)
X-Accept-Language: en,zh
MIME-Version: 1.0
To: Dimitri.Papadimitriou@alcatel.be
CC: curtis@fictitious.org, John Drake <jdrake@calient.net>,
        "'Yangguang Xu'" <xuyg@lucent.com>, Zhi-Wei Lin <zwlin@comcast.net>,
        mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <200303061553.KAA34859@workhorse.fictitious.org> <3E678926.6A865244@alcatel.be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dimitri,

snip
> imho in between do everything and let everything done by others
> (and just assign code-points) there is more than certainly a
> consensus that we can find here
Absolutely. And the way we work together and find a consensus is
to get IETF to pay attention to the liaison statements early on and
to respond. Then we all know from the start what gets done inside,
what gets done outside, and what gets done through ongoing collaboration.
Regards,
Steve

> 
> thanks,
> - dimitri.
> 
> > Curtis
> 
> --
> Papadimitriou Dimitri
> E-mail : dimitri.papadimitriou@alcatel.be
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : dpapadimitriou@psg.com
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : +32 3 240-8491


From owner-mpls@UU.NET  Thu Mar  6 15:10:35 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10508
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 15:10:35 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewu27164
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 20:12:40 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewu26702;
	Thu, 6 Mar 2003 20:12:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoews20347
	for mpls-outgoing; Thu, 6 Mar 2003 19:37:48 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoews20320
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 19:37:28 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoews06261
	for <mpls@uu.net>; Thu, 6 Mar 2003 19:37:15 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoews09575
	for <mpls@uu.net>; Thu, 6 Mar 2003 19:37:14 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoews09532
	for <mpls@uu.net>; Thu, 6 Mar 2003 19:37:11 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h26Jb4kD023218
	for <mpls@uu.net>; Thu, 6 Mar 2003 14:37:08 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA20200 for <mpls@uu.net>; Thu, 6 Mar 2003 14:37:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h26Jb3321333 for mpls@uu.net; Thu, 6 Mar 2003 14:37:03 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoews20083
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 19:35:34 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoews13296
	for <mpls@UU.NET>; Thu, 6 Mar 2003 19:35:22 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoews07460
	for <mpls@UU.NET>; Thu, 6 Mar 2003 19:35:22 GMT
Received: from mother.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12])
	id QQoews07451
	for <mpls@UU.NET>; Thu, 6 Mar 2003 19:35:21 GMT
Received: (qmail 15864 invoked by uid 104); 6 Mar 2003 19:35:20 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4251.  Clear:. 
 Processed in 0.833361 secs); 06 Mar 2003 19:35:20 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by mother.pmc-sierra.bc.ca with SMTP; 6 Mar 2003 19:35:18 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h26JZIh06571;
	Thu, 6 Mar 2003 11:35:18 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <DCP4H6QX>; Thu, 6 Mar 2003 11:35:18 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03D6E@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: ccamp@ops.ietf.org, mpls@UU.NET
Subject: draft-iesg-vendor-extensions-00.txt
Date: Thu, 6 Mar 2003 11:35:16 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi All,

I would like to make an alternative proposal to what is proposed in this draft.
I think that IETF should not prevent other SDOs from developing extensions (minor or major),
to IETF protocols, as long as they don't call those extensions being IETF compliant.
I think IETF could recommend that the other SDOs present their protocol extensions
to IETF (in the form of a draft). The IETF community then has 3 choices:

1) IETF agrees with the requirements and nature of the extensions and find them useful. In that case IETF could engage in technical discussions with the other SDO and reach to a mutually agreeable draft, which could then be advanced to Proposed Standard.

2) IETF agrees with the requirement, but does not agree with the proposed extension, and prefers other solutions/extensions that it thinks meet those requirements. In that case IETF could develop its solution and present it to the requesting SDO. If that SDO is satisfied with
IETF's solution, then fine, otherwise nobody can prevent them from developing their own extension. If that happens then there would be two solutions for the same requirements
and we should let the Market decide which solution/extension do they prefer.

3) IETF does not agree with the requirement for such extensions at all. In that case, the
other SDO should be free to developed their own extension, provided they don't call those extensions to be IETF compliant.



Thanks,
-Shahram



From owner-mpls@UU.NET  Thu Mar  6 15:29:04 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11374
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 15:29:04 -0500 (EST)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewo07147;
	Thu, 6 Mar 2003 18:31:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoewi01723
	for mpls-outgoing; Thu, 6 Mar 2003 17:14:15 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoewi01713
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 17:14:07 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoewi21029
	for <mpls@uu.net>; Thu, 6 Mar 2003 17:13:07 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewi03396
	for <mpls@uu.net>; Thu, 6 Mar 2003 17:13:07 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoewi03378
	for <mpls@uu.net>; Thu, 6 Mar 2003 17:13:06 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h26HD3kD022461
	for <mpls@uu.net>; Thu, 6 Mar 2003 12:13:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA07045 for <mpls@uu.net>; Thu, 6 Mar 2003 12:13:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h26HD3029682 for mpls@uu.net; Thu, 6 Mar 2003 12:13:03 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoewi01529
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 17:11:20 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoewi01302
	for <mpls@UU.NET>; Thu, 6 Mar 2003 17:11:13 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewi25794
	for <mpls@UU.NET>; Thu, 6 Mar 2003 17:11:12 GMT
Received: from auds953.usa.alcatel.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: auds953.usa.alcatel.com [143.209.238.6])
	id QQoewi25781
	for <mpls@UU.NET>; Thu, 6 Mar 2003 17:11:11 GMT
Received: from alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.12.6/8.12.6) with ESMTP id h26HBAeW029523
	for <mpls@UU.NET>; Thu, 6 Mar 2003 11:11:10 -0600 (CST)
Message-ID: <3E67812E.4CDAAE0F@alcatel.com>
Date: Thu, 06 Mar 2003 11:11:10 -0600
From: Eric Wang <chieh-chung.wang@alcatel.com>
Reply-To: chieh-chung.wang@alcatel.com
Organization: Research & Innovation
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: DisSubcribe
Content-Type: multipart/mixed;
 boundary="------------A67EAB7534AB0EE30AC6DE40"
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.
--------------A67EAB7534AB0EE30AC6DE40
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dissubscribe

--------------A67EAB7534AB0EE30AC6DE40
Content-Type: text/x-vcard; charset=us-ascii;
 name="chieh-chung.wang.vcf"
Content-Description: Card for Eric Wang
Content-Disposition: attachment;
 filename="chieh-chung.wang.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Wang;Eric
x-mozilla-html:TRUE
org:Research & Innovation - Alcatel USA;Advanced Routers & CrossConnects
adr:;;;;;;
version:2.1
email;internet:chieh-chung.wang@alcatel.com
title:Software Development Engineer
x-mozilla-cpt:;-18008
fn:Eric Wang
end:vcard

--------------A67EAB7534AB0EE30AC6DE40--



From owner-mpls@UU.NET  Thu Mar  6 15:59:08 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12253
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 15:59:07 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewy18690
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 21:01:10 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewy17913;
	Thu, 6 Mar 2003 21:00:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoewv12075
	for mpls-outgoing; Thu, 6 Mar 2003 20:17:14 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoewv11876
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 20:16:51 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoewu19354
	for <mpls@UU.NET>; Thu, 6 Mar 2003 20:07:27 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewu07378
	for <mpls@UU.NET>; Thu, 6 Mar 2003 20:07:27 GMT
Received: from hoemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail1.lucent.com [192.11.226.161])
	id QQoewu07364
	for <mpls@UU.NET>; Thu, 6 Mar 2003 20:07:26 GMT
Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35])
	by hoemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h26K7Pf22296
	for <mpls@UU.NET>; Thu, 6 Mar 2003 15:07:25 -0500 (EST)
Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19)
	id <1HW0MBQG>; Thu, 6 Mar 2003 15:07:24 -0500
Message-ID: <61B49BC6DA0DDE40957FB499E1835E3705FA841B@nj7460exch010u.ho.lucent.com>
From: "Varma, Eve L (Eve)" <evarma@lucent.com>
To: "'Gert Grammel'" <Gert.Grammel@alcatel.de>, Mark.Jones@mail.sprint.com
Cc: ccamp@ops.ietf.org, dwfedyk@nortelnetworks.com, gash@att.com, mpls@UU.NET
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Thu, 6 Mar 2003 15:07:23 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

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:Gert.Grammel@alcatel.de]
Sent: Thursday, March 06, 2003 2:21 PM
To: Mark.Jones@mail.sprint.com
Cc: ccamp@ops.ietf.org; dwfedyk@nortelnetworks.com; gash@att.com;
mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt


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



Mark.Jones@mail.sprint.com 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
> Optical Transport and Networking
> Sprint - Wireline Technology Development
> 913-794-2139
>
>
> -----Original Message-----
> From: Gert.Grammel [mailto:Gert.Grammel@alcatel.de]
> Sent: Thursday, March 06, 2003 10:17 AM
> To: Mark.Jones
> Cc: dwfedyk; gash; ccamp; mpls
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> 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
>
> Mark.Jones@mail.sprint.com 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
> > 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
> > Optical Transport and Networking
> > Sprint - Wireline Technology Development
> > 913-794-2139
> >
> >
> > -----Original Message-----
> > From: dwfedyk [mailto:dwfedyk@nortelnetworks.com]
> > Sent: Thursday, March 06, 2003 7:49 AM
> > To: gash
> > Cc: mpls; ccamp
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> > 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
>
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de




From owner-mpls@UU.NET  Thu Mar  6 16:00:17 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12299
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 16:00:17 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewy03863
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 21:02:20 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewy02104;
	Thu, 6 Mar 2003 21:01:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoewv12202
	for mpls-outgoing; Thu, 6 Mar 2003 20:17:41 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoewv12054
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 20:17:10 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoewt08296
	for <mpls@uu.net>; Thu, 6 Mar 2003 19:46:12 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewt22209
	for <mpls@uu.net>; Thu, 6 Mar 2003 19:46:11 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoewt22155
	for <mpls@uu.net>; Thu, 6 Mar 2003 19:46:10 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h26Jk8ws024331
	for <mpls@uu.net>; Thu, 6 Mar 2003 14:46:08 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA21093 for <mpls@uu.net>; Thu, 6 Mar 2003 14:46:07 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h26Jk7J22795 for mpls@uu.net; Thu, 6 Mar 2003 14:46:07 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoews20861
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 19:44:26 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoews18168
	for <mpls@UU.NET>; Thu, 6 Mar 2003 19:44:10 GMT
From: Mark.Jones@mail.sprint.com
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoews27400
	for <mpls@UU.NET>; Thu, 6 Mar 2003 19:44:10 GMT
Received: from damgwp01.corp.sprint.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: parker2.sprint.com [199.14.91.106])
	id QQoews27382
	for <mpls@UU.NET>; Thu, 6 Mar 2003 19:44:09 GMT
Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93])
	by damgwp01.corp.sprint.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h26JrFI06361;
	Thu, 6 Mar 2003 13:53:15 -0600 (CST)
Received: from kcopmp04.corp.sprint.com (kcopmp04m [10.79.2.196])
	by kcmgwp02.corp.sprint.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id h26JhKH19735;
	Thu, 6 Mar 2003 13:43:21 -0600 (CST)
Received: from localhost (root@localhost)
	by kcopmp04.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id NAA23708;
	Thu, 6 Mar 2003 13:43:13 -0600 (CST)
X-OpenMail-Hops: 1
Date: Thu, 6 Mar 2003 13:43:13 -0600
Message-Id: <H00017a81fd529df.1046979790.kcopmp04@MHS>
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
MIME-Version: 1.0
TO: Gert.Grammel@alcatel.de
CC: ccamp@ops.ietf.org, dwfedyk@nortelnetworks.com, gash@att.com, mpls@UU.NET
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline; filename="BDY.TXT"
	;Creation-Date="Thu, 6 Mar 2003 13:43:11 -0600"
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

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
Optical Transport and Networking
Sprint - Wireline Technology Development
913-794-2139
 

-----Original Message-----
From: Gert.Grammel [mailto:Gert.Grammel@alcatel.de]
Sent: Thursday, March 06, 2003 1:21 PM
To: Mark.Jones
Cc: ccamp; dwfedyk; gash; mpls
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt


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



Mark.Jones@mail.sprint.com 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
> Optical Transport and Networking
> Sprint - Wireline Technology Development
> 913-794-2139
>
>
> -----Original Message-----
> From: Gert.Grammel [mailto:Gert.Grammel@alcatel.de]
> Sent: Thursday, March 06, 2003 10:17 AM
> To: Mark.Jones
> Cc: dwfedyk; gash; ccamp; mpls
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> 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
>
> Mark.Jones@mail.sprint.com 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
> > 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
> > Optical Transport and Networking
> > Sprint - Wireline Technology Development
> > 913-794-2139
> >
> >
> > -----Original Message-----
> > From: dwfedyk [mailto:dwfedyk@nortelnetworks.com]
> > Sent: Thursday, March 06, 2003 7:49 AM
> > To: gash
> > Cc: mpls; ccamp
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> > 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
>
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de





From owner-mpls@UU.NET  Thu Mar  6 16:01:02 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12343
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 16:01:02 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewy21291
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 21:03:05 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewy20679;
	Thu, 6 Mar 2003 21:02:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoewv12379
	for mpls-outgoing; Thu, 6 Mar 2003 20:19:15 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoewv12372
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 20:19:05 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoewv14138
	for <mpls@uu.net>; Thu, 6 Mar 2003 20:17:12 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewv19928
	for <mpls@uu.net>; Thu, 6 Mar 2003 20:17:12 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoewv19916
	for <mpls@uu.net>; Thu, 6 Mar 2003 20:17:11 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h26KH9kD002253
	for <mpls@uu.net>; Thu, 6 Mar 2003 15:17:09 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA23935 for <mpls@uu.net>; Thu, 6 Mar 2003 15:17:09 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h26KH8Z26042 for mpls@uu.net; Thu, 6 Mar 2003 15:17:08 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoewv11551
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 20:15:28 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoewu21694
	for <mpls@uu.net>; Thu, 6 Mar 2003 20:03:10 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewu14195
	for <mpls@uu.net>; Thu, 6 Mar 2003 20:03:10 GMT
Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoewu14180
	for <mpls@uu.net>; Thu, 6 Mar 2003 20:03:09 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA37922;
	Thu, 6 Mar 2003 15:00:38 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303062000.PAA37922@workhorse.fictitious.org>
To: John Drake <jdrake@calient.net>
cc: "'Zhi-Wei Lin'" <zwlin@comcast.net>, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
In-reply-to: Your message of "Thu, 06 Mar 2003 09:47:24 PST."
             <9D42C6E086250248810DCADA39CE7EFC9722BF@nimbus> 
Date: Thu, 06 Mar 2003 15:00:37 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <9D42C6E086250248810DCADA39CE7EFC9722BF@nimbus>, John Drake writes:
> I think the point was that one would not be able to establish an LSP on a
> path containing both ASON and GMPLS networks

And you cannot send a packet on a path that contains bot OSI and IP
networks.  Such is the nature of standards.

In a situation like this one of them typically withers and dies.  But
this doesn't happen until after a great deal of arguing and dead end
standards documents from one SDO, typically the one that emphasizes
generating grandeous standards as opposed to carefully considering
real requirements and requiring code and implementations along with
the standards process.

Curtis



From owner-mpls@UU.NET  Thu Mar  6 16:19:32 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13016
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 16:19:32 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewz14638
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 21:21:35 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoewz14341;
	Thu, 6 Mar 2003 21:21:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoewx15504
	for mpls-outgoing; Thu, 6 Mar 2003 20:51:45 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoewx15419
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 20:51:30 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoewx01708
	for <mpls@UU.NET>; Thu, 6 Mar 2003 20:50:32 GMT
From: neil.2.harrison@bt.com
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewx08625
	for <mpls@UU.NET>; Thu, 6 Mar 2003 20:50:32 GMT
Received: from cbibipnt05.hc.bt.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: saturn.bt.com [193.113.57.20])
	id QQoewx08598
	for <mpls@UU.NET>; Thu, 6 Mar 2003 20:50:31 GMT
Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89)
	id <F5QY6BL0>; Thu, 6 Mar 2003 20:50:47 -0000
Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D659E@i2km07-ukbr.domain1.systemhost.net>
To: jdrake@calient.net, curtis@fictitious.org
Cc: xuyg@lucent.com, Dimitri.Papadimitriou@alcatel.be, zwlin@comcast.net,
        mpls@UU.NET
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
Date: Thu, 6 Mar 2003 20:50:27 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Curtis,

I am not sure this end-end vs edge-edge distinction is really that
meaningful anymore wrt current IETF activities.  I understand the IETF view
of end-end with IP and just with IP......that is fine/correct from this
perspective.  But if you can accept (please try) that we operators have
several layered networks to worry about besides IP then end-end is simply
between the trail termination points of whatever layer network we are
dealing with.  So, for example, if I have a customer wanting an E1
connection (over which he can send anything he likes) and this is
transported over SDH, there will be a E1 trail, a lower VC12 trail and a
(possible sequence of tandemed/disjoint) even lower VC4 trails...and each of
these trails are in networks in their own right that have an end-end context
in their own right, and they are not congruent wrt to their end points.
These sorts of services and client/server network relationships won't go
away and therefore we need to provide for them....so any solutions proposed
at L1/0 must deal with them, else they are not generic solutions.

They also exist in GMPLS *if* it can be applied to arbitrary clients as some
are suggesting, quite reasonably IMO, that it can (see Note).  However, I
sense from your comments that you regard such an application to be outside
the scope of IETF/GMPLS.
Note - Extract of Mail from Gert Grammel 06 March 2003 16:17:
"please don't forget that due to the 'Generalization' of GMPLS you are free
to do
the split at any application level you wish." 

I also see you brought up PWE3 which does deal with arbitrary clients (and
what does end-end mean here?).  And this is now deemed in-scope I guess?

Seems very confusing to me (and I think others, eg Note above) to work out
what is in/out of scope.  Maybe the easiest thing would be to simply state
that IETF has now extended its remit to cover all layer network
technologies.....since this seems nothing more than a reflection of what is
happening....but if doing so then IETF cannot claim to have generic
solutions unless it caters for the case noted above, ie arbitrary clients of
L1/0, as the vast majority of operators will require this.

regards, Neil

> -----Original Message-----
> From: John Drake [mailto:jdrake@calient.net]
> Sent: 06 March 2003 17:46
> To: 'curtis@fictitious.org'
> Cc: 'Yangguang Xu'; Dimitri.Papadimitriou@alcatel.be; Zhi-Wei Lin;
> mpls@UU.NET
> Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
> 
> 
> 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
> 
> > -----Original Message-----
> > From: Curtis Villamizar [mailto:curtis@fictitious.org]
> > Sent: Thursday, March 06, 2003 7:54 AM
> > To: John Drake
> > Cc: 'Yangguang Xu'; Dimitri.Papadimitriou@alcatel.be; Zhi-Wei Lin;
> > mpls@UU.NET
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
> > 
> > 
> > 
> > In message <9D42C6E086250248810DCADA39CE7EFC9722BB@nimbus>, 
> > John Drake writes:
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Yangguang Xu [mailto:xuyg@lucent.com]
> > > > Sent: Wednesday, March 05, 2003 2:55 PM
> > > > To: Dimitri.Papadimitriou@alcatel.be; Zhi-Wei Lin
> > > > Cc: mpls@UU.NET
> > > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > > > 
> > > > 
> > > > 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 owner-mpls@UU.NET  Thu Mar  6 16:47:28 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14411
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 16:47:28 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoexb19215
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 21:49:31 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoexb18696;
	Thu, 6 Mar 2003 21:49:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoewz06345
	for mpls-outgoing; Thu, 6 Mar 2003 21:23:23 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoewz06336
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 21:23:17 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoewz26673
	for <mpls@uu.net>; Thu, 6 Mar 2003 21:22:07 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewz07340
	for <mpls@uu.net>; Thu, 6 Mar 2003 21:22:06 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoewz07298
	for <mpls@uu.net>; Thu, 6 Mar 2003 21:22:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h26LM2kD018451
	for <mpls@uu.net>; Thu, 6 Mar 2003 16:22:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA29555 for <mpls@uu.net>; Thu, 6 Mar 2003 16:22:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h26LM2g07958 for mpls@uu.net; Thu, 6 Mar 2003 16:22:02 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoewz06095
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 21:20:03 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoewz03160
	for <mpls@UU.NET>; Thu, 6 Mar 2003 21:19:37 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewz03036
	for <mpls@UU.NET>; Thu, 6 Mar 2003 21:19:36 GMT
Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoewz03003
	for <mpls@UU.NET>; Thu, 6 Mar 2003 21:19:35 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA38532;
	Thu, 6 Mar 2003 16:16:41 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303062116.QAA38532@workhorse.fictitious.org>
To: neil.2.harrison@bt.com
cc: jdrake@calient.net, curtis@fictitious.org, xuyg@lucent.com,
        Dimitri.Papadimitriou@alcatel.be, zwlin@comcast.net, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
In-reply-to: Your message of "Thu, 06 Mar 2003 20:50:27 GMT."
             <0536FC9B908BEC4597EE721BE6A35389025D659E@i2km07-ukbr.domain1.systemhost.net> 
Date: Thu, 06 Mar 2003 16:16:41 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <0536FC9B908BEC4597EE721BE6A35389025D659E@i2km07-ukbr.domain1.system
host.net>, neil.2.harrison@bt.com writes:
> Curtis,
> 
> I am not sure this end-end vs edge-edge distinction is really that
> meaningful anymore wrt current IETF activities.  I understand the IETF view
> of end-end with IP and just with IP......that is fine/correct from this
> perspective.  But if you can accept (please try) that we operators have
> several layered networks to worry about besides IP then end-end is simply
> between the trail termination points of whatever layer network we are
> dealing with.  So, for example, if I have a customer wanting an E1
> connection (over which he can send anything he likes) and this is
> transported over SDH, there will be a E1 trail, a lower VC12 trail and a
> (possible sequence of tandemed/disjoint) even lower VC4 trails...and each of
> these trails are in networks in their own right that have an end-end context
> in their own right, and they are not congruent wrt to their end points.
> These sorts of services and client/server network relationships won't go
> away and therefore we need to provide for them....so any solutions proposed
> at L1/0 must deal with them, else they are not generic solutions.
> 
> They also exist in GMPLS *if* it can be applied to arbitrary clients as some
> are suggesting, quite reasonably IMO, that it can (see Note).  However, I
> sense from your comments that you regard such an application to be outside
> the scope of IETF/GMPLS.
> Note - Extract of Mail from Gert Grammel 06 March 2003 16:17:
> "please don't forget that due to the 'Generalization' of GMPLS you are free
> to do
> the split at any application level you wish." 
> 
> I also see you brought up PWE3 which does deal with arbitrary clients (and
> what does end-end mean here?).  And this is now deemed in-scope I guess?
> 
> Seems very confusing to me (and I think others, eg Note above) to work out
> what is in/out of scope.  Maybe the easiest thing would be to simply state
> that IETF has now extended its remit to cover all layer network
> technologies.....since this seems nothing more than a reflection of what is
> happening....but if doing so then IETF cannot claim to have generic
> solutions unless it caters for the case noted above, ie arbitrary clients of
> L1/0, as the vast majority of operators will require this.
> 
> regards, Neil


Neil,

A well thought out and well articulated response.  Thanks.

A major difference between ASON and the work that the IETF has choosen
to undertake is that there is no external party signaling.  In PWE3
means to provide various L2 tunneling over MPLS/GMPLS are provided.
In your example, with the work the IETF is doing the customer can have
their E1 but it is not signaled.  Or the OC12c trunk can be carried
over MPLS/GMPLS, but again, it is not signaled by the customer.  There
is no UNI for PWE3 or equivalent in GMPLS.

A simple way to accomplish the same thing would be giving the customer
MPLS adjacency but filtering requests (no change in protocols) and
requiring that the first hop in the ERO is one loose hop the exits the
network.  No change at all would be required to protocols, just
filterin of the incoming PATH messages (an implementation choice to
provide such a feature).  This is the same idea behind
draft-swallow-gmpls-overlay-00.txt where the ERO is entirely omitted
and no RRO is sent in response.  This is just a step further hiding
the network internals.

Simple and works vs grandeous.  The IETF usually favors simple.

Curtis


> > -----Original Message-----
> > From: John Drake [mailto:jdrake@calient.net]
> > Sent: 06 March 2003 17:46
> > To: 'curtis@fictitious.org'
> > Cc: 'Yangguang Xu'; Dimitri.Papadimitriou@alcatel.be; Zhi-Wei Lin;
> > mpls@UU.NET
> > Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
> > 
> > 
> > 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
> > 
> > > -----Original Message-----
> > > From: Curtis Villamizar [mailto:curtis@fictitious.org]
> > > Sent: Thursday, March 06, 2003 7:54 AM
> > > To: John Drake
> > > Cc: 'Yangguang Xu'; Dimitri.Papadimitriou@alcatel.be; Zhi-Wei Lin;
> > > mpls@UU.NET
> > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
> > > 
> > > 
> > > 
> > > In message <9D42C6E086250248810DCADA39CE7EFC9722BB@nimbus>, 
> > > John Drake writes:
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Yangguang Xu [mailto:xuyg@lucent.com]
> > > > > Sent: Wednesday, March 05, 2003 2:55 PM
> > > > > To: Dimitri.Papadimitriou@alcatel.be; Zhi-Wei Lin
> > > > > Cc: mpls@UU.NET
> > > > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > > > > 
> > > > > 
> > > > > 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 owner-mpls@UU.NET  Thu Mar  6 18:15:12 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17966
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 18:15:12 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoexh13701
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 23:17:16 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoexh13173;
	Thu, 6 Mar 2003 23:17:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoexf00607
	for mpls-outgoing; Thu, 6 Mar 2003 22:49:04 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoexf00598
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 22:48:55 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoexf27954
	for <mpls@UU.NET>; Thu, 6 Mar 2003 22:48:49 GMT
From: neil.2.harrison@bt.com
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoexf10742
	for <mpls@UU.NET>; Thu, 6 Mar 2003 22:48:49 GMT
Received: from cbibipnt05.hc.bt.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: saturn.bt.com [193.113.57.20])
	id QQoexf10727
	for <mpls@UU.NET>; Thu, 6 Mar 2003 22:48:48 GMT
Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89)
	id <F5QY6M05>; Thu, 6 Mar 2003 22:49:04 -0000
Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D65A1@i2km07-ukbr.domain1.systemhost.net>
To: Gert.Grammel@alcatel.de
Cc: Mark.Jones@mail.sprint.com, dwfedyk@nortelnetworks.com, gash@att.com,
        ccamp@ops.ietf.org, mpls@UU.NET
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Thu, 6 Mar 2003 22:48:37 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

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 owner-mpls@UU.NET  Thu Mar  6 18:38:49 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19420
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 18:38:49 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoexi18162
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 23:40:53 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoexi17579;
	Thu, 6 Mar 2003 23:40:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoexg19577
	for mpls-outgoing; Thu, 6 Mar 2003 23:08:42 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoexg19565
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 23:08:36 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoexg24979
	for <mpls@uu.net>; Thu, 6 Mar 2003 23:07:25 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoexg07703
	for <mpls@uu.net>; Thu, 6 Mar 2003 23:07:24 GMT
Received: from psg.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: psg.com [147.28.0.62])
	id QQoexg07666
	for <mpls@uu.net>; Thu, 6 Mar 2003 23:07:24 GMT
Received: from psg.com ([147.28.0.62] helo=127.0.0.1)
	by psg.com with esmtp (Exim 3.36 #1)
	id 18r4SN-000Fi9-00; Thu, 06 Mar 2003 15:07:19 -0800
Date: Thu, 6 Mar 2003 15:05:59 -0800
From: Alex Zinin <zinin@psg.com>
X-Mailer: The Bat! (v1.62i) Personal
Reply-To: Alex Zinin <zinin@psg.com>
X-Priority: 3 (Normal)
Message-ID: <12374266609.20030306150559@psg.com>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
CC: ccamp@ops.ietf.org, mpls@UU.NET, ietf@ietf.org
Subject: Re: draft-iesg-vendor-extensions-00.txt
In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03D6E@nt-exch-yow.pmc-sierra.bc.ca>
References: 
 <4B6D09F3B826D411A67300D0B706EFDEB03D6E@nt-exch-yow.pmc-sierra.bc.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Shahram,

  Since the draft in subject is not specific to the CCAMP or MPLS WGs,
  or even the SUB-IP area, may I suggest that we don't abuse the
  mailing lists of these WGs and take the discussion to ietf@ietf.org?

-- 
Alex

Thursday, March 6, 2003, 11:35:16 AM, Shahram Davari wrote:
> Hi All,

> I would like to make an alternative proposal to what is proposed in this draft.
> I think that IETF should not prevent other SDOs from developing extensions (minor or major),
> to IETF protocols, as long as they don't call those extensions being IETF compliant.
> I think IETF could recommend that the other SDOs present their protocol extensions
> to IETF (in the form of a draft). The IETF community then has 3 choices:

> 1) IETF agrees with the requirements and nature of the extensions and find them useful. In that case IETF could engage in technical discussions with the other SDO and reach to a mutually agreeable
> draft, which could then be advanced to Proposed Standard.

> 2) IETF agrees with the requirement, but does not agree with the proposed extension, and prefers other solutions/extensions that it thinks meet those requirements. In that case IETF could develop
> its solution and present it to the requesting SDO. If that SDO is satisfied with
> IETF's solution, then fine, otherwise nobody can prevent them from developing their own extension. If that happens then there would be two solutions for the same requirements
> and we should let the Market decide which solution/extension do they prefer.

> 3) IETF does not agree with the requirement for such extensions at all. In that case, the
> other SDO should be free to developed their own extension, provided they don't call those extensions to be IETF compliant.



> Thanks,
> -Shahram



From owner-mpls@UU.NET  Thu Mar  6 18:47:41 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19757
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 18:47:41 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoexj08113
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 23:49:45 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoexj07518;
	Thu, 6 Mar 2003 23:49:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoexg19952
	for mpls-outgoing; Thu, 6 Mar 2003 23:10:47 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoexg19893
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 23:10:34 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoexg06089
	for <mpls@uu.net>; Thu, 6 Mar 2003 23:09:08 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoexg18617
	for <mpls@uu.net>; Thu, 6 Mar 2003 23:09:07 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoexg18595
	for <mpls@uu.net>; Thu, 6 Mar 2003 23:09:06 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h26N93kD009376
	for <mpls@uu.net>; Thu, 6 Mar 2003 18:09:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA07386 for <mpls@uu.net>; Thu, 6 Mar 2003 18:09:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h26N92H15702 for mpls@uu.net; Thu, 6 Mar 2003 18:09:02 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoexg19337
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 23:07:34 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoexg15003
	for <mpls@UU.NET>; Thu, 6 Mar 2003 23:06:51 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoexg26987
	for <mpls@UU.NET>; Thu, 6 Mar 2003 23:06:50 GMT
Received: from kcmso2.proxy.att.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: kcmso2.att.com [192.128.134.71])
	id QQoexg26958
	for <mpls@UU.NET>; Thu, 6 Mar 2003 23:06:49 GMT
Received: from attrh3i.attrh.att.com ([135.71.62.12])
	by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h26MwjGm029347
	for <mpls@UU.NET>; Thu, 6 Mar 2003 17:06:49 -0600 (CST)
Received: from OCCLUST03EVS1.ugd.att.com (135.71.164.11) by attrh3i.attrh.att.com (6.5.032)
        id 3E637D670029AC28; Thu, 6 Mar 2003 18:06:46 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Thu, 6 Mar 2003 18:06:44 -0500
Message-ID: <35BD167AAD17F34F84B265D79518556704072ED5@OCCLUST03EVS1.ugd.att.com>
Thread-Topic: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Thread-Index: AcLkIPV1x2A9aoPATPy6yEREkrn5OgAEaYxQ
From: "Lazer, Monica A, ALABS" <mlazer@att.com>
To: "Gert Grammel" <Gert.Grammel@alcatel.de>, <Mark.Jones@mail.sprint.com>
Cc: <ccamp@ops.ietf.org>, <dwfedyk@nortelnetworks.com>,
        "Ash, Gerald R (Jerry), ALABS" <gash@att.com>, <mpls@UU.NET>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA19757

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
mlazer@att.com

-----Original Message-----
From: Gert Grammel [mailto:Gert.Grammel@alcatel.de]
Sent: Thursday, March 06, 2003 3:38 PM
To: Mark.Jones@mail.sprint.com
Cc: ccamp@ops.ietf.org; dwfedyk@nortelnetworks.com; Ash, Gerald R
(Jerry), ALABS; mpls@UU.NET
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


Mark.Jones@mail.sprint.com 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
> Optical Transport and Networking
> Sprint - Wireline Technology Development
> 913-794-2139
>
>
> -----Original Message-----
> From: Gert.Grammel [mailto:Gert.Grammel@alcatel.de]
> Sent: Thursday, March 06, 2003 1:21 PM
> To: Mark.Jones
> Cc: ccamp; dwfedyk; gash; mpls
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> 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
>
> Mark.Jones@mail.sprint.com 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
> > Optical Transport and Networking
> > Sprint - Wireline Technology Development
> > 913-794-2139
> >
> >
> > -----Original Message-----
> > From: Gert.Grammel [mailto:Gert.Grammel@alcatel.de]
> > Sent: Thursday, March 06, 2003 10:17 AM
> > To: Mark.Jones
> > Cc: dwfedyk; gash; ccamp; mpls
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> > 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
> >
> > Mark.Jones@mail.sprint.com 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
> > > 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
> > > Optical Transport and Networking
> > > Sprint - Wireline Technology Development
> > > 913-794-2139
> > >
> > >
> > > -----Original Message-----
> > > From: dwfedyk [mailto:dwfedyk@nortelnetworks.com]
> > > Sent: Thursday, March 06, 2003 7:49 AM
> > > To: gash
> > > Cc: mpls; ccamp
> > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > >
> > > 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
> >
> > --
> > Alcatel Optical Network Division    Gert Grammel
> > Network Strategy                    phone: +49 711 821 47368
> > Lorenzstrasse 10                    fax: +49 711 821 43169
> > D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de
>
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de




From owner-mpls@UU.NET  Thu Mar  6 19:26:59 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21414
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 19:26:59 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoexl11994
	for <mpls-archive@lists.ietf.org>; Fri, 7 Mar 2003 00:29:02 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoexl11082;
	Fri, 7 Mar 2003 00:28:33 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoexi22327
	for mpls-outgoing; Thu, 6 Mar 2003 23:35:40 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoexi22320
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 23:35:35 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoexi20853
	for <mpls@uu.net>; Thu, 6 Mar 2003 23:35:20 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoexi24193
	for <mpls@uu.net>; Thu, 6 Mar 2003 23:35:19 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoexi24182
	for <mpls@uu.net>; Thu, 6 Mar 2003 23:35:18 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h26NZFws020658
	for <mpls@uu.net>; Thu, 6 Mar 2003 18:35:15 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA09108 for <mpls@uu.net>; Thu, 6 Mar 2003 18:35:15 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h26NZFX19742 for mpls@uu.net; Thu, 6 Mar 2003 18:35:15 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoexi22219
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 23:33:20 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoexi10004
	for <mpls@uu.net>; Thu, 6 Mar 2003 23:31:49 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoexi07396
	for <mpls@uu.net>; Thu, 6 Mar 2003 23:31:49 GMT
Received: from halt-in.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: halt-in.cisco.com [171.70.144.185])
	id QQoexi07378
	for <mpls@uu.net>; Thu, 6 Mar 2003 23:31:49 GMT
Received: from cisco.com (144.254.74.60)
  by halt-in.cisco.com with ESMTP; 06 Mar 2003 15:31:42 -0800
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h26NU6qj008601;
	Fri, 7 Mar 2003 00:30:06 +0100 (MET)
Received: from JVASSEUR-W2K.cisco.com (ch2-dhcp134-209.cisco.com [161.44.134.209])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id AAA16041;
	Fri, 7 Mar 2003 00:31:44 +0100 (MET)
Message-Id: <4.3.2.7.2.20030306182711.08393b90@paris.cisco.com>
X-Sender: jvasseur@paris.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 06 Mar 2003 18:31:43 -0500
To: mpls@UU.NET
From: Jean Philippe Vasseur <jvasseur@cisco.com>
Subject: New Revision of MPLS TE FRR Bandwidth protection draft: 
Cc: acharny@cisco.com, flefauch@cisco.com, javier.achirica@telefonica-data.com,
        jeanlouis.leroux@francetelecom.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

Just posted a new version of the MPLS TE FRR Bandwidth Protection draft: 
ftp://ftp.normos.org/ietf/internet-drafts/draft-vasseur-mpls-backup-computation-02.txt

Those are the main changes compared to the rev-01:
	-> new co-author: Jean-Louis Leroux (FRANCE TELECOM),
	-> editorial changes/corrections,
	-> various clarifications and additional examples,
	-> introduction of the notion of SDLG (Shared SRLG Dependency Link Group) 
that allows to extend the applicability of the model to the case
	of links belonging to multiple SRLGs - see the new section 8 + Appendix 8,
	-> changes in the BACKUP-TUNNEL object format with:
		- new flags,
		- new field: "Bypass-tunnel-destination" so that the PCC can specify the 
required protected bandwidth per NNHOP (when the 		protected bandwidth is 
the sum of actual reserved bandwidths for the set of TE LSPs requiring 
bandwidth protection).

Any comment is very welcome.

JP. 



From owner-mpls@UU.NET  Thu Mar  6 19:29:31 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21492
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 19:29:31 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoexm16585
	for <mpls-archive@lists.ietf.org>; Fri, 7 Mar 2003 00:31:33 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoexm13975;
	Fri, 7 Mar 2003 00:30:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoexi22648
	for mpls-outgoing; Thu, 6 Mar 2003 23:38:07 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoexi22624
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 23:37:53 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoexi28856
	for <mpls@uu.net>; Thu, 6 Mar 2003 23:37:47 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoexi12252
	for <mpls@uu.net>; Thu, 6 Mar 2003 23:37:47 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoexi12233
	for <mpls@uu.net>; Thu, 6 Mar 2003 23:37:46 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h26NbgkD012975
	for <mpls@uu.net>; Thu, 6 Mar 2003 18:37:43 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA09306 for <mpls@uu.net>; Thu, 6 Mar 2003 18:37:42 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h26NbgZ20046 for mpls@uu.net; Thu, 6 Mar 2003 18:37:42 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoewr19328
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 19:23:23 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoewr28424
	for <mpls@uu.net>; Thu, 6 Mar 2003 19:21:58 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewr24328
	for <mpls@uu.net>; Thu, 6 Mar 2003 19:21:58 GMT
Received: from mailrelay1.alcatel.de by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailrelay2.alcatel.de [194.113.59.71])
	id QQoewr24314
	for <mpls@uu.net>; Thu, 6 Mar 2003 19:21:57 GMT
Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10])
	by mailrelay1.alcatel.de (8.9.3/8.9.3) with ESMTP id UAA18367;
	Thu, 6 Mar 2003 20:21:14 +0100 (MET)
Received: from slsv7at ([149.204.245.107] helo=slsv7a.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 18r0w0-0002bh-00; Thu, 06 Mar 2003 20:21:40 +0100
Received: from sls3on.stgl.sel.alcatel.de ([149.204.30.251] helo=alcatel.de) by slsv7a.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 18r0w0-0003tC-00; Thu, 06 Mar 2003 20:21:40 +0100
Message-ID: <3E679FB5.542FBF09@alcatel.de>
Date: Thu, 06 Mar 2003 20:21:25 +0100
From: Gert Grammel <Gert.Grammel@alcatel.de>
Organization: Alcatel TND Product Strategy
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en,de
MIME-Version: 1.0
To: Mark.Jones@mail.sprint.com
CC: ccamp@ops.ietf.org, dwfedyk@nortelnetworks.com, gash@att.com, mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <H00017a81fd4100a.1046968694.kcopmp04@MHS>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

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



Mark.Jones@mail.sprint.com 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
> Optical Transport and Networking
> Sprint - Wireline Technology Development
> 913-794-2139
>
>
> -----Original Message-----
> From: Gert.Grammel [mailto:Gert.Grammel@alcatel.de]
> Sent: Thursday, March 06, 2003 10:17 AM
> To: Mark.Jones
> Cc: dwfedyk; gash; ccamp; mpls
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> 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
>
> Mark.Jones@mail.sprint.com 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
> > 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
> > Optical Transport and Networking
> > Sprint - Wireline Technology Development
> > 913-794-2139
> >
> >
> > -----Original Message-----
> > From: dwfedyk [mailto:dwfedyk@nortelnetworks.com]
> > Sent: Thursday, March 06, 2003 7:49 AM
> > To: gash
> > Cc: mpls; ccamp
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> > 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
>
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de




From owner-mpls@UU.NET  Thu Mar  6 19:29:51 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21507
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 19:29:50 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoexm17315
	for <mpls-archive@lists.ietf.org>; Fri, 7 Mar 2003 00:31:53 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoexm15277;
	Fri, 7 Mar 2003 00:30:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoexi22662
	for mpls-outgoing; Thu, 6 Mar 2003 23:38:22 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoexi22651
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 23:38:07 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoexi08164
	for <mpls@uu.net>; Thu, 6 Mar 2003 23:37:59 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoexi12590
	for <mpls@uu.net>; Thu, 6 Mar 2003 23:37:57 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoexi12574
	for <mpls@uu.net>; Thu, 6 Mar 2003 23:37:57 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h26NbrkD013009
	for <mpls@uu.net>; Thu, 6 Mar 2003 18:37:54 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA09320 for <mpls@uu.net>; Thu, 6 Mar 2003 18:37:53 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h26Nbr420052 for mpls@uu.net; Thu, 6 Mar 2003 18:37:53 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoewu10699
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 20:11:01 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoewt22570
	for <mpls@uu.net>; Thu, 6 Mar 2003 19:57:13 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoewt07813
	for <mpls@uu.net>; Thu, 6 Mar 2003 19:57:12 GMT
Received: from mailrelay2.alcatel.de by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailrelay1.alcatel.de [194.113.59.75])
	id QQoewt07790
	for <mpls@uu.net>; Thu, 6 Mar 2003 19:57:11 GMT
Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10])
	by mailrelay2.alcatel.de (8.9.3/8.9.3) with ESMTP id UAA10129;
	Thu, 6 Mar 2003 20:55:53 +0100 (MET)
Received: from slsv7at ([149.204.245.107] helo=slsv7a.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 18r1U7-0007Ot-00; Thu, 06 Mar 2003 20:56:55 +0100
Received: from sls3on.stgl.sel.alcatel.de ([149.204.30.251] helo=alcatel.de) by slsv7a.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 18r1U7-0006nR-00; Thu, 06 Mar 2003 20:56:55 +0100
Message-ID: <3E67A7F8.127F442@alcatel.de>
Date: Thu, 06 Mar 2003 20:56:41 +0100
From: Gert Grammel <Gert.Grammel@alcatel.de>
Organization: Alcatel TND Product Strategy
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en,de
MIME-Version: 1.0
To: neil.2.harrison@bt.com
CC: Mark.Jones@mail.sprint.com, dwfedyk@nortelnetworks.com, gash@att.com,
        ccamp@ops.ietf.org, mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <0536FC9B908BEC4597EE721BE6A35389014D0083@i2km07-ukbr.domain1.systemhost.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Neil,

I know that you've had a hard time in the past with your arguments. To comment
to some of them:

  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.
  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.
  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 ;-)?
  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?
  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.

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. I say this because
it seems to me that Mark understood that there are very specific L1/0 points
which are under 'hot discussion'. I am not aware of those, but you may want to
correct me there.

Regards

Gert



neil.2.harrison@bt.com wrote:

> Gert....its not a nice feature if you don't want to use the forced
> functional component set.
>
> Ignoring the commercial vertical (client/server) and horizontal (same layer
> partitioning) requirements for functional decoupling, there are certain
> behaviours an operator may wish to use at L1/0 that are different to those
> the operator may wish to use in a L3/2 network.  Operators may want the
> freedom to choose what they consider (whether others agree with them or not)
> what they perceive as best-of-breed components.  For example, why should an
> operator be forced to use v4 addressing for the user-plane access points at
> L1/0?  Why should they be forced to use RSVP-TE signalling if they believe
> pnni signalling is better?  Why should they be forced to run a routing
> protocol at L1/0 (they may want discovery aspects however and the ability to
> hold a routing cache) when they need access to centralised records (eg duct
> records), and moreover they want their management system to retain
> absolute/overriding control?  It's not clear to me operators have such
> degrees of freedom here.
>
> regards, Neil
>
> > -----Original Message-----
> > From: Gert Grammel [mailto:Gert.Grammel@alcatel.de]
> > Sent: 06 March 2003 16:17
> > To: Mark.Jones@mail.sprint.com
> > Cc: dwfedyk@nortelnetworks.com; gash@att.com; ccamp@ops.ietf.org;
> > mpls@UU.NET
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> >
> > 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
> >
> > Mark.Jones@mail.sprint.com 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
> > > 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
> > > Optical Transport and Networking
> > > Sprint - Wireline Technology Development
> > > 913-794-2139
> > >
> > >
> > > -----Original Message-----
> > > From: dwfedyk [mailto:dwfedyk@nortelnetworks.com]
> > > Sent: Thursday, March 06, 2003 7:49 AM
> > > To: gash
> > > Cc: mpls; ccamp
> > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > >
> > > 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
> >
> > --
> > Alcatel Optical Network Division    Gert Grammel
> > Network Strategy                    phone: +49 711 821 47368
> > Lorenzstrasse 10                    fax: +49 711 821 43169
> > D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de
> >
> >
> >
> >

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de




From owner-mpls@UU.NET  Thu Mar  6 19:29:59 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21536
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 19:29:59 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoexm17570
	for <mpls-archive@lists.ietf.org>; Fri, 7 Mar 2003 00:32:02 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoexm15688;
	Fri, 7 Mar 2003 00:31:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoexi22724
	for mpls-outgoing; Thu, 6 Mar 2003 23:39:11 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoexi22702
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 23:38:47 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoexi12902
	for <mpls@uu.net>; Thu, 6 Mar 2003 23:38:36 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoexi13639
	for <mpls@uu.net>; Thu, 6 Mar 2003 23:38:35 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoexi13617
	for <mpls@uu.net>; Thu, 6 Mar 2003 23:38:34 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h26NcVkD013085
	for <mpls@uu.net>; Thu, 6 Mar 2003 18:38:31 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA09362 for <mpls@uu.net>; Thu, 6 Mar 2003 18:38:30 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h26NcUZ20157 for mpls@uu.net; Thu, 6 Mar 2003 18:38:30 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoeww14291
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Mar 2003 20:41:11 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoeww21390
	for <mpls@uu.net>; Thu, 6 Mar 2003 20:40:41 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeww12743
	for <mpls@uu.net>; Thu, 6 Mar 2003 20:40:40 GMT
Received: from mailrelay2.alcatel.de by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailrelay1.alcatel.de [194.113.59.75])
	id QQoeww12721
	for <mpls@uu.net>; Thu, 6 Mar 2003 20:40:39 GMT
Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10])
	by mailrelay2.alcatel.de (8.9.3/8.9.3) with ESMTP id VAA13358;
	Thu, 6 Mar 2003 21:37:40 +0100 (MET)
Received: from slsv7at ([149.204.245.107] helo=slsv7a.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 18r28Z-0000o6-00; Thu, 06 Mar 2003 21:38:43 +0100
Received: from sls3on.stgl.sel.alcatel.de ([149.204.30.251] helo=alcatel.de) by slsv7a.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 18r28Y-0000ZB-00; Thu, 06 Mar 2003 21:38:42 +0100
Message-ID: <3E67B1C3.4401083C@alcatel.de>
Date: Thu, 06 Mar 2003 21:38:28 +0100
From: Gert Grammel <Gert.Grammel@alcatel.de>
Organization: Alcatel TND Product Strategy
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en,de
MIME-Version: 1.0
To: Mark.Jones@mail.sprint.com
CC: ccamp@ops.ietf.org, dwfedyk@nortelnetworks.com, gash@att.com, mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <H00017a81fd529df.1046979790.kcopmp04@MHS>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

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


Mark.Jones@mail.sprint.com 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
> Optical Transport and Networking
> Sprint - Wireline Technology Development
> 913-794-2139
>
>
> -----Original Message-----
> From: Gert.Grammel [mailto:Gert.Grammel@alcatel.de]
> Sent: Thursday, March 06, 2003 1:21 PM
> To: Mark.Jones
> Cc: ccamp; dwfedyk; gash; mpls
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> 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
>
> Mark.Jones@mail.sprint.com 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
> > Optical Transport and Networking
> > Sprint - Wireline Technology Development
> > 913-794-2139
> >
> >
> > -----Original Message-----
> > From: Gert.Grammel [mailto:Gert.Grammel@alcatel.de]
> > Sent: Thursday, March 06, 2003 10:17 AM
> > To: Mark.Jones
> > Cc: dwfedyk; gash; ccamp; mpls
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> > 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
> >
> > Mark.Jones@mail.sprint.com 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
> > > 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
> > > Optical Transport and Networking
> > > Sprint - Wireline Technology Development
> > > 913-794-2139
> > >
> > >
> > > -----Original Message-----
> > > From: dwfedyk [mailto:dwfedyk@nortelnetworks.com]
> > > Sent: Thursday, March 06, 2003 7:49 AM
> > > To: gash
> > > Cc: mpls; ccamp
> > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > >
> > > 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
> >
> > --
> > Alcatel Optical Network Division    Gert Grammel
> > Network Strategy                    phone: +49 711 821 47368
> > Lorenzstrasse 10                    fax: +49 711 821 43169
> > D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de
>
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de




From owner-mpls@UU.NET  Thu Mar  6 21:20:33 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24377
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 21:20:32 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoext19874
	for <mpls-archive@lists.ietf.org>; Fri, 7 Mar 2003 02:22:38 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoext19478;
	Fri, 7 Mar 2003 02:22:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoexr10400
	for mpls-outgoing; Fri, 7 Mar 2003 01:56:55 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoexr10391
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 7 Mar 2003 01:56:38 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoexr19996
	for <mpls@uu.net>; Fri, 7 Mar 2003 01:56:05 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoexr17555
	for <mpls@uu.net>; Fri, 7 Mar 2003 01:56:04 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoexr17542
	for <mpls@uu.net>; Fri, 7 Mar 2003 01:56:04 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h271u1kD029466
	for <mpls@uu.net>; Thu, 6 Mar 2003 20:56:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA16473 for <mpls@uu.net>; Thu, 6 Mar 2003 20:56:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h271u1Q09058 for mpls@uu.net; Thu, 6 Mar 2003 20:56:01 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoexr10147
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 7 Mar 2003 01:54:35 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoexr13460
	for <mpls@UU.NET>; Fri, 7 Mar 2003 01:54:21 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoexr02498
	for <mpls@UU.NET>; Fri, 7 Mar 2003 01:54:20 GMT
Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoexr02452
	for <mpls@UU.NET>; Fri, 7 Mar 2003 01:54:18 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id UAA40792;
	Thu, 6 Mar 2003 20:51:28 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303070151.UAA40792@workhorse.fictitious.org>
To: Gert Grammel <Gert.Grammel@alcatel.de>
cc: Mark.Jones@mail.sprint.com, ccamp@ops.ietf.org, dwfedyk@nortelnetworks.com,
        gash@att.com, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: {Possible Spam} Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
In-reply-to: Your message of "Thu, 06 Mar 2003 20:21:25 +0100."
             <3E679FB5.542FBF09@alcatel.de> 
Date: Thu, 06 Mar 2003 20:51:27 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


Coments inline.

In message <3E679FB5.542FBF09@alcatel.de>, Gert Grammel writes:
>  
> 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 (agai n informational) in IETF which do not comply to
>      the purity of RSVP-TE. Due t o 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 solutio n on how to proceed. What I've seen so far was a complete
> misperception of what i s 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 networkin g 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)

SDH/SONET bandwidth on demand has never been deployed.  There is
serious question about whether this is a viable service.  The
technology has existed for about a decade (a little less maybe) for
provide ATM SVC service doing essentially the same thing.  Market
penetration after a decade is very close to zero for SVC.  Market
penetration for ATM SPVC/PVC is small and may be shrinking.  The FR
market seems to be shrinking as well.  FR SVC market is zero.
SDH/SONET does not have the bandwidth on demand capability but there
is ample evidence that implementing it would be a waste of time.

ASON is a requirements document from ITU that assumes the SDH/SONET
BOND is a viable service.  This is an enormous leap of faith given the
trends in the market.  The IETF doesn't buy into it.

And yes, most of us are familiar with SS7 and the whole SCP/STP AIN
mess, so if you want to extend TCAP to support ASON, go right ahead.
We in the IETF would get a real good laugh over that.

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

Initially IP and voice ran over TDM.  The bandwidth demands of IP were
much less than voice a decade ago.  As IP penetration grew roughly
exponentially through the early, mid, and most of the late 1990s, this
reversed and IP consumed far more bandwidth than voice.  Switched
services also grew but at a slower rate and in the late 1990s
experienced negative growth for many SPs.  One factor may have been
notable outages in FR (US nationwide one day at one major provider and
intermittent for 10 days in another a few years later) shot a big hole
in the "much more reliable than IP" story.

Initially MPLS served as traffic enginnering strictly for IP.  With IP
still growing substantially, voice growing very slowly (and losing
revenue) and switched services growing slowly to shrinking, there was
motivation to carry voice, switched services, and leased line services
over the IP and/or MPLS infrastructure and decommission older
SDH/SONET ADM and FR or ATM switches.  This led to the tunneling work.

Another factor which led to GMPLS was the (unrealized) promise/hype of
optical switching in the very late 1990s.  IP over an ATM overlay was
a poor design and IP providers did not want to repeat that mistake so
the control of the underlying optical domain was accommodated by what
has evolved into GMPLS.  GMPLS was extended to accommodate TDM in
addition to FSC, LSC and PSC.

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

ASON was never accepted by the IETF as requirements and for very good
reason.  To say that IETF must accept the ASON requirements simply
because they came in a liason statement and that the IETF must
accommodate this ITU folly is absurd.

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

Regardless of how this was handled in Yokohama, some of the
fundamental premise of ASON is flawed.  It would be best if ITU
members go off and waste their own time pursuing ASON capabilities,
just as the ATM Forum went off and wasted their time on Q.2931
capability in UNI 3.x, 4.x, but ITU should do so without extending
protocols which originated in the IETF.

> 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

I look forward to seeing the IETF come up with a formal statement of
liason policy.  It would be useful to have explicitly documented that
liason statements carry no more weight than any individual
internet-draft submission.

Curtis



From owner-mpls@UU.NET  Thu Mar  6 21:34:29 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24829
	for <mpls-archive@lists.ietf.org>; Thu, 6 Mar 2003 21:34:29 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoexu21910
	for <mpls-archive@lists.ietf.org>; Fri, 7 Mar 2003 02:36:34 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoexu21460;
	Fri, 7 Mar 2003 02:36:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoexs29157
	for mpls-outgoing; Fri, 7 Mar 2003 02:10:34 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoexs29135
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 7 Mar 2003 02:10:28 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoexs01485
	for <mpls@uu.net>; Fri, 7 Mar 2003 02:10:10 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoexs03510
	for <mpls@uu.net>; Fri, 7 Mar 2003 02:10:08 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoexs03494
	for <mpls@uu.net>; Fri, 7 Mar 2003 02:10:07 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h272A5kD000785
	for <mpls@uu.net>; Thu, 6 Mar 2003 21:10:05 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA17067 for <mpls@uu.net>; Thu, 6 Mar 2003 21:10:05 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h272A5j10973 for mpls@uu.net; Thu, 6 Mar 2003 21:10:05 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoexs28798
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 7 Mar 2003 02:08:32 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoexs24392
	for <mpls@UU.NET>; Fri, 7 Mar 2003 02:08:12 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoexs18485
	for <mpls@UU.NET>; Fri, 7 Mar 2003 02:08:12 GMT
Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoexs18475
	for <mpls@UU.NET>; Fri, 7 Mar 2003 02:08:11 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id VAA40839;
	Thu, 6 Mar 2003 21:05:27 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303070205.VAA40839@workhorse.fictitious.org>
To: Gert Grammel <Gert.Grammel@alcatel.de>
cc: neil.2.harrison@bt.com, Mark.Jones@mail.sprint.com,
        dwfedyk@nortelnetworks.com, gash@att.com, ccamp@ops.ietf.org,
        mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: {Possible Spam} Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
In-reply-to: Your message of "Thu, 06 Mar 2003 20:56:41 +0100."
             <3E67A7F8.127F442@alcatel.de> 
Date: Thu, 06 Mar 2003 21:05:27 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <3E67A7F8.127F442@alcatel.de>, Gert Grammel writes:
>  
>   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.
>  
>   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 ye t another one (and in
>      IETF we had already two ;-)?
>  
>   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?


Please.  Don't use GMPLS or OSPF or IPv4 (or IPv6) or RSVP/TE.

ASON implemented over PNNI on SS7 would be perfect, but OSI, ATM or
X.25 would be just as good if you prefer those.  This would entirely
disentagle the IETF and ITU wrt ASON.

Curtis



From owner-mpls@UU.NET  Fri Mar  7 00:55:44 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00579
	for <mpls-archive@lists.ietf.org>; Fri, 7 Mar 2003 00:55:43 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeyh16591
	for <mpls-archive@lists.ietf.org>; Fri, 7 Mar 2003 05:57:48 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeyh16271;
	Fri, 7 Mar 2003 05:57:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeyg08790
	for mpls-outgoing; Fri, 7 Mar 2003 05:32:16 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoeyg08783
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 7 Mar 2003 05:31:57 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoeyg25274
	for <mpls@UU.NET>; Fri, 7 Mar 2003 05:31:42 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeyg20690
	for <mpls@UU.NET>; Fri, 7 Mar 2003 05:31:42 GMT
Received: from zcars04f.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57])
	id QQoeyg20680
	for <mpls@UU.NET>; Fri, 7 Mar 2003 05:31:41 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h275Ukj18777;
	Fri, 7 Mar 2003 00:30:47 -0500 (EST)
Received: from zcard0ke.ca.nortel.com ([47.129.242.166]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id GDF44D2J; Fri, 7 Mar 2003 00:30:47 -0500
Received: from nortelnetworks.com (artpt5pz.us.nortel.com [47.140.52.117]) by zcard0ke.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id FSM4PFVZ; Fri, 7 Mar 2003 00:30:46 -0500
Message-ID: <3E682F61.4090004@nortelnetworks.com>
Date: Fri, 07 Mar 2003 00:34:25 -0500
X-Sybari-Space: 00000000 00000000 00000000
From: Don Fedyk <dwfedyk@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: curtis@fictitious.org
CC: Gert Grammel <Gert.Grammel@alcatel.de>, Mark.Jones@mail.sprint.com,
        ccamp@ops.ietf.org, "Don Fedyk" <dwfedyk@nortelnetworks.com>,
        gash@att.com, mpls@UU.NET
Subject: Re: {Possible Spam} Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <200303070151.UAA40792@workhorse.fictitious.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Curtis

Some comments, inline.

Curtis Villamizar wrote:

>Coments inline.
>
>In message <3E679FB5.542FBF09@alcatel.de>, Gert Grammel writes:
>  
>
>> 
>>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 (agai n informational) in IETF which do not comply to
>>     the purity of RSVP-TE. Due t o 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 solutio n on how to proceed. What I've seen so far was a complete
>>misperception of what i s 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 networkin g 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)
>>    
>>
>
>SDH/SONET bandwidth on demand has never been deployed.  There is
>serious question about whether this is a viable service.  The
>technology has existed for about a decade (a little less maybe) for
>provide ATM SVC service doing essentially the same thing.  Market
>penetration after a decade is very close to zero for SVC.  Market
>penetration for ATM SPVC/PVC is small and may be shrinking.  The FR
>market seems to be shrinking as well.  FR SVC market is zero.
>SDH/SONET does not have the bandwidth on demand capability but there
>is ample evidence that implementing it would be a waste of time.
>
>ASON is a requirements document from ITU that assumes the SDH/SONET
>BOND is a viable service.  This is an enormous leap of faith given the
>trends in the market.  The IETF doesn't buy into it.
>
This is not correct. I have had this discussion with the authors and 
they assure me bandwidth on demand not the expected model of deployment. 
It is not precluded true but they realize the current situation.

>
>And yes, most of us are familiar with SS7 and the whole SCP/STP AIN
>mess, so if you want to extend TCAP to support ASON, go right ahead.
>We in the IETF would get a real good laugh over that.
>
>  
>
>>  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.
>>    
>>
>
>Initially IP and voice ran over TDM.  The bandwidth demands of IP were
>much less than voice a decade ago.  As IP penetration grew roughly
>exponentially through the early, mid, and most of the late 1990s, this
>reversed and IP consumed far more bandwidth than voice.  Switched
>services also grew but at a slower rate and in the late 1990s
>experienced negative growth for many SPs.  One factor may have been
>notable outages in FR (US nationwide one day at one major provider and
>intermittent for 10 days in another a few years later) shot a big hole
>in the "much more reliable than IP" story.
>
We know the world is changing and that is why we are trying to reuse IP 
technology.  I think it is a big win if we reuse similar technology 
components. It won't happen overnight. But it wont happen if we don't 
move forward. There is a lot of history in optical networks and they are 
evolving and simplifying. This is similar to the early packet industry. 
We used to have many protocols for different traffic. Only with the 
advent of cheaper bandwidth could we afford IP. 

>
>  
>
<snip> History of GMPLS

>>    
>>
>
>ASON was never accepted by the IETF as requirements and for very good
>reason.  To say that IETF must accept the ASON requirements simply
>because they came in a liason statement and that the IETF must
>accommodate this ITU folly is absurd.
>
I don't think it is about accepting ASON per se. We would not have the 
ITU if that were true. It is about parallel requirements that can be 
solved by the same mechanisms. Is there a one to one mapping? In many 
cases yes. Are there differences yes again. Do we need the IETF to 
accept all the changes?  Well that is THE question. What would be great 
is if the IETF could accommodate, and filter the information that is 
relevant and suggest solutions to features that the IETF cannot see 
value in. That's what I saw happen in other WGs.  You know the ITU has 
taken a lot of technology from the IETF. It is common practice not to 
reinvent technology.

 I can't think of system that was deployed that turned out the way 
everyone thought it would. We wouldn't be deploying IP version 6 if 
there wasn't some room for changes.   There are many profitable ATM 
networks in the world. Guess what?  There are even profitable X.25 
networks still kicking.

>>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 .
>>    
>>
>
>Regardless of how this was handled in Yokohama, some of the
>fundamental premise of ASON is flawed.  It would be best if ITU
>members go off and waste their own time pursuing ASON capabilities,
>just as the ATM Forum went off and wasted their time on Q.2931
>capability in UNI 3.x, 4.x, but ITU should do so without extending
>protocols which originated in the IETF.
>
Your instance that they are all irrelevant and should go away is tiresome.

>>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
>>    
>>
>
>I look forward to seeing the IETF come up with a formal statement of
>liason policy.  It would be useful to have explicitly documented that
>liason statements carry no more weight than any individual
>internet-draft submission.
>
>Curtis
>
Curtis you have proven that even the weight of any individual has a 
pretty high threshold!

Don



From owner-mpls@UU.NET  Fri Mar  7 04:35:29 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16226
	for <mpls-archive@lists.ietf.org>; Fri, 7 Mar 2003 04:35:29 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeyw28907
	for <mpls-archive@lists.ietf.org>; Fri, 7 Mar 2003 09:37:33 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeyw28483;
	Fri, 7 Mar 2003 09:37:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeyu05979
	for mpls-outgoing; Fri, 7 Mar 2003 09:11:37 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoeyu05968
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 7 Mar 2003 09:11:25 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoeyu02582
	for <mpls@UU.NET>; Fri, 7 Mar 2003 09:10:42 GMT
From: neil.2.harrison@bt.com
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeyu11182
	for <mpls@UU.NET>; Fri, 7 Mar 2003 09:10:42 GMT
Received: from mbibipnt08.HC.BT.COM by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: saturn.bt.com [193.113.57.20])
	id QQoeyu11122
	for <mpls@UU.NET>; Fri, 7 Mar 2003 09:10:39 GMT
Received: by mbibipnt08.nat.bt.com with Internet Mail Service (5.5.2653.19)
	id <FXRF59B8>; Fri, 7 Mar 2003 09:10:41 -0000
Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D65A2@i2km07-ukbr.domain1.systemhost.net>
To: dwfedyk@nortelnetworks.com, curtis@fictitious.org
Cc: Gert.Grammel@alcatel.de, Mark.Jones@mail.sprint.com, ccamp@ops.ietf.org,
        gash@att.com, mpls@UU.NET
Subject: RE: {Possible Spam} Re: I-D ACTION:draft-andersson-mpls-g-chng-pr
	oc-00.txt
Date: Fri, 7 Mar 2003 09:10:22 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Don, you observed 07 March 2003 05:34
<snip>
> >SDH/SONET bandwidth on demand has never been deployed.  There is
> >serious question about whether this is a viable service.  The
> >technology has existed for about a decade (a little less maybe) for
> >provide ATM SVC service doing essentially the same thing.  Market
> >penetration after a decade is very close to zero for SVC.  Market
> >penetration for ATM SPVC/PVC is small and may be shrinking.  The FR
> >market seems to be shrinking as well.  FR SVC market is zero.
> >SDH/SONET does not have the bandwidth on demand capability but there
> >is ample evidence that implementing it would be a waste of time.

NH=> Mark has said effectively the same and I can confirm this.  To make
switched services work you basically need (i) very large numbers and (ii)
knowledge of the calling-rate/holding-times.  We have neither at SDH rates
or lower (ie OTN).  However, using generalised models you can show that to
had a stab at a reasonably efficient network/service-model the expected
waiting-time for a given BW 'post demand' needs to be the same order as the
holding-time of that BW.  If the expected holding-time is the order
days/weeks/months on a relatively small network population you can see that
its a nonsense to even think about going here at this point.  Note that you
can extend this arguement to the ethernet BOD case....the fundamantal
problem is the same (you can of course address niche markets in limited
locations, but not large/general-case geographical areas).

Wrt to your other observations on ATM/FR.  Yes, its been very difficult to
justify SVCs here.  This is also due to their use as product substitution
for TDM-leased-line services (to build private networks) rather than new
services.  And from what we see, the FR market is now flat but the ATM
market is still showing fairly high growth rates.
> >
> >ASON is a requirements document from ITU that assumes the SDH/SONET
> >BOND is a viable service.  This is an enormous leap of faith 
> given the
> >trends in the market.  The IETF doesn't buy into it.
> >
> This is not correct. I have had this discussion with the authors and 
> they assure me bandwidth on demand not the expected model of 
> deployment. 
> It is not precluded true but they realize the current situation.
NH=> Again I can confirm what Don is saying is correct.  We have been
consistent on this from the start.....we never saw BOD at L1 as the main
driver.  It was those driving GMPLS who were the main group arguing for BOD
at L1 to set-up 'LSPs' at will for the IP client layer.....and I can
remember arguing with them a couple of years ago on this saying 'please
don't go there'.  In fact its really hard to justify using a control-plane
at all at L1.  The benefits are minimal in our opinion (but to be fair, I
have to admit that we have some very slick NMS/OSS solutions here).
Restoration/S-PVC-like constructs are useful.  Having a control-plane
external NNI is arguably better than a NMS-plane NNI (eg less real damange
possible from any hacking).  Any control-plane solution must play
second-fiddle to the NMS.  And given operators have multiple clients, none
of which will be 'peering' with the L1/0 networks then there is no
compelling argument to select a specific control-plane solution.....the
components can therefore be chosen based on what an operator perceives to be
best-of-breed.
> 
<snip>
> >Initially IP and voice ran over TDM.
NH=> Don, they always will in core networks.  Cct-switching is a fine way to
aggregate *any* forms of large traffic volumes, irrespective of its source
nature.  This is just a fact that any operator could confirm.

regards, Neil
<snipped to end>


From owner-mpls@UU.NET  Fri Mar  7 04:52:56 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16825
	for <mpls-archive@lists.ietf.org>; Fri, 7 Mar 2003 04:52:56 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeyx21824
	for <mpls-archive@lists.ietf.org>; Fri, 7 Mar 2003 09:55:00 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoeyx21452;
	Fri, 7 Mar 2003 09:54:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoeyv07163
	for mpls-outgoing; Fri, 7 Mar 2003 09:29:17 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoeyv07158
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 7 Mar 2003 09:29:10 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoeyv14028
	for <mpls@UU.NET>; Fri, 7 Mar 2003 09:28:30 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoeyv09668
	for <mpls@UU.NET>; Fri, 7 Mar 2003 09:28:30 GMT
Received: from web20709.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web20709.mail.yahoo.com [216.136.226.182])
	id QQoeyv09641
	for <mpls@UU.NET>; Fri, 7 Mar 2003 09:28:29 GMT
Message-ID: <20030307092828.59869.qmail@web20709.mail.yahoo.com>
Received: from [216.174.224.251] by web20709.mail.yahoo.com via HTTP; Fri, 07 Mar 2003 01:28:28 PST
Date: Fri, 7 Mar 2003 01:28:28 -0800 (PST)
From: Sameer K <sameerdw@yahoo.com>
Subject: Repost: RFC 3471: IF ID specification WRT component link.
To: ccamp@ops.ietf.org, mpls@UU.NET
In-Reply-To: <20030220081550.7962.qmail@web20705.mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


Reposting, as I did not get any response.  Could
someone please answer the question.

Thanks
- Sameer

--- Sameer K <sameerdw@yahoo.com> wrote:
> Hello All,
> 
> From the RFC 3471 - GMPLS Signaling Functional
> Description, Section 9.1.1, it appears that there is
> no way for upstream node, to specify component links
> that are numbered, in the IF-ID HOP object.
> 
> The TLV format for IF-ID Types 4 and 5 assumes that
> the component link is always un-numbered.
> 
> Is this the way it was planned to be?.  If yes, then
> what should IF-ID look like for numbered component
> link (which is a valid scenario per the Link
> Bundling
> draft).
> 
> Or did I get it all wrong?
> TIA
> - Sameer
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, more
> http://taxes.yahoo.com/
> 


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/


From owner-mpls@UU.NET  Fri Mar  7 07:29:28 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25840
	for <mpls-archive@lists.ietf.org>; Fri, 7 Mar 2003 07:29:27 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoezi11439
	for <mpls-archive@lists.ietf.org>; Fri, 7 Mar 2003 12:31:31 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoezi10242;
	Fri, 7 Mar 2003 12:30:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoezf23351
	for mpls-outgoing; Fri, 7 Mar 2003 11:56:25 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoezf23341
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 7 Mar 2003 11:56:21 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoezf15587
	for <mpls@uu.net>; Fri, 7 Mar 2003 11:55:41 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoezf01214
	for <mpls@uu.net>; Fri, 7 Mar 2003 11:55:41 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoezf01209
	for <mpls@uu.net>; Fri, 7 Mar 2003 11:55:40 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h27BtcvD008779
	for <mpls@uu.net>; Fri, 7 Mar 2003 06:55:38 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA12470 for <mpls@uu.net>; Fri, 7 Mar 2003 06:55:38 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h27Btc112366 for mpls@uu.net; Fri, 7 Mar 2003 06:55:38 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoezf23103
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 7 Mar 2003 11:54:04 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoezf24774
	for <mpls@uu.net>; Fri, 7 Mar 2003 11:53:40 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoezf24133
	for <mpls@uu.net>; Fri, 7 Mar 2003 11:53:39 GMT
Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQoezf24123
	for <mpls@uu.net>; Fri, 7 Mar 2003 11:53:39 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20855;
	Fri, 7 Mar 2003 06:51:34 -0500 (EST)
Message-Id: <200303071151.GAA20855@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
CC: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ash-mpls-dste-bcmodel-max-alloc-resv-01.txt
Date: Fri, 07 Mar 2003 06:51:33 -0500
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Max Allocation with Reservation BW Constraint Model 
                          for MPLS/DiffServ TE
	Author(s)	: J. Ash
	Filename	: draft-ash-mpls-dste-bcmodel-max-alloc-resv-01.txt
	Pages		: 0
	Date		: 2003-3-6
	
This document complements the DiffServ-aware MPLS TE (DSTE) requirements 
document by giving a functional specification for the Maximum Allocation 
with Reservation (MAR) bandwidth constraint model.  Examples of the 
operation of the MAR bandwidth constraint model are presented.  MAR 
performance is analyzed relative to the criteria for selecting a 
bandwidth constraint model, in order to provide guidance to user 
implementation of the model in their networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ash-mpls-dste-bcmodel-max-alloc-resv-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ash-mpls-dste-bcmodel-max-alloc-resv-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ash-mpls-dste-bcmodel-max-alloc-resv-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-3-6124648.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ash-mpls-dste-bcmodel-max-alloc-resv-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ash-mpls-dste-bcmodel-max-alloc-resv-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-3-6124648.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Fri Mar  7 07:29:33 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25861
	for <mpls-archive@lists.ietf.org>; Fri, 7 Mar 2003 07:29:33 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoezi11559
	for <mpls-archive@lists.ietf.org>; Fri, 7 Mar 2003 12:31:36 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoezi10296;
	Fri, 7 Mar 2003 12:30:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoezf23354
	for mpls-outgoing; Fri, 7 Mar 2003 11:56:27 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoezf23342
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 7 Mar 2003 11:56:22 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoezf15561
	for <mpls@uu.net>; Fri, 7 Mar 2003 11:55:41 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoezf25725
	for <mpls@uu.net>; Fri, 7 Mar 2003 11:55:41 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoezf25711
	for <mpls@uu.net>; Fri, 7 Mar 2003 11:55:40 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h27BtbKO026491
	for <mpls@uu.net>; Fri, 7 Mar 2003 06:55:38 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA12462 for <mpls@uu.net>; Fri, 7 Mar 2003 06:55:37 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h27BtbM12351 for mpls@uu.net; Fri, 7 Mar 2003 06:55:37 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoezf23086
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 7 Mar 2003 11:53:47 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoezf10677
	for <mpls@uu.net>; Fri, 7 Mar 2003 11:52:36 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoezf23567
	for <mpls@uu.net>; Fri, 7 Mar 2003 11:52:36 GMT
Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQoezf23551
	for <mpls@uu.net>; Fri, 7 Mar 2003 11:52:35 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20581;
	Fri, 7 Mar 2003 06:50:29 -0500 (EST)
Message-Id: <200303071150.GAA20581@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
CC: mpls@UU.NET, te-wg@ops.ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ash-e2e-crtp-hdr-compress-01.txt
Date: Fri, 07 Mar 2003 06:50:29 -0500
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: End-to-End VoIP Header Compression Using cRTP
	Author(s)	: J. Ash, B. Goode, J. Hand
	Filename	: draft-ash-e2e-crtp-hdr-compress-01.txt
	Pages		: 9
	Date		: 2003-3-6
	
VoIP typically uses the encapsulation voice/RTP/UDP/IP, wherein the 
packet header is at least 40 bytes, while the voice payload is typically 
no more than 30 bytes.  VoIP header compression can significantly reduce 
the VoIP overhead through various compression mechanisms.  This is 
important on access links where bandwidth is scarce, and can be 
important on backbone facilities, especially where costs are high (e.g., 
some global cross-sections).  In this draft we propose to re-use the 
methods in cRTP to determine the header compression context and to use 
the cRTP session context ID to route a compressed packet between the 
ingress and egress routers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ash-e2e-crtp-hdr-compress-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ash-e2e-crtp-hdr-compress-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ash-e2e-crtp-hdr-compress-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-3-6124457.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ash-e2e-crtp-hdr-compress-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ash-e2e-crtp-hdr-compress-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-3-6124457.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Fri Mar  7 07:29:41 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25888
	for <mpls-archive@lists.ietf.org>; Fri, 7 Mar 2003 07:29:41 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoezi11745
	for <mpls-archive@lists.ietf.org>; Fri, 7 Mar 2003 12:31:45 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoezi10344;
	Fri, 7 Mar 2003 12:30:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoezf23357
	for mpls-outgoing; Fri, 7 Mar 2003 11:56:30 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoezf23343
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 7 Mar 2003 11:56:22 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoezf15574
	for <mpls@uu.net>; Fri, 7 Mar 2003 11:55:41 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoezf25726
	for <mpls@uu.net>; Fri, 7 Mar 2003 11:55:41 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoezf25712
	for <mpls@uu.net>; Fri, 7 Mar 2003 11:55:40 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h27BtbKO026492
	for <mpls@uu.net>; Fri, 7 Mar 2003 06:55:38 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA12466 for <mpls@uu.net>; Fri, 7 Mar 2003 06:55:37 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h27Btbc12357 for mpls@uu.net; Fri, 7 Mar 2003 06:55:37 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoezf23087
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 7 Mar 2003 11:53:47 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoezf10818
	for <mpls@uu.net>; Fri, 7 Mar 2003 11:52:43 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoezf23655
	for <mpls@uu.net>; Fri, 7 Mar 2003 11:52:42 GMT
Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQoezf23647
	for <mpls@uu.net>; Fri, 7 Mar 2003 11:52:42 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20614;
	Fri, 7 Mar 2003 06:50:35 -0500 (EST)
Message-Id: <200303071150.GAA20614@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
CC: te-wg@ops.ietf.org, mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ash-e2e-vompls-hdr-compress-01.txt
Date: Fri, 07 Mar 2003 06:50:35 -0500
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: End-to-End VoIP over MPLS Header Compression
	Author(s)	: J. Ash, B. Goode
	Filename	: draft-ash-e2e-vompls-hdr-compress-01.txt
	Pages		: 0
	Date		: 2003-3-6
	
VoIP over MPLS typically uses the encapsulation voice/RTP/UDP/IP/MPLS.  
For an MPLS VPN, the packet header is at least 48 bytes, while the voice 
payload is typically no more than 30 bytes.  VoIP over MPLS header 
compression can significantly reduce the VoIP overhead through various 
compression mechanisms.  This is important on access links where 
bandwidth is scarce, and can be important on backbone facilities, 
especially where costs are high (e.g., some global cross-sections).  In 
this draft we propose to use RSVP extensions to signal the header 
compression context and other control messages between the ingress and 
egress LSR.  We provide two approaches to determining the header 
compression context: a) re-use the methods in cRTP to determine the 
context, and b) re-use the methods in Swallow's and Berger's 'simple' 
approach to determine the context.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ash-e2e-vompls-hdr-compress-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ash-e2e-vompls-hdr-compress-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-3-6124505.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ash-e2e-vompls-hdr-compress-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ash-e2e-vompls-hdr-compress-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-3-6124505.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Fri Mar  7 15:03:59 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25898
	for <mpls-archive@lists.ietf.org>; Fri, 7 Mar 2003 15:03:59 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofam07319
	for <mpls-archive@lists.ietf.org>; Fri, 7 Mar 2003 20:06:03 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofam07011;
	Fri, 7 Mar 2003 20:05:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofak20930
	for mpls-outgoing; Fri, 7 Mar 2003 19:39:50 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQofak20925
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 7 Mar 2003 19:39:44 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofak12650
	for <mpls@uu.net>; Fri, 7 Mar 2003 19:39:07 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofak04583
	for <mpls@uu.net>; Fri, 7 Mar 2003 19:39:06 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQofak04575
	for <mpls@uu.net>; Fri, 7 Mar 2003 19:39:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h27Jd2vD007408
	for <mpls@uu.net>; Fri, 7 Mar 2003 14:39:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA13115 for <mpls@uu.net>; Fri, 7 Mar 2003 14:39:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h27Jd1E10290 for mpls@uu.net; Fri, 7 Mar 2003 14:39:01 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofak20864
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 7 Mar 2003 19:37:56 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofak25853
	for <mpls@UU.NET>; Fri, 7 Mar 2003 19:36:28 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofak25318
	for <mpls@UU.NET>; Fri, 7 Mar 2003 19:36:28 GMT
Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQofak25216
	for <mpls@UU.NET>; Fri, 7 Mar 2003 19:36:22 GMT
Received: from toque.cisco.com (IDENT:mirapoint@toque.cisco.com [161.44.201.11])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h27JaHsv015297;
	Fri, 7 Mar 2003 11:36:17 -0800 (PST)
Received: from ancaz-w2k01.cisco.com (dhcp-kta1-161-44-193-133.cisco.com [161.44.193.133])
	by toque.cisco.com (Mirapoint)
	with ESMTP id AJW00236;
	Fri, 7 Mar 2003 14:27:44 -0500 (EST)
Message-Id: <4.3.2.7.2.20030307143500.01ba28e0@toque.cisco.com>
X-Sender: ancaz@toque.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 07 Mar 2003 14:36:12 -0500
To: Sameer K <sameerdw@yahoo.com>, kireeti@juniper.net, yakov@juniper.net,
        lberger@movaz.com
From: Anca Zamfir <ancaz@cisco.com>
Subject: Fwd: Re: Repost: RFC 3471: IF ID specification WRT component
  link.
Cc: ccamp@ops.ietf.org, mpls@UU.NET
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

<html>
Sameer,<br>
I think you are right, currently there is no way to specify a numbered
component link in the IF-ID HOP object. Also, AFAIK the ERO is not a
mandatory object so because of this both TE Link and component link
should be specified in the IF-ID HOP.<br>
If the following text would be added to the draft, it could IMO solve
these issues. Comments?<br>
<br>
&quot;Added in RFC-3471 - Section 9.1.1. or added to the bundle draft-
Proposed Changes:<br>
<br>
<font face="Courier, Courier">Type Length Format Description<br>
--------------------------------------------------------------------<br>
1&nbsp;&nbsp;&nbsp; 8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IPv4 Addr. IPv4<br>
2&nbsp;&nbsp;&nbsp; 20&nbsp;&nbsp;&nbsp;&nbsp; IPv6 Addr. IPv6<br>
3&nbsp;&nbsp;&nbsp; 12&nbsp;&nbsp;&nbsp;&nbsp; See below IF_INDEX
(Interface Index)<br>
4&nbsp;&nbsp;&nbsp; 12&nbsp;&nbsp;&nbsp;&nbsp; See below
COMPONENT_IF_DOWNSTREAM (Component interface)<br>
5&nbsp;&nbsp;&nbsp; 12&nbsp;&nbsp;&nbsp;&nbsp; See below
COMPONENT_IF_UPSTREAM (Component interface)<br>
<b>6&nbsp;&nbsp;&nbsp; 8&nbsp;&nbsp;&nbsp;&nbsp; IPv4 Addr. IPv4 -
DOWNSTREAM (Component interface)&nbsp;&nbsp;&nbsp; ---&gt; new<br>
7&nbsp;&nbsp;&nbsp; 8&nbsp;&nbsp;&nbsp;&nbsp; IPv4 Addr. IPv4 - UPSTREAM
(Component interface)<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;
----&gt; new<br>
8&nbsp;&nbsp; 20&nbsp;&nbsp;&nbsp;&nbsp; IPv6 Addr. IPv6 - DOWNSTREAM
(Component interface)&nbsp;&nbsp;&nbsp; ----&gt; new<br>
9&nbsp;&nbsp; 20&nbsp;&nbsp;&nbsp;&nbsp; IPv6 Addr. IPv6 - UPSTREAM
(Component interface)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ----&gt; new<br>
<br>
Types 1-3 are used to identify an unbundled TE
Link<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;
----&gt; new<br>
Types 3-9 are used to identify the component interfaces in the&nbsp;
----&gt; new<br>
case of a bundled TE Link. In this case both the TE Link
and&nbsp;&nbsp;&nbsp;&nbsp; ----&gt; new<br>
the component interface MUST be
specified.&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
----&gt; new<br>
<br>
<br>
<br>
</b></font>This being said, maybe the authors of the bundle draft and
RFC3471 could help to answer the following:<br>
&nbsp;&nbsp; - are these issues valid<br>
&nbsp;&nbsp; - is the proposed change good<br>
&nbsp;&nbsp; - how could the specification be fixed<br>
<br>
Thanks,<br>
Anca<br>
<br>
At 01:28 AM 3/7/2003 -0800, Sameer K wrote:<br>
<br>
<blockquote type=cite cite>Reposting, as I did not get any
response.&nbsp; Could<br>
someone please answer the question.<br>
<br>
Thanks<br>
- Sameer<br>
<br>
--- Sameer K &lt;sameerdw@yahoo.com&gt; wrote:<br>
&gt; Hello All,<br>
&gt; <br>
&gt; From the RFC 3471 - GMPLS Signaling Functional<br>
&gt; Description, Section 9.1.1, it appears that there is<br>
&gt; no way for upstream node, to specify component links<br>
&gt; that are numbered, in the IF-ID HOP object.<br>
&gt; <br>
&gt; The TLV format for IF-ID Types 4 and 5 assumes that<br>
&gt; the component link is always un-numbered.<br>
&gt; <br>
&gt; Is this the way it was planned to be?.&nbsp; If yes, then<br>
&gt; what should IF-ID look like for numbered component<br>
&gt; link (which is a valid scenario per the Link<br>
&gt; Bundling<br>
&gt; draft).<br>
&gt; <br>
&gt; Or did I get it all wrong?<br>
&gt; TIA<br>
&gt; - Sameer<br>
&gt; <br>
&gt; <br>
&gt; __________________________________________________<br>
&gt; Do you Yahoo!?<br>
&gt; Yahoo! Tax Center - forms, calculators, tips, more<br>
&gt;
<a href="http://taxes.yahoo.com/" eudora="autourl">http://taxes.yahoo.com/</a><br>
&gt; <br>
<br>
<br>
__________________________________________________<br>
Do you Yahoo!?<br>
Yahoo! Tax Center - forms, calculators, tips, more<br>
<a href="http://taxes.yahoo.com/" eudora="autourl">http://taxes.yahoo.com/</a></blockquote><br>

<font face="Courier New, Courier">--------------------------------------------<br>
</font><font face="Times New Roman CE, Times">Anca
Zamfir&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Public Carrier IP <br>
Cisco Systems,
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
email: ancaz@cisco.com<br>
2000 Innovation Dr.,
Kanata&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tel#: (613)
254-3484 <br>
Ontario, CANADA&nbsp; K2K
3E8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fax:&nbsp; (613)
254-3717<br>
&nbsp; </font></html>



From owner-mpls@UU.NET  Fri Mar  7 15:21:35 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27423
	for <mpls-archive@lists.ietf.org>; Fri, 7 Mar 2003 15:21:35 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofan00345
	for <mpls-archive@lists.ietf.org>; Fri, 7 Mar 2003 20:23:40 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofan00140;
	Fri, 7 Mar 2003 20:23:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofal22706
	for mpls-outgoing; Fri, 7 Mar 2003 19:58:22 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQofal22696
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 7 Mar 2003 19:58:16 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQofal04006
	for <mpls@uu.net>; Fri, 7 Mar 2003 19:58:11 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofal05976
	for <mpls@uu.net>; Fri, 7 Mar 2003 19:58:10 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQofal05971
	for <mpls@uu.net>; Fri, 7 Mar 2003 19:58:10 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h27Jw7Sc002747
	for <mpls@uu.net>; Fri, 7 Mar 2003 14:58:08 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA14687 for <mpls@uu.net>; Fri, 7 Mar 2003 14:58:07 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h27Jw7w13769 for mpls@uu.net; Fri, 7 Mar 2003 14:58:07 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQofal22633
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 7 Mar 2003 19:57:04 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQofal27492
	for <mpls@UU.NET>; Fri, 7 Mar 2003 19:56:48 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofal04673
	for <mpls@UU.NET>; Fri, 7 Mar 2003 19:56:47 GMT
Received: from sj-core-5.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-core-5.cisco.com [171.71.177.238])
	id QQofal04663
	for <mpls@UU.NET>; Fri, 7 Mar 2003 19:56:47 GMT
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h27JugtD013800;
	Fri, 7 Mar 2003 11:56:42 -0800 (PST)
Received: from toque.cisco.com (IDENT:mirapoint@toque.cisco.com [161.44.201.11])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h27Jufdq013751;
	Fri, 7 Mar 2003 11:56:41 -0800 (PST)
Received: from ancaz-w2k01.cisco.com (dhcp-kta1-161-44-193-133.cisco.com [161.44.193.133])
	by toque.cisco.com (Mirapoint)
	with ESMTP id AJX00076;
	Fri, 7 Mar 2003 14:48:09 -0500 (EST)
Message-Id: <4.3.2.7.2.20030307145059.02bac540@toque.cisco.com>
X-Sender: ancaz@toque.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 07 Mar 2003 14:56:36 -0500
To: ancaz@cisco.com
From: Anca Zamfir <ancaz@cisco.com>
Subject: Re: Fwd: Re: Repost: RFC 3471: IF ID specification WRT
  component link.
Cc: Sameer K <sameerdw@yahoo.com>, kireeti@juniper.net, yakov@juniper.net,
        lberger@movaz.com, ccamp@ops.ietf.org, mpls@UU.NET
In-Reply-To: <4.3.2.7.2.20030307143500.01ba28e0@toque.cisco.com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

<html>
Hi,<br>
Actually, I need to make a correction. The lack of ERO does not require
the bundled TE link Id to be specified in the IF-ID HOP since the
component link id (numbered or unnumbered) is unique per node.<br>
Thanks,<br>
Anca<br>
p.s. I corrected the text below<br>
<br>
At 02:36 PM 3/7/2003 -0500, Anca Zamfir wrote:<br>
<blockquote type=cite cite>Sameer,<br>
I think you are right, currently there is no way to specify a numbered
component link in the IF-ID HOP object. Also, AFAIK the ERO is not a
mandatory object so because of this both TE Link and component link
should be specified in the IF-ID HOP.<br>
If the following text would be added to the draft, it could IMO solve
these issues. Comments?<br>
<br>
&quot;Added in RFC-3471 - Section 9.1.1. or added to the bundle draft-
Proposed Changes:<br>
<br>
<font face="Courier, Courier">Type Length Format Description<br>
--------------------------------------------------------------------<br>
1&nbsp;&nbsp;&nbsp; 8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IPv4 Addr. IPv4<br>
2&nbsp;&nbsp;&nbsp; 20&nbsp;&nbsp;&nbsp;&nbsp; IPv6 Addr. IPv6<br>
3&nbsp;&nbsp;&nbsp; 12&nbsp;&nbsp;&nbsp;&nbsp; See below IF_INDEX
(Interface Index)<br>
4&nbsp;&nbsp;&nbsp; 12&nbsp;&nbsp;&nbsp;&nbsp; See below
COMPONENT_IF_DOWNSTREAM (Component interface)<br>
5&nbsp;&nbsp;&nbsp; 12&nbsp;&nbsp;&nbsp;&nbsp; See below
COMPONENT_IF_UPSTREAM (Component interface)<br>
<b>6&nbsp;&nbsp;&nbsp; 8&nbsp;&nbsp;&nbsp;&nbsp; IPv4 Addr. IPv4 -
DOWNSTREAM (Component interface)&nbsp;&nbsp;&nbsp; ---&gt; new<br>
7&nbsp;&nbsp;&nbsp; 8&nbsp;&nbsp;&nbsp;&nbsp; IPv4 Addr. IPv4 - UPSTREAM
(Component interface)<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;
----&gt; new<br>
8&nbsp;&nbsp; 20&nbsp;&nbsp;&nbsp;&nbsp; IPv6 Addr. IPv6 - DOWNSTREAM
(Component interface)&nbsp;&nbsp;&nbsp; ----&gt; new<br>
9&nbsp;&nbsp; 20&nbsp;&nbsp;&nbsp;&nbsp; IPv6 Addr. IPv6 - UPSTREAM
(Component interface)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ----&gt; new<br>
<br>
Types 1-3 are used to identify an unbundled TE
Link<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;
----&gt; new<br>
Types 3-9 are used to identify the component interfaces in the&nbsp;
----&gt; new<br>
case of a bundled TE Link. <br>
<br>
<br>
</b></font>This being said, maybe the authors of the bundle draft and
RFC3471 could help to answer the following:<br>
&nbsp;&nbsp; - are these issues valid<br>
&nbsp;&nbsp; - is the proposed change good<br>
&nbsp;&nbsp; - how could the specification be fixed<br>
<br>
Thanks,<br>
Anca<br>
<br>
At 01:28 AM 3/7/2003 -0800, Sameer K wrote:<br>
<br>
<blockquote type=cite cite>Reposting, as I did not get any
response.&nbsp; Could<br>
someone please answer the question.<br>
<br>
Thanks<br>
- Sameer<br>
<br>
--- Sameer K &lt;sameerdw@yahoo.com&gt; wrote:<br>
&gt; Hello All,<br>
&gt; <br>
&gt; From the RFC 3471 - GMPLS Signaling Functional<br>
&gt; Description, Section 9.1.1, it appears that there is<br>
&gt; no way for upstream node, to specify component links<br>
&gt; that are numbered, in the IF-ID HOP object.<br>
&gt; <br>
&gt; The TLV format for IF-ID Types 4 and 5 assumes that<br>
&gt; the component link is always un-numbered.<br>
&gt; <br>
&gt; Is this the way it was planned to be?.&nbsp; If yes, then<br>
&gt; what should IF-ID look like for numbered component<br>
&gt; link (which is a valid scenario per the Link<br>
&gt; Bundling<br>
&gt; draft).<br>
&gt; <br>
&gt; Or did I get it all wrong?<br>
&gt; TIA<br>
&gt; - Sameer<br>
&gt; <br>
&gt; <br>
&gt; __________________________________________________<br>
&gt; Do you Yahoo!?<br>
&gt; Yahoo! Tax Center - forms, calculators, tips, more<br>
&gt;
<a href="http://taxes.yahoo.com/" eudora="autourl">http://taxes.yahoo.com/</a><br>
&gt; <br>
<br>
<br>
__________________________________________________<br>
Do you Yahoo!?<br>
Yahoo! Tax Center - forms, calculators, tips, more<br>
<a href="http://taxes.yahoo.com/" eudora="autourl">http://taxes.yahoo.com/</a></blockquote><br>
<font face="Courier New, Courier">--------------------------------------------<br>
</font><font face="Times New Roman CE, Times">Anca
Zamfir&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Public Carrier IP <br>
Cisco Systems,
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
email: ancaz@cisco.com<br>
2000 Innovation Dr.,
Kanata&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tel#: (613)
254-3484 <br>
Ontario, CANADA&nbsp; K2K
3E8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fax:&nbsp; (613)
254-3717<br>
&nbsp; </font></blockquote><br>

<font face="Courier New, Courier">--------------------------------------------<br>
</font><font face="Times New Roman CE, Times">Anca
Zamfir&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Public Carrier IP <br>
Cisco Systems,
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
email: ancaz@cisco.com<br>
2000 Innovation Dr.,
Kanata&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tel#: (613)
254-3484 <br>
Ontario, CANADA&nbsp; K2K
3E8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fax:&nbsp; (613)
254-3717<br>
&nbsp; </font></html>



From owner-mpls@UU.NET  Fri Mar  7 20:11:36 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23604
	for <mpls-archive@lists.ietf.org>; Fri, 7 Mar 2003 20:11:36 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofbg21294
	for <mpls-archive@lists.ietf.org>; Sat, 8 Mar 2003 01:13:41 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofbg21131;
	Sat, 8 Mar 2003 01:13:30 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofbf13953
	for mpls-outgoing; Sat, 8 Mar 2003 00:48:23 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofbf13948
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 8 Mar 2003 00:48:17 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofbf02064
	for <mpls@uu.net>; Sat, 8 Mar 2003 00:48:08 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofbf28152
	for <mpls@uu.net>; Sat, 8 Mar 2003 00:48:07 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQofbf28141
	for <mpls@uu.net>; Sat, 8 Mar 2003 00:48:06 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h280m4Sc009253
	for <mpls@uu.net>; Fri, 7 Mar 2003 19:48:04 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA06081 for <mpls@uu.net>; Fri, 7 Mar 2003 19:48:04 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h280m3102374 for mpls@uu.net; Fri, 7 Mar 2003 19:48:04 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQofbf13889
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 8 Mar 2003 00:47:02 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQofbf13869
	for <mpls@uu.net>; Sat, 8 Mar 2003 00:46:12 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofbf24058
	for <mpls@uu.net>; Sat, 8 Mar 2003 00:46:11 GMT
Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQofbf24053
	for <mpls@uu.net>; Sat, 8 Mar 2003 00:46:11 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20428;
	Fri, 7 Mar 2003 19:44:05 -0500 (EST)
Message-Id: <200303080044.TAA20428@ietf.org>
To: IETF-Announce:;
Cc: mpls@UU.NET
From: The IESG <iesg-secretary@ietf.org>
SUBJECT: Last Call: Multi Protocol Label Switching Label Distribution 
	   Protocol Query Message Description to Proposed Standard
Reply-to: iesg@ietf.org
Date: Fri, 07 Mar 2003 19:44:04 -0500
Sender: owner-mpls@UU.NET
Precedence: bulk


The IESG has received a request from the Multiprotocol Label Switching 
Working Group to consider Multi Protocol Label Switching Label 
Distribution Protocol Query Message Description 
<draft-ietf-mpls-lsp-query-06.txt> as a Proposed Standard.  

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the 
iesg@ietf.org or ietf@ietf.org mailing lists by 2003-3-25.

Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-query-06.txt





From owner-mpls@UU.NET  Sat Mar  8 13:10:46 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04608
	for <mpls-archive@lists.ietf.org>; Sat, 8 Mar 2003 13:10:46 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofdw19881
	for <mpls-archive@lists.ietf.org>; Sat, 8 Mar 2003 18:12:51 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofdw19542;
	Sat, 8 Mar 2003 18:12:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofdv07769
	for mpls-outgoing; Sat, 8 Mar 2003 17:47:14 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQofdv07761
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 8 Mar 2003 17:47:13 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQofdv23832
	for <mpls@uu.net>; Sat, 8 Mar 2003 17:47:06 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofdv13459
	for <mpls@uu.net>; Sat, 8 Mar 2003 17:47:05 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQofdv13449
	for <mpls@uu.net>; Sat, 8 Mar 2003 17:47:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h28Hl2Sc019027
	for <mpls@uu.net>; Sat, 8 Mar 2003 12:47:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA12146 for <mpls@uu.net>; Sat, 8 Mar 2003 12:47:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h28Hl2a16947 for mpls@uu.net; Sat, 8 Mar 2003 12:47:02 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofdv07738
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 8 Mar 2003 17:46:31 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofdv24576
	for <mpls@uu.net>; Sat, 8 Mar 2003 17:45:45 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofdv25780
	for <mpls@uu.net>; Sat, 8 Mar 2003 17:45:44 GMT
Received: from rkgjwty by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [61.171.252.83])
	id QQofdv25760
	for <mpls@uu.net>; Sat, 8 Mar 2003 17:45:41 GMT
From: Terminiate It <Terminiatecrm@ibm.com>
To: <mpls@UU.NET>
Subject: Stop harassing credit calls ag
Date: Sat, 08 Mar 2003 04:46:17 -0500
Mime-Version: 1.0
Content-Type: text/html
Content-Transfer-Encoding: base64
Message-Id: <lgnmini@ibm.com>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT51am5ucW5yeHZ2YW1zZHBka25sdm50PC90aXRsZT4N
CjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IiNGRkZGRkYiPg0KPGZvbnQgZmFjZT1WZXJkYW5h
IHNpemU9Mj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cubXBsc0BkZWJ0LXBsYW5uaW5nLmNvbS8/
YWZmaWQ9bzg4OCZlPW1wbHNAdXUubmV0Ij48aW1nDQpzcmM9Imh0dHA6Ly9tcGxzQDIxMC4y
Mi4xNDQuMTk5LzQyNXg1MDBfYWRzLmpwZyIgYm9yZGVyPTAgd2lkdGg9NDI1IGhlaWdodD01
MDA+PC9hPg0KPHA+Jm5ic3A7PC9wPg0KPHA+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLTxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cubXBsc0BkZWJ0LXBsYW5uaW5n
LmNvbS9yLz9lPW1wbHNAdXUubmV0Ij48aW1nDQpzcmM9Imh0dHA6Ly8yMTAuMjIuMTQ0LjE5
OS9yZS5naWYiIGJvcmRlcj0wIHdpZHRoPTIwOSBoZWlnaHQ9MjA+PC9hPjxicj51am5ucW5y
eHZ2YW1zZHBka25sdm50LDxicj4iV2h5IGRvIHlvdSB3YW50IHJlZmVyZW5jZXM/Iiw8YnI+
ImBUaGlzIG11c3QgYmUgVGh1cnNkYXksJyBzYWlkIEFydGh1ciB0byBoaW1zZWxmLCBzaW5r
aW5nIGxvdyBvdmVyIGhpcyBiZWVyLCBgSSBuZXZlciBjb3VsZCBnZXQgdGhlIGhhbmcgb2Yg
VGh1cnNkYXlzLiciIDwvZm9udD4NCjwvYm9keT4NCjwvaHRtbD4NCg==



From owner-mpls@UU.NET  Sun Mar  9 11:08:15 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11894
	for <mpls-archive@lists.ietf.org>; Sun, 9 Mar 2003 11:08:15 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofhg23701
	for <mpls-archive@lists.ietf.org>; Sun, 9 Mar 2003 16:10:16 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofhg22981;
	Sun, 9 Mar 2003 16:09:47 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofhe13889
	for mpls-outgoing; Sun, 9 Mar 2003 15:43:51 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofhe13884
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 9 Mar 2003 15:43:49 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQofhe21854
	for <mpls@uu.net>; Sun, 9 Mar 2003 15:42:06 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofhe05735
	for <mpls@uu.net>; Sun, 9 Mar 2003 15:42:05 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQofhe05720
	for <mpls@uu.net>; Sun, 9 Mar 2003 15:42:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h29Fg2Sc000158
	for <mpls@uu.net>; Sun, 9 Mar 2003 10:42:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA25256 for <mpls@uu.net>; Sun, 9 Mar 2003 10:42:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h29Fg1w14376 for mpls@uu.net; Sun, 9 Mar 2003 10:42:01 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQofhe13843
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 9 Mar 2003 15:41:15 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofhe28621
	for <mpls@UU.NET>; Sun, 9 Mar 2003 15:41:13 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofhe24361
	for <mpls@UU.NET>; Sun, 9 Mar 2003 15:41:13 GMT
Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQofhe24351
	for <mpls@UU.NET>; Sun, 9 Mar 2003 15:41:12 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id KAA59785;
	Sun, 9 Mar 2003 10:40:56 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303091540.KAA59785@workhorse.fictitious.org>
To: Sachin Kalra <skalra@opnet.com>
cc: rfc-editor@rfc-editor.org, Internet-Drafts@ietf.org, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: Mails from "rfc-editor" and "Internet-Drafts" 
In-reply-to: Your message of "Thu, 20 Feb 2003 12:03:26 EST."
             <5.0.0.25.2.20030220115522.00a70cb0@mailserver.opnet.com> 
Date: Sun, 09 Mar 2003 10:40:56 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <5.0.0.25.2.20030220115522.00a70cb0@mailserver.opnet.com>, Sachin Ka
lra writes:
> 
> Dear MPLS Community:
> 
> Since last few months, all of the emails that come from 
> 'rfc-editor@rfc-editor.org' and 'Internet-Drafts@ietf.org' appears to be 
> "Virus Infected".
> 
> If this is true, then either they should fix the mails before sending them 
> out or 'mpls@UU.NET' Mail server should filter out the infected mails.
> 
> Just a little thought.
> Thanks,
> Sachin Kalra


AFAIK - No one seems to have responded to this.  The message from the
RFC editor has a few mime encodings that allow you to automatically
download the text of the RFC onto you computer and some overacheiver
mail filtering software interprets this as a virus but delivers the
mail to you anyway but altered with a warning.  The extra URLs if you
get the message unchanged and the warning if you get the message
altered, are both harmless.

Curtis


> At 02:39 PM 2/19/03 -0800, rfc-editor@rfc-editor.org wrote:
> >Warning: This message has had one or more attachments removed
> >Warning: (not named).
> >Warning: Please read the "VirusWarning.txt" attachment(s) for more 
> >information.
> >
> >  {Virus} RFC 3479 on Fault Tolerance for the Label Distribution Protocol 
> > (LDP)



From owner-mpls@UU.NET  Mon Mar 10 10:26:11 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29021
	for <mpls-archive@lists.ietf.org>; Mon, 10 Mar 2003 10:26:10 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofkv12229
	for <mpls-archive@lists.ietf.org>; Mon, 10 Mar 2003 15:28:17 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofkv11622;
	Mon, 10 Mar 2003 15:27:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofkt07036
	for mpls-outgoing; Mon, 10 Mar 2003 14:59:50 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofkt07030
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Mar 2003 14:59:41 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQofkt24915
	for <mpls@UU.NET>; Mon, 10 Mar 2003 14:58:51 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofkt23854
	for <mpls@UU.NET>; Mon, 10 Mar 2003 14:58:51 GMT
Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQofkt23848
	for <mpls@UU.NET>; Mon, 10 Mar 2003 14:58:50 GMT
Received: from juniper.net (garnet.juniper.net [172.17.28.17])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2AEwiS65546;
	Mon, 10 Mar 2003 06:58:44 -0800 (PST)
	(envelope-from yakov@juniper.net)
Message-Id: <200303101458.h2AEwiS65546@merlot.juniper.net>
To: Sameer K <sameerdw@yahoo.com>
cc: ccamp@ops.ietf.org, mpls@UU.NET
Subject: Re: Repost: RFC 3471: IF ID specification WRT component link. 
In-Reply-To: Your message of "Fri, 07 Mar 2003 01:28:28 PST."
             <20030307092828.59869.qmail@web20709.mail.yahoo.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <60283.1047308324.1@juniper.net>
Date: Mon, 10 Mar 2003 06:58:44 -0800
From: Yakov Rekhter <yakov@juniper.net>
Sender: owner-mpls@UU.NET
Precedence: bulk

Sameer,

> 
> Reposting, as I did not get any response.  Could
> someone please answer the question.

from  draft-ietf-mpls-bundle-04.txt:

   If the component link is numbered, the IF_ID RSVP_HOP object, or 
   IF_ID TLV carries either Type 1 (IPv4 address) or Type 2 (IPv6
   address) TLVs (see [GMPLS-SIG]). The address carried in the TLV
   identifies the link for which label allocation must be done.
   
   If the component link is unnumbered, the IF_ID RSVP_HOP object, or
   IF_ID TLV carries Type 3 (IF_INDEX) TLV (see [GMPLS-SIG]). The
   value carried in Type 3 TLV contains the identifier of the selected
   component link assigned to the link by the sender of the Path/REQUEST
   message. Processing this object is the same as specified in Section
   "Processing the IF_ID RSVP_HOP object"/"Processing the IF_ID TLV"
   of [RSVP-UNNUM]/[CRLDP-UNNUM].

Yakov.

> 
> Thanks
> - Sameer
> 
> --- Sameer K <sameerdw@yahoo.com> wrote:
> > Hello All,
> > 
> > From the RFC 3471 - GMPLS Signaling Functional
> > Description, Section 9.1.1, it appears that there is
> > no way for upstream node, to specify component links
> > that are numbered, in the IF-ID HOP object.
> > 
> > The TLV format for IF-ID Types 4 and 5 assumes that
> > the component link is always un-numbered.
> > 
> > Is this the way it was planned to be?.  If yes, then
> > what should IF-ID look like for numbered component
> > link (which is a valid scenario per the Link
> > Bundling
> > draft).
> > 
> > Or did I get it all wrong?
> > TIA
> > - Sameer
> > 
> > 
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Tax Center - forms, calculators, tips, more
> > http://taxes.yahoo.com/
> > 
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, more
> http://taxes.yahoo.com/
> 


From owner-mpls@UU.NET  Mon Mar 10 10:27:39 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29065
	for <mpls-archive@lists.ietf.org>; Mon, 10 Mar 2003 10:27:39 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofkv24433
	for <mpls-archive@lists.ietf.org>; Mon, 10 Mar 2003 15:29:46 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofkv24245;
	Mon, 10 Mar 2003 15:29:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofku14856
	for mpls-outgoing; Mon, 10 Mar 2003 15:01:35 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQofku14578
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Mar 2003 15:01:32 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQofku29414
	for <mpls@uu.net>; Mon, 10 Mar 2003 15:01:11 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofku26038
	for <mpls@uu.net>; Mon, 10 Mar 2003 15:01:11 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQofku26027
	for <mpls@uu.net>; Mon, 10 Mar 2003 15:01:10 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2AF18Sc009261
	for <mpls@uu.net>; Mon, 10 Mar 2003 10:01:08 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA12764 for <mpls@uu.net>; Mon, 10 Mar 2003 10:01:07 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2AF17p14193 for mpls@uu.net; Mon, 10 Mar 2003 10:01:07 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofkt07031
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Mar 2003 14:59:41 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofkt25750
	for <mpls@UU.NET>; Mon, 10 Mar 2003 14:59:23 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofkt25525
	for <mpls@UU.NET>; Mon, 10 Mar 2003 14:59:23 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQofkt25514
	for <mpls@UU.NET>; Mon, 10 Mar 2003 14:59:23 GMT
Received: from bucket.cisco.com (IDENT:mirapoint@bucket.cisco.com [161.44.167.72])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2AEx7vF020054;
	Mon, 10 Mar 2003 09:59:09 -0500 (EST)
Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-1-62.cisco.com [10.86.240.62])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ACS48374;
	Mon, 10 Mar 2003 09:59:06 -0500 (EST)
Message-Id: <5.2.0.9.2.20030310095746.095791b8@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 10 Mar 2003 09:58:58 -0500
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>, ccamp@ops.ietf.org,
        mpls@UU.NET
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: draft-iesg-vendor-extensions-00.txt
In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03D73@nt-exch-yow.pmc-sie
 rra.bc.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


>Thanks, I am happy to hear that my proposal is in fact in-line with
>current IETF standardization process. However, my proposal is about allowing
>other SDOs to develop extensions to IETF protocols, even if IETF does
>not agree to those extension, while the iesg draft prohibits other SDOs from
>developing any extension to IETF protocols without IETF's approval.

         I personally happen to agree with the IESG on the last point.

         --Tom


>-Shahram
>
>
>
> >-----Original Message-----
> >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> >Sent: Friday, March 07, 2003 12:43 PM
> >To: Shahram Davari; ccamp@ops.ietf.org; mpls@UU.NET
> >Subject: Re: draft-iesg-vendor-extensions-00.txt
> >
> >
> >
> >         I don't see how your proposal differs from the current
> >IETF standards process. How could extensions created by other
> >SDOs be considered IETF compliant without being passed through the
> >process within the IETF?  If they are passed through the processes and
> >are eventually approved as standards, then they are called
> >IETF compliant.
> >Where exactly do you see this as being broken and requiring
> >additional red
> >tape?
> >
> >         --Tom
> >
> >
> >>Hi All,
> >>
> >>I would like to make an alternative proposal to what is
> >proposed in this
> >>draft.
> >>I think that IETF should not prevent other SDOs from
> >developing extensions
> >>(minor or major),
> >>to IETF protocols, as long as they don't call those
> >extensions being IETF
> >>compliant.
> >>I think IETF could recommend that the other SDOs present
> >their protocol
> >>extensions
> >>to IETF (in the form of a draft). The IETF community then has
> >3 choices:
> >>1) IETF agrees with the requirements and nature of the
> >extensions and find
> >>them useful. In that case IETF could engage in technical
> >discussions with
> >>the other SDO and reach to a mutually agreeable draft, which
> >could then be
> >>advanced to Proposed Standard.
> >>
> >>2) IETF agrees with the requirement, but does not agree with
> >the proposed
> >>extension, and prefers other solutions/extensions that it thinks meet
> >>those requirements. In that case IETF could develop its solution and
> >>present it to the requesting SDO. If that SDO is satisfied with
> >>IETF's solution, then fine, otherwise nobody can prevent them from
> >>developing their own extension. If that happens then there
> >would be two
> >>solutions for the same requirements
> >>and we should let the Market decide which solution/extension
> >do they prefer.
> >>
> >>3) IETF does not agree with the requirement for such
> >extensions at all. In
> >>that case, the
> >>other SDO should be free to developed their own extension,
> >provided they
> >>don't call those extensions to be IETF compliant.
> >>
> >>
> >>
> >>Thanks,
> >>-Shahram
> >
> >




From owner-mpls@UU.NET  Mon Mar 10 11:10:37 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00867
	for <mpls-archive@lists.ietf.org>; Mon, 10 Mar 2003 11:10:36 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofky09590
	for <mpls-archive@lists.ietf.org>; Mon, 10 Mar 2003 16:12:43 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofky09155;
	Mon, 10 Mar 2003 16:12:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofkw28287
	for mpls-outgoing; Mon, 10 Mar 2003 15:37:35 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQofkw28280
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Mar 2003 15:37:16 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofkw12256
	for <mpls@uu.net>; Mon, 10 Mar 2003 15:37:06 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofkw03661
	for <mpls@uu.net>; Mon, 10 Mar 2003 15:37:05 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQofkw03648
	for <mpls@uu.net>; Mon, 10 Mar 2003 15:37:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2AFb2vD023326
	for <mpls@uu.net>; Mon, 10 Mar 2003 10:37:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA16004 for <mpls@uu.net>; Mon, 10 Mar 2003 10:37:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2AFb1P18848 for mpls@uu.net; Mon, 10 Mar 2003 10:37:01 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofkw28050
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Mar 2003 15:35:32 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofkw20478
	for <mpls@UU.NET>; Mon, 10 Mar 2003 15:34:43 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofkw20444
	for <mpls@UU.NET>; Mon, 10 Mar 2003 15:34:42 GMT
Received: from sj-core-5.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-core-5.cisco.com [171.71.177.238])
	id QQofkw20438
	for <mpls@UU.NET>; Mon, 10 Mar 2003 15:34:42 GMT
Received: from toque.cisco.com (IDENT:mirapoint@toque.cisco.com [161.44.201.11])
	by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2AFYchs003859;
	Mon, 10 Mar 2003 07:34:38 -0800 (PST)
Received: from ancaz-w2k01.cisco.com (dhcp-kta1-161-44-193-133.cisco.com [161.44.193.133])
	by toque.cisco.com (Mirapoint)
	with ESMTP id AKC00371;
	Mon, 10 Mar 2003 10:26:07 -0500 (EST)
Message-Id: <4.3.2.7.2.20030310103158.05cf81f0@toque.cisco.com>
X-Sender: ancaz@toque.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 10 Mar 2003 10:34:38 -0500
To: Yakov Rekhter <yakov@juniper.net>
From: Anca Zamfir <ancaz@cisco.com>
Subject: Re: Repost: RFC 3471: IF ID specification WRT component link. 
Cc: Sameer K <sameerdw@yahoo.com>, ccamp@ops.ietf.org, mpls@UU.NET
In-Reply-To: <200303101458.h2AEwiS65546@merlot.juniper.net>
References: <Your message of "Fri, 07 Mar 2003 01:28:28 PST." <20030307092828.59869.qmail@web20709.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Yakov,
What goes in the IF-ID RSVP_HOP TLVs if upstream and downstream directions 
use different numbered component links?
Thanks,
Anca

At 06:58 AM 3/10/2003 -0800, Yakov Rekhter wrote:
>Sameer,
>
> >
> > Reposting, as I did not get any response.  Could
> > someone please answer the question.
>
>from  draft-ietf-mpls-bundle-04.txt:
>
>    If the component link is numbered, the IF_ID RSVP_HOP object, or
>    IF_ID TLV carries either Type 1 (IPv4 address) or Type 2 (IPv6
>    address) TLVs (see [GMPLS-SIG]). The address carried in the TLV
>    identifies the link for which label allocation must be done.
>
>    If the component link is unnumbered, the IF_ID RSVP_HOP object, or
>    IF_ID TLV carries Type 3 (IF_INDEX) TLV (see [GMPLS-SIG]). The
>    value carried in Type 3 TLV contains the identifier of the selected
>    component link assigned to the link by the sender of the Path/REQUEST
>    message. Processing this object is the same as specified in Section
>    "Processing the IF_ID RSVP_HOP object"/"Processing the IF_ID TLV"
>    of [RSVP-UNNUM]/[CRLDP-UNNUM].
>
>Yakov.
>
> >
> > Thanks
> > - Sameer
> >
> > --- Sameer K <sameerdw@yahoo.com> wrote:
> > > Hello All,
> > >
> > > From the RFC 3471 - GMPLS Signaling Functional
> > > Description, Section 9.1.1, it appears that there is
> > > no way for upstream node, to specify component links
> > > that are numbered, in the IF-ID HOP object.
> > >
> > > The TLV format for IF-ID Types 4 and 5 assumes that
> > > the component link is always un-numbered.
> > >
> > > Is this the way it was planned to be?.  If yes, then
> > > what should IF-ID look like for numbered component
> > > link (which is a valid scenario per the Link
> > > Bundling
> > > draft).
> > >
> > > Or did I get it all wrong?
> > > TIA
> > > - Sameer
> > >
> > >
> > > __________________________________________________
> > > Do you Yahoo!?
> > > Yahoo! Tax Center - forms, calculators, tips, more
> > > http://taxes.yahoo.com/
> > >
> >
> >
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Tax Center - forms, calculators, tips, more
> > http://taxes.yahoo.com/
> >

--------------------------------------------
Anca Zamfir                                Public Carrier IP
Cisco Systems, Inc.                    email: ancaz@cisco.com
2000 Innovation Dr., Kanata          tel#: (613) 254-3484
Ontario, CANADA  K2K 3E8         fax:  (613) 254-3717
   



From owner-mpls@UU.NET  Mon Mar 10 11:11:55 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00920
	for <mpls-archive@lists.ietf.org>; Mon, 10 Mar 2003 11:11:55 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofky11121
	for <mpls-archive@lists.ietf.org>; Mon, 10 Mar 2003 16:14:02 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofky10758;
	Mon, 10 Mar 2003 16:13:47 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofkw28327
	for mpls-outgoing; Mon, 10 Mar 2003 15:38:56 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQofkw28317
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Mar 2003 15:38:48 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofkw15217
	for <mpls@UU.NET>; Mon, 10 Mar 2003 15:37:48 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofkw24385
	for <mpls@UU.NET>; Mon, 10 Mar 2003 15:37:48 GMT
Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQofkw24361
	for <mpls@UU.NET>; Mon, 10 Mar 2003 15:37:47 GMT
Received: from juniper.net (garnet.juniper.net [172.17.28.17])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2AFb1S68174;
	Mon, 10 Mar 2003 07:37:01 -0800 (PST)
	(envelope-from yakov@juniper.net)
Message-Id: <200303101537.h2AFb1S68174@merlot.juniper.net>
To: Anca Zamfir <ancaz@cisco.com>
cc: Sameer K <sameerdw@yahoo.com>, ccamp@ops.ietf.org, mpls@UU.NET
Subject: Re: Repost: RFC 3471: IF ID specification WRT component link. 
In-Reply-To: Your message of "Mon, 10 Mar 2003 10:34:38 EST."
             <4.3.2.7.2.20030310103158.05cf81f0@toque.cisco.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <72929.1047310621.1@juniper.net>
Date: Mon, 10 Mar 2003 07:37:01 -0800
From: Yakov Rekhter <yakov@juniper.net>
Sender: owner-mpls@UU.NET
Precedence: bulk

Anca,

> Yakov,
> What goes in the IF-ID RSVP_HOP TLVs if upstream and downstream directions 
> use different numbered component links?

draft-ietf-mpls-bundle-04.txt does *not* support this.

Yakov.

> Thanks,
> Anca
> 
> At 06:58 AM 3/10/2003 -0800, Yakov Rekhter wrote:
> >Sameer,
> >
> > >
> > > Reposting, as I did not get any response.  Could
> > > someone please answer the question.
> >
> >from  draft-ietf-mpls-bundle-04.txt:
> >
> >    If the component link is numbered, the IF_ID RSVP_HOP object, or
> >    IF_ID TLV carries either Type 1 (IPv4 address) or Type 2 (IPv6
> >    address) TLVs (see [GMPLS-SIG]). The address carried in the TLV
> >    identifies the link for which label allocation must be done.
> >
> >    If the component link is unnumbered, the IF_ID RSVP_HOP object, or
> >    IF_ID TLV carries Type 3 (IF_INDEX) TLV (see [GMPLS-SIG]). The
> >    value carried in Type 3 TLV contains the identifier of the selected
> >    component link assigned to the link by the sender of the Path/REQUEST
> >    message. Processing this object is the same as specified in Section
> >    "Processing the IF_ID RSVP_HOP object"/"Processing the IF_ID TLV"
> >    of [RSVP-UNNUM]/[CRLDP-UNNUM].
> >
> >Yakov.
> >
> > >
> > > Thanks
> > > - Sameer
> > >
> > > --- Sameer K <sameerdw@yahoo.com> wrote:
> > > > Hello All,
> > > >
> > > > From the RFC 3471 - GMPLS Signaling Functional
> > > > Description, Section 9.1.1, it appears that there is
> > > > no way for upstream node, to specify component links
> > > > that are numbered, in the IF-ID HOP object.
> > > >
> > > > The TLV format for IF-ID Types 4 and 5 assumes that
> > > > the component link is always un-numbered.
> > > >
> > > > Is this the way it was planned to be?.  If yes, then
> > > > what should IF-ID look like for numbered component
> > > > link (which is a valid scenario per the Link
> > > > Bundling
> > > > draft).
> > > >
> > > > Or did I get it all wrong?
> > > > TIA
> > > > - Sameer
> > > >
> > > >
> > > > __________________________________________________
> > > > Do you Yahoo!?
> > > > Yahoo! Tax Center - forms, calculators, tips, more
> > > > http://taxes.yahoo.com/
> > > >
> > >
> > >
> > > __________________________________________________
> > > Do you Yahoo!?
> > > Yahoo! Tax Center - forms, calculators, tips, more
> > > http://taxes.yahoo.com/
> > >
> 
> --------------------------------------------
> Anca Zamfir                                Public Carrier IP
> Cisco Systems, Inc.                    email: ancaz@cisco.com
> 2000 Innovation Dr., Kanata          tel#: (613) 254-3484
> Ontario, CANADA  K2K 3E8         fax:  (613) 254-3717
>    
> 
> 


From owner-mpls@UU.NET  Mon Mar 10 11:25:00 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01540
	for <mpls-archive@lists.ietf.org>; Mon, 10 Mar 2003 11:25:00 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofkz19782
	for <mpls-archive@lists.ietf.org>; Mon, 10 Mar 2003 16:27:08 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofkz19498;
	Mon, 10 Mar 2003 16:26:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofkx29737
	for mpls-outgoing; Mon, 10 Mar 2003 15:52:48 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofkx29705
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Mar 2003 15:52:41 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofkx18218
	for <mpls@UU.NET>; Mon, 10 Mar 2003 15:52:20 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofkx17785
	for <mpls@UU.NET>; Mon, 10 Mar 2003 15:52:20 GMT
Received: from tama5.ecl.ntt.co.jp by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: tama5.ecl.ntt.co.jp [129.60.39.102])
	id QQofkx17766
	for <mpls@UU.NET>; Mon, 10 Mar 2003 15:52:19 GMT
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.12.8/8.12.8) with ESMTP id h2AFqHfG008441
	for <mpls@UU.NET>; Tue, 11 Mar 2003 00:52:17 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1])
	by vcs3.rdh.ecl.ntt.co.jp (8.12.8/8.12.8) with ESMTP id h2AFqG41005015
	for <mpls@UU.NET>; Tue, 11 Mar 2003 00:52:16 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.12.8/8.12.8) with ESMTP id h2AFqGZL012335
	for <mpls@UU.NET>; Tue, 11 Mar 2003 00:52:16 +0900 (JST)
Received: from imc.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id AAA07276;
	Tue, 11 Mar 2003 00:52:15 +0900 (JST)
Received: from barrister.lab.ntt.co.jp
	by imc.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id AAA23460;
	Tue, 11 Mar 2003 00:52:13 +0900 (JST)
Message-Id: <5.0.2.5.2.20030311003225.045816e0@imc.m.ecl.ntt.co.jp>
X-Sender: sy003@imc.m.ecl.ntt.co.jp
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J
Date: Tue, 11 Mar 2003 00:56:06 +0900
To: mpls@UU.NET
From: Seisho Yasukawa <yasukawa.seisho@lab.ntt.co.jp>
Subject: draft-yasukawa-mpls-rsvp-p2mp-01.txt
Cc: yasukawa.seisho@lab.ntt.co.jp
In-Reply-To: <5.0.2.5.2.20030228024230.06268c70@imc.m.ecl.ntt.co.jp>
References: <200302271244.HAA27616@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Hello everyone,

Please find following draft.

"Extended RSVP-TE for Point-to-Multipoint LSP Tunnels"

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-rsvp-p2mp-01.txt

We have revised our draft to meet the scope of wg's charter.
Following are major modification points.

1. Eliminate Leaf initiated Join and Leave mechanism
2. Eliminate Mcast Notify mechanism

After this modification, this draft is more specialized to basic P2MP LSP
establishment mechanism.

We welcome any feedback and comments.

Thanks,

Seisho 



From owner-mpls@UU.NET  Mon Mar 10 11:27:21 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01721
	for <mpls-archive@lists.ietf.org>; Mon, 10 Mar 2003 11:27:20 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofkz21735
	for <mpls-archive@lists.ietf.org>; Mon, 10 Mar 2003 16:29:27 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofkz21514;
	Mon, 10 Mar 2003 16:29:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofkx00004
	for mpls-outgoing; Mon, 10 Mar 2003 15:56:16 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofkx29993
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Mar 2003 15:56:12 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofkx23770
	for <mpls@uu.net>; Mon, 10 Mar 2003 15:56:08 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofkx21529
	for <mpls@uu.net>; Mon, 10 Mar 2003 15:56:07 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQofkx21514
	for <mpls@uu.net>; Mon, 10 Mar 2003 15:56:07 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2AFu4vD024902
	for <mpls@uu.net>; Mon, 10 Mar 2003 10:56:04 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA18717 for <mpls@uu.net>; Mon, 10 Mar 2003 10:56:04 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2AFu4J21350 for mpls@uu.net; Mon, 10 Mar 2003 10:56:04 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofkx29849
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Mar 2003 15:54:31 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofkx21111
	for <mpls@UU.NET>; Mon, 10 Mar 2003 15:54:16 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofkx13866
	for <mpls@UU.NET>; Mon, 10 Mar 2003 15:54:16 GMT
Received: from sj-core-5.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-core-5.cisco.com [171.71.177.238])
	id QQofkx13855
	for <mpls@UU.NET>; Mon, 10 Mar 2003 15:54:15 GMT
Received: from toque.cisco.com (IDENT:mirapoint@toque.cisco.com [161.44.201.11])
	by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2AFsChs021491;
	Mon, 10 Mar 2003 07:54:12 -0800 (PST)
Received: from ancaz-w2k01.cisco.com (dhcp-kta1-161-44-193-133.cisco.com [161.44.193.133])
	by toque.cisco.com (Mirapoint)
	with ESMTP id AKC00756;
	Mon, 10 Mar 2003 10:45:42 -0500 (EST)
Message-Id: <4.3.2.7.2.20030310104437.02c9c008@toque.cisco.com>
X-Sender: ancaz@toque.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 10 Mar 2003 10:54:12 -0500
To: Yakov Rekhter <yakov@juniper.net>
From: Anca Zamfir <ancaz@cisco.com>
Subject: Re: Repost: RFC 3471: IF ID specification WRT component link. 
Cc: Sameer K <sameerdw@yahoo.com>, ccamp@ops.ietf.org, mpls@UU.NET
In-Reply-To: <200303101537.h2AFb1S68174@merlot.juniper.net>
References: <Your message of "Mon, 10 Mar 2003 10:34:38 EST." <4.3.2.7.2.20030310103158.05cf81f0@toque.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Yakov,
At 07:37 AM 3/10/2003 -0800, Yakov Rekhter wrote:
>Anca,
>
> > Yakov,
> > What goes in the IF-ID RSVP_HOP TLVs if upstream and downstream directions
> > use different numbered component links?
>
>draft-ietf-mpls-bundle-04.txt does *not* support this.

It looks like draft-ietf-mpls-bundle-04.txt does not support different 
links (numbered or unnumbered) for the upstream and downstream directions.
On the other hand, RFC3471 seems to allow different unnumbered links for 
the upstream and downstream LSP directions, but no equivalent support for 
the numbered case, so it looks like a small inconsistency. Any reasons for 
this?

Thanks,
Anca


>Yakov.
>
> > Thanks,
> > Anca
> >
> > At 06:58 AM 3/10/2003 -0800, Yakov Rekhter wrote:
> > >Sameer,
> > >
> > > >
> > > > Reposting, as I did not get any response.  Could
> > > > someone please answer the question.
> > >
> > >from  draft-ietf-mpls-bundle-04.txt:
> > >
> > >    If the component link is numbered, the IF_ID RSVP_HOP object, or
> > >    IF_ID TLV carries either Type 1 (IPv4 address) or Type 2 (IPv6
> > >    address) TLVs (see [GMPLS-SIG]). The address carried in the TLV
> > >    identifies the link for which label allocation must be done.
> > >
> > >    If the component link is unnumbered, the IF_ID RSVP_HOP object, or
> > >    IF_ID TLV carries Type 3 (IF_INDEX) TLV (see [GMPLS-SIG]). The
> > >    value carried in Type 3 TLV contains the identifier of the selected
> > >    component link assigned to the link by the sender of the Path/REQUEST
> > >    message. Processing this object is the same as specified in Section
> > >    "Processing the IF_ID RSVP_HOP object"/"Processing the IF_ID TLV"
> > >    of [RSVP-UNNUM]/[CRLDP-UNNUM].
> > >
> > >Yakov.
> > >
> > > >
> > > > Thanks
> > > > - Sameer
> > > >
> > > > --- Sameer K <sameerdw@yahoo.com> wrote:
> > > > > Hello All,
> > > > >
> > > > > From the RFC 3471 - GMPLS Signaling Functional
> > > > > Description, Section 9.1.1, it appears that there is
> > > > > no way for upstream node, to specify component links
> > > > > that are numbered, in the IF-ID HOP object.
> > > > >
> > > > > The TLV format for IF-ID Types 4 and 5 assumes that
> > > > > the component link is always un-numbered.
> > > > >
> > > > > Is this the way it was planned to be?.  If yes, then
> > > > > what should IF-ID look like for numbered component
> > > > > link (which is a valid scenario per the Link
> > > > > Bundling
> > > > > draft).
> > > > >
> > > > > Or did I get it all wrong?
> > > > > TIA
> > > > > - Sameer
> > > > >
> > > > >
> > > > > __________________________________________________
> > > > > Do you Yahoo!?
> > > > > Yahoo! Tax Center - forms, calculators, tips, more
> > > > > http://taxes.yahoo.com/
> > > > >
> > > >
> > > >
> > > > __________________________________________________
> > > > Do you Yahoo!?
> > > > Yahoo! Tax Center - forms, calculators, tips, more
> > > > http://taxes.yahoo.com/
> > > >
> >
> > --------------------------------------------
> > Anca Zamfir                                Public Carrier IP
> > Cisco Systems, Inc.                    email: ancaz@cisco.com
> > 2000 Innovation Dr., Kanata          tel#: (613) 254-3484
> > Ontario, CANADA  K2K 3E8         fax:  (613) 254-3717
> >
> >
> >

--------------------------------------------
Anca Zamfir                                Public Carrier IP
Cisco Systems, Inc.                    email: ancaz@cisco.com
2000 Innovation Dr., Kanata          tel#: (613) 254-3484
Ontario, CANADA  K2K 3E8         fax:  (613) 254-3717
   



From owner-mpls@UU.NET  Mon Mar 10 12:54:01 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05560
	for <mpls-archive@lists.ietf.org>; Mon, 10 Mar 2003 12:54:00 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoflf06198
	for <mpls-archive@lists.ietf.org>; Mon, 10 Mar 2003 17:56:08 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoflf05812;
	Mon, 10 Mar 2003 17:55:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofld11371
	for mpls-outgoing; Mon, 10 Mar 2003 17:23:57 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofld11361
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Mar 2003 17:23:44 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofld24339
	for <mpls@UU.NET>; Mon, 10 Mar 2003 17:23:33 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofld15227
	for <mpls@UU.NET>; Mon, 10 Mar 2003 17:23:32 GMT
Received: from dnsmx1pya.telcordia.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31])
	id QQofld15220
	for <mpls@UU.NET>; Mon, 10 Mar 2003 17:23:32 GMT
Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6])
	by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id LAA27642
	for <mpls@UU.NET>; Mon, 10 Mar 2003 11:57:19 -0500 (EST)
Subject: Question for the RFC2961--Refresh reduction--trigger msg
To: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF81A781DD.4CD696EA-ON85256CE5.005ADE7F@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Mon, 10 Mar 2003 11:57:19 -0500
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 03/10/2003 11:57:20 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

I have question for the trigger message.

In the RFC2961,section 4.5,

>>When a node is sending a trigger message, the Message_Identifier value
MUST have a value that is greater than any other value previously used with
the same Epoch field value.

so basically if it is a trigger message then message id should be greater
than previous one with the same epoch value;but does this mean that if the
message id is greater than previous one for the same epoch value, and the
rest of the contents are the same as the previous message, then should the
message be considered as trigger message ?  Can someone confirm this for
me?

Thanks in an advance.

Hong (Julia) Liao
ATM/Broadband Network Integration
Telcordia Technologies, Inc

Tel:  (973) 829-4570
Fax: (973) 829-5962



From owner-mpls@UU.NET  Mon Mar 10 16:01:13 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14146
	for <mpls-archive@lists.ietf.org>; Mon, 10 Mar 2003 16:01:13 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofls02288
	for <mpls-archive@lists.ietf.org>; Mon, 10 Mar 2003 21:03:14 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofls02049;
	Mon, 10 Mar 2003 21:03:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoflq16551
	for mpls-outgoing; Mon, 10 Mar 2003 20:37:39 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoflq16544
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Mar 2003 20:37:24 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoflq24651
	for <mpls@UU.NET>; Mon, 10 Mar 2003 20:37:17 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoflq14141
	for <mpls@UU.NET>; Mon, 10 Mar 2003 20:37:17 GMT
Received: from dnsmx1pya.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31])
	id QQoflq14127
	for <mpls@UU.NET>; Mon, 10 Mar 2003 20:37:16 GMT
Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6])
	by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id PAA14085;
	Mon, 10 Mar 2003 15:36:05 -0500 (EST)
Subject: Question for the RFC2961--Refresh reduction--trigger msg
To: David.Charlap@marconi.com
Cc: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF4096C448.D02E1EBD-ON85256CE5.007110A3@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Mon, 10 Mar 2003 15:36:06 -0500
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 03/10/2003 03:36:10 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

David,

Do you have any idea for my question below?

Thanks,
Julia
----- Forwarded by Hong Liao/Telcordia on 03/10/2003 03:34 PM -----
                                                                                                            
                    "Hong Liao"                                                                             
                    <hliao@telcor        To:     mpls@UU.NET                                                
                    dia.com>             cc:     (bcc: Hong Liao/Telcordia)                                 
                                         Subject:     Question for the RFC2961--Refresh reduction--trigger  
                    03/10/2003           msg                                                                
                    11:57 AM                                                                                
                                                                                                            
                                                                                                            





Hi,

I have question for the trigger message.

In the RFC2961,section 4.5,

>>When a node is sending a trigger message, the Message_Identifier value
MUST have a value that is greater than any other value previously used with
the same Epoch field value.

so basically if it is a trigger message then message id should be greater
than previous one with the same epoch value;but does this mean that if the
message id is greater than previous one for the same epoch value, and the
rest of the contents are the same as the previous message, then should the
message be considered as trigger message ?  Can someone confirm this for
me?

Thanks in an advance.

Hong (Julia) Liao
ATM/Broadband Network Integration
Telcordia Technologies, Inc

Tel:  (973) 829-4570
Fax: (973) 829-5962





From owner-mpls@UU.NET  Mon Mar 10 16:43:49 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15678
	for <mpls-archive@lists.ietf.org>; Mon, 10 Mar 2003 16:43:49 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoflv23782
	for <mpls-archive@lists.ietf.org>; Mon, 10 Mar 2003 21:45:56 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoflv23548;
	Mon, 10 Mar 2003 21:45:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoflt07972
	for mpls-outgoing; Mon, 10 Mar 2003 21:20:20 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoflt07965
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Mar 2003 21:20:11 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoflt05702
	for <mpls@uu.net>; Mon, 10 Mar 2003 21:17:07 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoflt05147
	for <mpls@uu.net>; Mon, 10 Mar 2003 21:17:06 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoflt05134
	for <mpls@uu.net>; Mon, 10 Mar 2003 21:17:06 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2ALH3Sc024871
	for <mpls@uu.net>; Mon, 10 Mar 2003 16:17:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA16746 for <mpls@uu.net>; Mon, 10 Mar 2003 16:17:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2ALH2512142 for mpls@uu.net; Mon, 10 Mar 2003 16:17:02 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofls07289
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Mar 2003 21:14:23 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofls20420
	for <mpls@UU.NET>; Mon, 10 Mar 2003 21:14:08 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofls10948
	for <mpls@UU.NET>; Mon, 10 Mar 2003 21:14:08 GMT
Received: from w2k04exg01.ciena.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: LIN1-118-38-40.ciena.com [63.118.38.40])
	id QQofls10939
	for <mpls@UU.NET>; Mon, 10 Mar 2003 21:14:07 GMT
Received: by w2k04exg01.ciena.com with Internet Mail Service (5.5.2653.19)
	id <GPDY9CLB>; Mon, 10 Mar 2003 16:12:49 -0500
Received: from w2ksjexg01.ciena.com (W2KSJEXG01 [10.34.31.33]) by w2k07exg01.ciena.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id GPQJF499; Mon, 10 Mar 2003 16:13:52 -0500
Received: from ciena.com (PPAN [10.34.77.170]) by w2ksjexg01.ciena.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id GVR608NQ; Mon, 10 Mar 2003 13:13:34 -0800
Message-ID: <3E6D000E.5030009@ciena.com>
Date: Mon, 10 Mar 2003 13:13:50 -0800
From: Ping Pan <ppan@ciena.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en, zh
MIME-Version: 1.0
To: Hong Liao <hliao@telcordia.com>
CC: mpls@UU.NET
Subject: Re: Question for the RFC2961--Refresh reduction--trigger msg
References: <OF81A781DD.4CD696EA-ON85256CE5.005ADE7F@cc.telcordia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hong Liao wrote:
> Hi,
> 
> I have question for the trigger message.
> 
> In the RFC2961,section 4.5,
> 
> 
>>>When a node is sending a trigger message, the Message_Identifier value
>>
> MUST have a value that is greater than any other value previously used with
> the same Epoch field value.
> 
> so basically if it is a trigger message then message id should be greater
> than previous one with the same epoch value;but does this mean that if the
> message id is greater than previous one for the same epoch value, and the
> rest of the contents are the same as the previous message, then should the
> message be considered as trigger message ?  Can someone confirm this for
> me?
> 

Hi,

A couple of points:

1. What qualify as a trigger message on a receiving node?

The idea of refresh reduction is to avoid looking at the content of the 
message. Thus by looking at the message-id, the epoch value, and 
RSVP-hop (that is, incoming interface, RSVP phop address), if there is 
no match to your local table, this is a trigger message. Process the 
message in detail.

2. Why incremental message-id's?

For mis-ordering. When processing a message that carries a message-id, 
from SESSION and SENDER_TEMPLATE, find the flow entry first. If the flow 
entry records a message-id greater than what you have received, don't 
process the message - because this is an old junk. (Actually, I didn't 
see this condition in a customer's test net.)

To make sure you are OK with the msg-id roll-over, the routers always 
change to a new epoch number and start to assign messag-id from a small 
value again.

Hope this will help.

- Ping



From owner-mpls@UU.NET  Mon Mar 10 17:50:08 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18200
	for <mpls-archive@lists.ietf.org>; Mon, 10 Mar 2003 17:50:08 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoflz22318
	for <mpls-archive@lists.ietf.org>; Mon, 10 Mar 2003 22:52:15 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoflz22175;
	Mon, 10 Mar 2003 22:52:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoflx00495
	for mpls-outgoing; Mon, 10 Mar 2003 22:26:43 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoflx00490
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Mar 2003 22:26:30 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoflx13796
	for <mpls@UU.NET>; Mon, 10 Mar 2003 22:26:20 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoflx28783
	for <mpls@UU.NET>; Mon, 10 Mar 2003 22:26:19 GMT
Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQoflx28769
	for <mpls@UU.NET>; Mon, 10 Mar 2003 22:26:19 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA13253;
	Mon, 10 Mar 2003 17:26:16 -0500 (EST)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA22971;
	Mon, 10 Mar 2003 17:26:18 -0500 (EST)
Message-ID: <3E6D1141.5010202@marconi.com>
Date: Mon, 10 Mar 2003 17:27:13 -0500
From: David Charlap <David.Charlap@marconi.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210
X-Accept-Language: en-us, en, he
MIME-Version: 1.0
To: Ping Pan <ppan@ciena.com>
CC: Hong Liao <hliao@telcordia.com>, mpls@UU.NET
Subject: Re: Question for the RFC2961--Refresh reduction--trigger msg
References: <OF81A781DD.4CD696EA-ON85256CE5.005ADE7F@cc.telcordia.com> <3E6D000E.5030009@ciena.com>
In-Reply-To: <3E6D000E.5030009@ciena.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Ping Pan wrote:
> 
> To make sure you are OK with the msg-id roll-over, the routers always 
> change to a new epoch number and start to assign messag-id from a small 
> value again.

I'm not sure I understand you here.

When do they always change to a new epoch number?  When the value hits 
the maximum?  Or at some other time.

I don't recall this being a requirement.  The requirement that I saw was 
that routers must be able to detect and support rollover.  A code 
fragment was provided to show developers exactly how to do this, so 
there shouldn't be any excuse for a router that doesn't detect this.

-- David



From owner-mpls@UU.NET  Mon Mar 10 17:59:26 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18483
	for <mpls-archive@lists.ietf.org>; Mon, 10 Mar 2003 17:59:26 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofma01100
	for <mpls-archive@lists.ietf.org>; Mon, 10 Mar 2003 23:01:34 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofma00901;
	Mon, 10 Mar 2003 23:01:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofly00953
	for mpls-outgoing; Mon, 10 Mar 2003 22:35:44 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofly00948
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Mar 2003 22:35:40 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofly05026
	for <mpls@uu.net>; Mon, 10 Mar 2003 22:34:10 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofly09123
	for <mpls@uu.net>; Mon, 10 Mar 2003 22:34:09 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQofly09057
	for <mpls@uu.net>; Mon, 10 Mar 2003 22:34:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2AMY1vD027984
	for <mpls@uu.net>; Mon, 10 Mar 2003 17:34:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA23524 for <mpls@uu.net>; Mon, 10 Mar 2003 17:34:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2AMY1S18664 for mpls@uu.net; Mon, 10 Mar 2003 17:34:01 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofly00807
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Mar 2003 22:31:30 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofly04075
	for <mpls@UU.NET>; Mon, 10 Mar 2003 22:31:17 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofly19998
	for <mpls@UU.NET>; Mon, 10 Mar 2003 22:31:16 GMT
Received: from w2k04exg01.ciena.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: LIN1-118-38-40.ciena.com [63.118.38.40])
	id QQofly19994
	for <mpls@UU.NET>; Mon, 10 Mar 2003 22:31:16 GMT
Received: by w2k04exg01.ciena.com with Internet Mail Service (5.5.2653.19)
	id <GPDY9C85>; Mon, 10 Mar 2003 17:29:58 -0500
Received: from w2ksjexg01.ciena.com (W2KSJEXG01 [10.34.31.33]) by w2k07exg01.ciena.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id GPQJFXVA; Mon, 10 Mar 2003 17:30:59 -0500
Received: from ciena.com (PPAN [10.34.77.170]) by w2ksjexg01.ciena.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id GVR60039; Mon, 10 Mar 2003 14:30:41 -0800
Message-ID: <3E6D1222.3060201@ciena.com>
Date: Mon, 10 Mar 2003 14:30:58 -0800
From: Ping Pan <ppan@ciena.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en, zh
MIME-Version: 1.0
To: David Charlap <David.Charlap@marconi.com>
CC: mpls@UU.NET
Subject: Re: Question for the RFC2961--Refresh reduction--trigger msg
References: <OF81A781DD.4CD696EA-ON85256CE5.005ADE7F@cc.telcordia.com> <3E6D000E.5030009@ciena.com> <3E6D1141.5010202@marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

David Charlap wrote:
> Ping Pan wrote:
> 
>>
>> To make sure you are OK with the msg-id roll-over, the routers always 
>> change to a new epoch number and start to assign messag-id from a 
>> small value again.
> 
> 
> I'm not sure I understand you here.
> 
> When do they always change to a new epoch number?  When the value hits 
> the maximum?  Or at some other time.
>

When it is approaching the max. for rollover.




From owner-mpls@UU.NET  Mon Mar 10 18:50:30 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21238
	for <mpls-archive@lists.ietf.org>; Mon, 10 Mar 2003 18:50:30 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofmd25131
	for <mpls-archive@lists.ietf.org>; Mon, 10 Mar 2003 23:52:38 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofmd24816;
	Mon, 10 Mar 2003 23:52:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofmb23539
	for mpls-outgoing; Mon, 10 Mar 2003 23:27:22 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofmb23534
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Mar 2003 23:27:19 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQofmb19104
	for <mpls@UU.NET>; Mon, 10 Mar 2003 23:27:09 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofmb00545
	for <mpls@UU.NET>; Mon, 10 Mar 2003 23:27:09 GMT
Received: from dnsmx1rrc.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41])
	id QQofmb00539
	for <mpls@UU.NET>; Mon, 10 Mar 2003 23:27:09 GMT
Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6])
	by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id SAA22125;
	Mon, 10 Mar 2003 18:26:27 -0500 (EST)
Subject: Re: Question for the RFC2961--Refresh reduction--trigger msg
To: Ping Pan <ppan@ciena.com>
Cc: Hong Liao <hliao@telcordia.com>, mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF7FF44E93.454C5FDE-ON85256CE5.00805A20@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Mon, 10 Mar 2003 18:26:26 -0500
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 03/10/2003 06:26:27 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


So you tried to say that as  far as the msgid is  greater than the previous
one with the same epoch, it does not  matter if the other content is the
same  as the one before, it is considered  to be a trigger msg.

or as far as the epoch value is different,  it does not matter if the other
contents in the message are the same  as the  one before, it is considered
as  a  trigger msg, right?

Thanks,
Julia


                                                                                                            
                    Ping Pan                                                                                
                    <ppan@ciena.c        To:     Hong Liao <hliao@telcordia.com>                            
                    om>                  cc:     mpls@UU.NET, (bcc: Hong Liao/Telcordia)                    
                                         Subject:     Re: Question for the RFC2961--Refresh                 
                    03/10/2003           reduction--trigger msg                                             
                    04:13 PM                                                                                
                                                                                                            
                                                                                                            





Hong Liao wrote:
> Hi,
>
> I have question for the trigger message.
>
> In the RFC2961,section 4.5,
>
>
>>>When a node is sending a trigger message, the Message_Identifier value
>>
> MUST have a value that is greater than any other value previously used
with
> the same Epoch field value.
>
> so basically if it is a trigger message then message id should be greater
> than previous one with the same epoch value;but does this mean that if
the
> message id is greater than previous one for the same epoch value, and the
> rest of the contents are the same as the previous message, then should
the
> message be considered as trigger message ?  Can someone confirm this for
> me?
>

Hi,

A couple of points:

1. What qualify as a trigger message on a receiving node?

The idea of refresh reduction is to avoid looking at the content of the
message. Thus by looking at the message-id, the epoch value, and
RSVP-hop (that is, incoming interface, RSVP phop address), if there is
no match to your local table, this is a trigger message. Process the
message in detail.

2. Why incremental message-id's?

For mis-ordering. When processing a message that carries a message-id,
from SESSION and SENDER_TEMPLATE, find the flow entry first. If the flow
entry records a message-id greater than what you have received, don't
process the message - because this is an old junk. (Actually, I didn't
see this condition in a customer's test net.)

To make sure you are OK with the msg-id roll-over, the routers always
change to a new epoch number and start to assign messag-id from a small
value again.

Hope this will help.

- Ping





From owner-mpls@UU.NET  Mon Mar 10 19:47:31 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22491
	for <mpls-archive@lists.ietf.org>; Mon, 10 Mar 2003 19:47:31 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofmh10026
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 00:49:39 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofmh09816;
	Tue, 11 Mar 2003 00:49:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofmf13927
	for mpls-outgoing; Tue, 11 Mar 2003 00:24:22 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQofmf13922
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Mar 2003 00:24:18 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQofmf28671
	for <mpls@uu.net>; Tue, 11 Mar 2003 00:23:29 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofmf21276
	for <mpls@uu.net>; Tue, 11 Mar 2003 00:23:28 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQofmf21272
	for <mpls@uu.net>; Tue, 11 Mar 2003 00:23:28 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA14640
	for <mpls@uu.net>; Mon, 10 Mar 2003 19:23:26 -0500 (EST)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA01271
	for <mpls@uu.net>; Mon, 10 Mar 2003 19:23:27 -0500 (EST)
Message-ID: <3E6D2CB7.6040109@marconi.com>
Date: Mon, 10 Mar 2003 19:24:23 -0500
From: David Charlap <David.Charlap@marconi.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210
X-Accept-Language: en-us, en, he
MIME-Version: 1.0
To: IETF MPLS List <mpls@UU.NET>
Subject: Re: Question for the RFC2961--Refresh reduction--trigger msg
References: <OF7FF44E93.454C5FDE-ON85256CE5.00805A20@cc.telcordia.com>
In-Reply-To: <OF7FF44E93.454C5FDE-ON85256CE5.00805A20@cc.telcordia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hong Liao wrote:
> So you tried to say that as  far as the msgid is  greater than the previous
> one with the same epoch, it does not  matter if the other content is the
> same  as the one before, it is considered  to be a trigger msg.
> 
> or as far as the epoch value is different,  it does not matter if the other
> contents in the message are the same  as the  one before, it is considered
> as  a  trigger msg, right?

No.  Quite the opposite.

If the epoch is the same, and the message ID is lower than the most 
recent one received for the LSP, then it the message is out of order and 
should be ignored - meaning it is definitely not a trigger.

If the message ID is greater, or if the epoch is different, then you 
have to compare the rest of the message's content against your saved 
state to determine if the message is a trigger or not.

-- David



From owner-mpls@UU.NET  Tue Mar 11 05:52:10 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15517
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 05:52:10 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofnv21542
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 10:54:18 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofnv21387;
	Tue, 11 Mar 2003 10:54:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofnt23086
	for mpls-outgoing; Tue, 11 Mar 2003 10:28:49 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQofnt23081
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Mar 2003 10:28:45 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofnt23622
	for <mpls@UU.NET>; Tue, 11 Mar 2003 10:28:37 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofnt05344
	for <mpls@UU.NET>; Tue, 11 Mar 2003 10:28:37 GMT
Received: from exchub.albacom.it by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pascal.albacom.it [212.17.194.155])
	id QQofnt05337
	for <mpls@UU.NET>; Tue, 11 Mar 2003 10:28:36 GMT
Received: by EXCHUB with Internet Mail Service (5.5.2655.55)
	id <1AZC2BCX>; Tue, 11 Mar 2003 11:28:36 +0100
Message-ID: <0EEDEC14A2D1854280B3964BC76375087E55EB@a3sv002r.albacom.it>
From: Rossi Francesco <Francesco.Rossi@albacom.it>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: DisSubscribe
Date: Tue, 11 Mar 2003 11:28:30 +0100
X-Mailer: Internet Mail Service (5.5.2655.55)
Sender: owner-mpls@UU.NET
Precedence: bulk

DisSubscribe




From owner-mpls@UU.NET  Tue Mar 11 06:14:36 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15897
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 06:14:36 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofnx29076
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 11:16:44 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofnx28775;
	Tue, 11 Mar 2003 11:16:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofnv25052
	for mpls-outgoing; Tue, 11 Mar 2003 10:51:07 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQofnv24897
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Mar 2003 10:50:48 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofnv20898
	for <mpls@UU.NET>; Tue, 11 Mar 2003 10:50:07 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofnv28813
	for <mpls@UU.NET>; Tue, 11 Mar 2003 10:50:06 GMT
Received: from smtp.tedata.net by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: smtp.tedata.net [212.103.160.188])
	id QQofnv28766
	for <mpls@UU.NET>; Tue, 11 Mar 2003 10:50:05 GMT
Received: (qmail 618 invoked from network); 11 Mar 2003 10:50:03 -0000
Received: from unknown (HELO EG1OPW2K082.tedata.net) (212.103.165.202)
  by 0 with SMTP; 11 Mar 2003 10:50:03 -0000
Message-Id: <5.1.1.6.0.20030311124817.01b4cd10@212.103.160.18>
X-Sender: azyousef@212.103.160.18
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Tue, 11 Mar 2003 12:48:48 +0200
To: "'mpls@UU.NET'" <mpls@UU.NET>
From: Azza Yousef <azza.yousef@tedata.net>
Subject: DisSubscribe
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

DisSubscribe


Best Regards,
Azza Mikhail Yousef
Networks Engineer
T.E-Data
Tel: +202 - 7494025
Ext: 1122



From owner-mpls@UU.NET  Tue Mar 11 11:10:00 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25060
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 11:09:59 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofoq08816
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 16:12:06 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofoq08289;
	Tue, 11 Mar 2003 16:11:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofom08759
	for mpls-outgoing; Tue, 11 Mar 2003 15:03:06 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQofom08397
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Mar 2003 15:03:02 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQofom25437
	for <mpls@uu.net>; Tue, 11 Mar 2003 15:02:40 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofom02626
	for <mpls@uu.net>; Tue, 11 Mar 2003 15:02:40 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQofom02594
	for <mpls@uu.net>; Tue, 11 Mar 2003 15:02:39 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2BF2avD018315
	for <mpls@uu.net>; Tue, 11 Mar 2003 10:02:36 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA10136 for <mpls@uu.net>; Tue, 11 Mar 2003 10:02:35 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2BF2ZF07178 for mpls@uu.net; Tue, 11 Mar 2003 10:02:35 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofkj19480
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Mar 2003 12:25:59 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofkj26010
	for <mpls@uu.net>; Mon, 10 Mar 2003 12:25:04 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofkj15770
	for <mpls@uu.net>; Mon, 10 Mar 2003 12:25:04 GMT
Received: from mailrelay1.alcatel.de by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailrelay2.alcatel.de [194.113.59.71])
	id QQofkj15738
	for <mpls@uu.net>; Mon, 10 Mar 2003 12:25:03 GMT
Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10])
	by mailrelay1.alcatel.de (8.9.3/8.9.3) with ESMTP id NAA06360;
	Mon, 10 Mar 2003 13:23:55 +0100 (MET)
Received: from slsv7at ([149.204.245.107] helo=slsv7a.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 18sMKO-0005AP-00; Mon, 10 Mar 2003 13:24:24 +0100
Received: from sls5gi ([149.204.30.7] helo=alcatel.de) by slsv7a.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 18sMKN-0001Qp-00; Mon, 10 Mar 2003 13:24:23 +0100
Message-ID: <3E6C83E6.F94C0CD0@alcatel.de>
Date: Mon, 10 Mar 2003 13:24:06 +0100
From: Gert Grammel <Gert.Grammel@alcatel.de>
Organization: Alcatel TND Product Strategy
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en,de
MIME-Version: 1.0
To: curtis@fictitious.org
CC: Mark.Jones@mail.sprint.com, ccamp@ops.ietf.org, dwfedyk@nortelnetworks.com,
        gash@att.com, mpls@UU.NET
Subject: Re: {Possible Spam} Re: I-D 
 ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <200303070151.UAA40792@workhorse.fictitious.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Curtis,

you've wrote:

     It would be best if ITU members go off and waste their own time
     pursuing ASON capabilities, just as the ATM Forum went off and wasted
     their time on Q.2931 capability in UNI 3.x, 4.x, ...

and I don't agree with that. In my view it would be best if ITU-T members were
able to understand and accept the ideas behind GMPLS and would provide valuable
input to bring this work forward.

Regards

Gert


Curtis Villamizar wrote:

> Coments inline.
>
> In message <3E679FB5.542FBF09@alcatel.de>, Gert Grammel writes:
> >
> > 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 (agai n informational) in IETF which do not comply to
> >      the purity of RSVP-TE. Due t o 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 solutio n on how to proceed. What I've seen so far was a complete
> > misperception of what i s 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 networkin g 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)
>
> SDH/SONET bandwidth on demand has never been deployed.  There is
> serious question about whether this is a viable service.  The
> technology has existed for about a decade (a little less maybe) for
> provide ATM SVC service doing essentially the same thing.  Market
> penetration after a decade is very close to zero for SVC.  Market
> penetration for ATM SPVC/PVC is small and may be shrinking.  The FR
> market seems to be shrinking as well.  FR SVC market is zero.
> SDH/SONET does not have the bandwidth on demand capability but there
> is ample evidence that implementing it would be a waste of time.
>
> ASON is a requirements document from ITU that assumes the SDH/SONET
> BOND is a viable service.  This is an enormous leap of faith given the
> trends in the market.  The IETF doesn't buy into it.
>
> And yes, most of us are familiar with SS7 and the whole SCP/STP AIN
> mess, so if you want to extend TCAP to support ASON, go right ahead.
> We in the IETF would get a real good laugh over that.
>
> >   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.
>
> Initially IP and voice ran over TDM.  The bandwidth demands of IP were
> much less than voice a decade ago.  As IP penetration grew roughly
> exponentially through the early, mid, and most of the late 1990s, this
> reversed and IP consumed far more bandwidth than voice.  Switched
> services also grew but at a slower rate and in the late 1990s
> experienced negative growth for many SPs.  One factor may have been
> notable outages in FR (US nationwide one day at one major provider and
> intermittent for 10 days in another a few years later) shot a big hole
> in the "much more reliable than IP" story.
>
> Initially MPLS served as traffic enginnering strictly for IP.  With IP
> still growing substantially, voice growing very slowly (and losing
> revenue) and switched services growing slowly to shrinking, there was
> motivation to carry voice, switched services, and leased line services
> over the IP and/or MPLS infrastructure and decommission older
> SDH/SONET ADM and FR or ATM switches.  This led to the tunneling work.
>
> Another factor which led to GMPLS was the (unrealized) promise/hype of
> optical switching in the very late 1990s.  IP over an ATM overlay was
> a poor design and IP providers did not want to repeat that mistake so
> the control of the underlying optical domain was accommodated by what
> has evolved into GMPLS.  GMPLS was extended to accommodate TDM in
> addition to FSC, LSC and PSC.
>
> > 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.
>
> ASON was never accepted by the IETF as requirements and for very good
> reason.  To say that IETF must accept the ASON requirements simply
> because they came in a liason statement and that the IETF must
> accommodate this ITU folly is absurd.
>
> > 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 .
>
> Regardless of how this was handled in Yokohama, some of the
> fundamental premise of ASON is flawed.  It would be best if ITU
> members go off and waste their own time pursuing ASON capabilities,
> just as the ATM Forum went off and wasted their time on Q.2931
> capability in UNI 3.x, 4.x, but ITU should do so without extending
> protocols which originated in the IETF.
>
> > 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
>
> I look forward to seeing the IETF come up with a formal statement of
> liason policy.  It would be useful to have explicitly documented that
> liason statements carry no more weight than any individual
> internet-draft submission.
>
> Curtis

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de




From owner-mpls@UU.NET  Tue Mar 11 11:18:52 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25599
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 11:18:52 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofor21653
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 16:20:59 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofor20469;
	Tue, 11 Mar 2003 16:20:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofom12340
	for mpls-outgoing; Tue, 11 Mar 2003 15:06:43 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQofom12312
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Mar 2003 15:06:38 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofom09741
	for <mpls@UU.NET>; Tue, 11 Mar 2003 15:06:13 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofom13384
	for <mpls@UU.NET>; Tue, 11 Mar 2003 15:06:12 GMT
Received: from dnsmx2pya.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32])
	id QQofom13366
	for <mpls@UU.NET>; Tue, 11 Mar 2003 15:06:12 GMT
Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6])
	by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id KAA20980;
	Tue, 11 Mar 2003 10:04:22 -0500 (EST)
Subject: Re: Question for the RFC2961--Refresh reduction--trigger msg
To: David Charlap <David.Charlap@marconi.com>
Cc: IETF MPLS List <mpls@UU.NET>
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OFA6809078.500A73E9-ON85256CE6.0051B7BD@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Tue, 11 Mar 2003 09:54:31 -0500
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 03/11/2003 10:04:24 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


>>If the message ID is greater, or if the epoch is different, then you
have to compare the rest of the message's content against your saved
state to determine if the message is a trigger or not.

So If the message ID is greater, or if the epoch is different, ,and the
LSPID is different from the previous one, then the msg is trigger msg,
right/

Thanks,
Julia


                                                                                                                
                    David Charlap                                                                               
                    <David.Charlap@ma        To:     IETF MPLS List <mpls@UU.NET>                               
                    rconi.com>               cc:     (bcc: Hong Liao/Telcordia)                                 
                                             Subject:     Re: Question for the RFC2961--Refresh                 
                    03/10/2003 07:24         reduction--trigger msg                                             
                    PM                                                                                          
                                                                                                                
                                                                                                                





Hong Liao wrote:
> So you tried to say that as  far as the msgid is  greater than the
previous
> one with the same epoch, it does not  matter if the other content is the
> same  as the one before, it is considered  to be a trigger msg.
>
> or as far as the epoch value is different,  it does not matter if the
other
> contents in the message are the same  as the  one before, it is
considered
> as  a  trigger msg, right?

No.  Quite the opposite.

If the epoch is the same, and the message ID is lower than the most
recent one received for the LSP, then it the message is out of order and
should be ignored - meaning it is definitely not a trigger.

If the message ID is greater, or if the epoch is different, then you
have to compare the rest of the message's content against your saved
state to determine if the message is a trigger or not.

-- David






From owner-mpls@UU.NET  Tue Mar 11 11:20:23 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25650
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 11:20:22 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofor24198
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 16:22:30 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofor23591;
	Tue, 11 Mar 2003 16:22:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofom12369
	for mpls-outgoing; Tue, 11 Mar 2003 15:06:49 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQofom12344
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Mar 2003 15:06:44 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofom05243
	for <mpls@uu.net>; Tue, 11 Mar 2003 15:05:07 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofom12011
	for <mpls@uu.net>; Tue, 11 Mar 2003 15:05:05 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQofom11994
	for <mpls@uu.net>; Tue, 11 Mar 2003 15:05:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2BF52Sc009945
	for <mpls@uu.net>; Tue, 11 Mar 2003 10:05:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA10366 for <mpls@uu.net>; Tue, 11 Mar 2003 10:05:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2BF52x07317 for mpls@uu.net; Tue, 11 Mar 2003 10:05:02 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofom11336
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Mar 2003 15:03:59 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofom12950
	for <mpls@UU.NET>; Tue, 11 Mar 2003 15:03:27 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofom09373
	for <mpls@UU.NET>; Tue, 11 Mar 2003 15:03:26 GMT
Received: from kcmso2.proxy.att.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: kcmso2.att.com [192.128.134.71])
	id QQofom09344
	for <mpls@UU.NET>; Tue, 11 Mar 2003 15:03:25 GMT
Received: from attrh3i.attrh.att.com ([135.71.62.12])
	by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h2BElvHM023764
	for <mpls@UU.NET>; Tue, 11 Mar 2003 09:03:24 -0600 (CST)
Received: from OCCLUST03EVS1.ugd.att.com (135.71.164.10) by attrh3i.attrh.att.com (6.5.032)
        id 3E637D6700671416; Tue, 11 Mar 2003 10:03:20 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Tue, 11 Mar 2003 10:03:19 -0500
Message-ID: <35BD167AAD17F34F84B265D79518556704072EDE@OCCLUST03EVS1.ugd.att.com>
Thread-Topic: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Thread-Index: AcLm/0Dqrjae9vR5T56ncJGy5NUpSAA3QkUQ
From: "Lazer, Monica A, ALABS" <mlazer@att.com>
To: "Gert Grammel" <Gert.Grammel@alcatel.de>
Cc: <Mark.Jones@mail.sprint.com>, <ccamp@ops.ietf.org>,
        <dwfedyk@nortelnetworks.com>,
        "Ash, Gerald R (Jerry), ALABS" <gash@att.com>, <mpls@UU.NET>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA25650

Gert,
I have some comments, inline, below. The short of it is that I don't
agree with your perspective.
In my view, the main issue is not about taking sides in these debates,
but about what is bringing more value to a carrier's network. 

Monica A. Lazer
Network Architecture and Reliability
 
908 234 8462
mlazer@att.com

-----Original Message-----
From: Gert Grammel [mailto:Gert.Grammel@alcatel.de]
Sent: Monday, March 10, 2003 7:19 AM
To: Lazer, Monica A, ALABS
Cc: Mark.Jones@mail.sprint.com; ccamp@ops.ietf.org;
dwfedyk@nortelnetworks.com; Ash, Gerald R (Jerry), ALABS; mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Monica,

I think there were lots of discussions about what is best for layer XYZ
and also
Neil was arguing in this direction. This argumentation is of course
valid if you
focus on layer XYZ and look for a (new) control plane. Let's name it a
classical
ASON point ov view. What I tried to raise as an issue is, that from a
CCAMP
point of view the question is the other way round. You have already a
control
plane defined and the question is: how to apply it in the best way to
layer XYZ?
There is an issue about what is the main backwards compatibility issue
here, I guess. From the ccamp perspective, it seems to be compatibility
with the defined GMPLS work. From the network perspective, however, it
means compatibility with how the transport network works. It may indeed
be an issue of priorities.
So coming back to your argument. You've said correctly:

     ... while when going from HO to LO one is within the same paradigm.

One conclusion could be: you should use the same Control Plane paradigm
for
different layers in order to let them interoperate seamlessly. First it
needs to support each layer!
 Further more, scalability becomes a very real issue 
To sum up a bit: in my view all the discussion about features of ASON
and/or
GMPLS is flawed right from the beginning if it is not clear what should
be
achieved: 

  1. If you focus on a single paradigm arcoss layers you should consider
GMPLS
     with all its features and limitations
Why must one take things with limitations, what is wrong with
improvements?
The control plane focus is on saving operations cost for the given
layer! 

  2. If you are interesting on getting some specialized control planes
for
     SDH/SONET you are free to choose anything.

in ITU-T you have the choice, in IETF you have not. Do you really mean
this?? That seems to be a flawed attitude. Saying that in ietf there is
no choice, or room for improvements (your point above about accepting
all its limitations) seems to be a serious judgment call on this forum.
Are you saying that one should not even bother with problem statements
or requirements? 
 For sure the choice is not
between transport and packet technology, the choice is your focus.

Regards

Gert


"Lazer, Monica A, ALABS" wrote:

> 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
> mlazer@att.com
>
> -----Original Message-----
> From: Gert Grammel [mailto:Gert.Grammel@alcatel.de]
> Sent: Thursday, March 06, 2003 3:38 PM
> To: Mark.Jones@mail.sprint.com
> Cc: ccamp@ops.ietf.org; dwfedyk@nortelnetworks.com; Ash, Gerald R
> (Jerry), ALABS; mpls@UU.NET
> 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
>
> Mark.Jones@mail.sprint.com 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
> > Optical Transport and Networking
> > Sprint - Wireline Technology Development
> > 913-794-2139
> >
> >
> > -----Original Message-----
> > From: Gert.Grammel [mailto:Gert.Grammel@alcatel.de]
> > Sent: Thursday, March 06, 2003 1:21 PM
> > To: Mark.Jones
> > Cc: ccamp; dwfedyk; gash; mpls
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> > 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
> >
> > Mark.Jones@mail.sprint.com 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
> > > Optical Transport and Networking
> > > Sprint - Wireline Technology Development
> > > 913-794-2139
> > >
> > >
> > > -----Original Message-----
> > > From: Gert.Grammel [mailto:Gert.Grammel@alcatel.de]
> > > Sent: Thursday, March 06, 2003 10:17 AM
> > > To: Mark.Jones
> > > Cc: dwfedyk; gash; ccamp; mpls
> > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > >
> > > 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
> > >
> > > Mark.Jones@mail.sprint.com 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
> > > > 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
> > > > Optical Transport and Networking
> > > > Sprint - Wireline Technology Development
> > > > 913-794-2139
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: dwfedyk [mailto:dwfedyk@nortelnetworks.com]
> > > > Sent: Thursday, March 06, 2003 7:49 AM
> > > > To: gash
> > > > Cc: mpls; ccamp
> > > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > > >
> > > > 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
> > >
> > > --
> > > Alcatel Optical Network Division    Gert Grammel
> > > Network Strategy                    phone: +49 711 821 47368
> > > Lorenzstrasse 10                    fax: +49 711 821 43169
> > > D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de
> >
> > --
> > Alcatel Optical Network Division    Gert Grammel
> > Network Strategy                    phone: +49 711 821 47368
> > Lorenzstrasse 10                    fax: +49 711 821 43169
> > D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de
>
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de



From owner-mpls@UU.NET  Tue Mar 11 11:22:39 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25733
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 11:22:39 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofor27275
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 16:24:46 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofor26823;
	Tue, 11 Mar 2003 16:24:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofom13070
	for mpls-outgoing; Tue, 11 Mar 2003 15:11:51 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofom13065
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Mar 2003 15:11:50 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofom08367
	for <mpls@UU.NET>; Tue, 11 Mar 2003 15:11:44 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofom19794
	for <mpls@UU.NET>; Tue, 11 Mar 2003 15:11:43 GMT
Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQofom19785
	for <mpls@UU.NET>; Tue, 11 Mar 2003 15:11:43 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA26748
	for <mpls@UU.NET>; Tue, 11 Mar 2003 10:11:41 -0500 (EST)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA29560
	for <mpls@UU.NET>; Tue, 11 Mar 2003 10:11:42 -0500 (EST)
Message-ID: <3E6DFCE8.3000403@marconi.com>
Date: Tue, 11 Mar 2003 10:12:40 -0500
From: David Charlap <David.Charlap@marconi.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210
X-Accept-Language: en-us, en, he
MIME-Version: 1.0
To: IETF MPLS List <mpls@UU.NET>
Subject: Re: Question for the RFC2961--Refresh reduction--trigger msg
References: <OFA6809078.500A73E9-ON85256CE6.0051B7BD@cc.telcordia.com>
In-Reply-To: <OFA6809078.500A73E9-ON85256CE6.0051B7BD@cc.telcordia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hong Liao wrote:
>> If the message ID is greater, or if the epoch is different, then you
>> have to compare the rest of the message's content against your saved
>> state to determine if the message is a trigger or not.
> 
> So If the message ID is greater, or if the epoch is different, ,and the
> LSPID is different from the previous one, then the msg is trigger msg,
> right/

If the message ID is greater, or the epoch is different, then the 
message MIGHT be a trigger.  You still have to look up the LSP and 
compare its state against the rest of the message in order to see if 
anything significant has changed.

If the LSPID is different, then the message applies to some other LSP 
and the entire argument is moot.

-- David



From owner-mpls@UU.NET  Tue Mar 11 11:22:53 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25762
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 11:22:52 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofor27691
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 16:25:00 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofor27131;
	Tue, 11 Mar 2003 16:24:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofom12570
	for mpls-outgoing; Tue, 11 Mar 2003 15:09:43 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQofom12565
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Mar 2003 15:09:31 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofom11931
	for <mpls@UU.NET>; Tue, 11 Mar 2003 15:09:19 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofom19421
	for <mpls@UU.NET>; Tue, 11 Mar 2003 15:09:19 GMT
Received: from thurn.corp.titan.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: thurn.corp.titan.com [159.62.51.20])
	id QQofom19389
	for <mpls@UU.NET>; Tue, 11 Mar 2003 15:09:18 GMT
Received: from vcmd-nt1.validity.com (val114-005.validity.titan.com [159.62.114.5])
	by thurn.corp.titan.com (8.12.8/8.12.8) with ESMTP id h2BF7rEJ013297;
	Tue, 11 Mar 2003 07:07:53 -0800
Received: by VCMD-NT1 with Internet Mail Service (5.5.2655.55)
	id <1J0RK5X8>; Tue, 11 Mar 2003 10:07:12 -0500
Message-ID: <561621C69F17D511A3A20050047340EC01AAF5EB@VCMD-NT1>
From: "Ferrell, William" <William.Ferrell@titan.com>
To: "'Gert Grammel '" <Gert.Grammel@alcatel.de>,
        "'curtis@fictitious.org '"
	 <curtis@fictitious.org>
Cc: "'Mark.Jones@mail.sprint.com '" <Mark.Jones@mail.sprint.com>,
        "'ccamp@ops.ietf.org '" <ccamp@ops.ietf.org>,
        "'dwfedyk@nortelnetworks.com '" <dwfedyk@nortelnetworks.com>,
        "'gash@att.com '" <gash@att.com>, "'mpls@UU.NET '" <mpls@UU.NET>
Subject: RE: {Possible Spam} Re: I-D  ACTION:draft-andersson-mpls-g-chng-p
	roc-00.txt
Date: Tue, 11 Mar 2003 10:07:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

 Gert / All

 I am Will Ferrell of Titan working at DISA on an MPLS security 
project. I have worked with Barry Raveendran Greene (Cisco) on a major DISA
ACL project of which he provided invaluable guidance/support/ tech reference
that led to the projects success.


Ive checked RFC's 2547,3036,2702 et. al.  It appears that there isnt a lot
of interest in securing MPLS. Can you refer me to other work for MPLS
security requirements and all phases of MPLS security to include secure
implementation. 

> > > 
> > >William Ferrell 
> > >Information Assurance Eng. CCNP 
> > >Titan Corp. 
> > >703-882-2474 



-----Original Message-----
From: Gert Grammel
To: curtis@fictitious.org
Cc: Mark.Jones@mail.sprint.com; ccamp@ops.ietf.org;
dwfedyk@nortelnetworks.com; gash@att.com; mpls@UU.NET
Sent: 3/10/03 7:24 AM
Subject: Re: {Possible Spam} Re: I-D
ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Curtis,

you've wrote:

     It would be best if ITU members go off and waste their own time
     pursuing ASON capabilities, just as the ATM Forum went off and
wasted
     their time on Q.2931 capability in UNI 3.x, 4.x, ...

and I don't agree with that. In my view it would be best if ITU-T
members were
able to understand and accept the ideas behind GMPLS and would provide
valuable
input to bring this work forward.

Regards

Gert


Curtis Villamizar wrote:

> Coments inline.
>
> In message <3E679FB5.542FBF09@alcatel.de>, Gert Grammel writes:
> >
> > 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 (agai n informational) in IETF which do not comply to
> >      the purity of RSVP-TE. Due t o 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 solutio n on how to proceed. What I've seen so far was a complete
> > misperception of what i s 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 networkin g 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)
>
> SDH/SONET bandwidth on demand has never been deployed.  There is
> serious question about whether this is a viable service.  The
> technology has existed for about a decade (a little less maybe) for
> provide ATM SVC service doing essentially the same thing.  Market
> penetration after a decade is very close to zero for SVC.  Market
> penetration for ATM SPVC/PVC is small and may be shrinking.  The FR
> market seems to be shrinking as well.  FR SVC market is zero.
> SDH/SONET does not have the bandwidth on demand capability but there
> is ample evidence that implementing it would be a waste of time.
>
> ASON is a requirements document from ITU that assumes the SDH/SONET
> BOND is a viable service.  This is an enormous leap of faith given the
> trends in the market.  The IETF doesn't buy into it.
>
> And yes, most of us are familiar with SS7 and the whole SCP/STP AIN
> mess, so if you want to extend TCAP to support ASON, go right ahead.
> We in the IETF would get a real good laugh over that.
>
> >   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.
>
> Initially IP and voice ran over TDM.  The bandwidth demands of IP were
> much less than voice a decade ago.  As IP penetration grew roughly
> exponentially through the early, mid, and most of the late 1990s, this
> reversed and IP consumed far more bandwidth than voice.  Switched
> services also grew but at a slower rate and in the late 1990s
> experienced negative growth for many SPs.  One factor may have been
> notable outages in FR (US nationwide one day at one major provider and
> intermittent for 10 days in another a few years later) shot a big hole
> in the "much more reliable than IP" story.
>
> Initially MPLS served as traffic enginnering strictly for IP.  With IP
> still growing substantially, voice growing very slowly (and losing
> revenue) and switched services growing slowly to shrinking, there was
> motivation to carry voice, switched services, and leased line services
> over the IP and/or MPLS infrastructure and decommission older
> SDH/SONET ADM and FR or ATM switches.  This led to the tunneling work.
>
> Another factor which led to GMPLS was the (unrealized) promise/hype of
> optical switching in the very late 1990s.  IP over an ATM overlay was
> a poor design and IP providers did not want to repeat that mistake so
> the control of the underlying optical domain was accommodated by what
> has evolved into GMPLS.  GMPLS was extended to accommodate TDM in
> addition to FSC, LSC and PSC.
>
> > 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.
>
> ASON was never accepted by the IETF as requirements and for very good
> reason.  To say that IETF must accept the ASON requirements simply
> because they came in a liason statement and that the IETF must
> accommodate this ITU folly is absurd.
>
> > 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 .
>
> Regardless of how this was handled in Yokohama, some of the
> fundamental premise of ASON is flawed.  It would be best if ITU
> members go off and waste their own time pursuing ASON capabilities,
> just as the ATM Forum went off and wasted their time on Q.2931
> capability in UNI 3.x, 4.x, but ITU should do so without extending
> protocols which originated in the IETF.
>
> > 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
>
> I look forward to seeing the IETF come up with a formal statement of
> liason policy.  It would be useful to have explicitly documented that
> liason statements carry no more weight than any individual
> internet-draft submission.
>
> Curtis

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de



From owner-mpls@UU.NET  Tue Mar 11 11:33:34 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26380
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 11:33:33 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofos21848
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 16:35:41 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofos21642;
	Tue, 11 Mar 2003 16:35:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofoo15298
	for mpls-outgoing; Tue, 11 Mar 2003 15:35:52 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofoo15284
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Mar 2003 15:35:36 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofoo19678
	for <mpls@UU.NET>; Tue, 11 Mar 2003 15:35:10 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofoo20436
	for <mpls@UU.NET>; Tue, 11 Mar 2003 15:35:09 GMT
Received: from thurn.corp.titan.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: thurn.corp.titan.com [159.62.51.20])
	id QQofoo20410
	for <mpls@UU.NET>; Tue, 11 Mar 2003 15:35:08 GMT
Received: from vcmd-nt1.validity.com (val114-005.validity.titan.com [159.62.114.5])
	by thurn.corp.titan.com (8.12.8/8.12.8) with ESMTP id h2BFYlEJ015321;
	Tue, 11 Mar 2003 07:34:49 -0800
Received: by VCMD-NT1 with Internet Mail Service (5.5.2655.55)
	id <1J0RK5Z0>; Tue, 11 Mar 2003 10:34:07 -0500
Message-ID: <561621C69F17D511A3A20050047340EC01AAF5EE@VCMD-NT1>
From: "Ferrell, William" <William.Ferrell@titan.com>
To: "'Ping Pan '" <ppan@ciena.com>, "'Hong Liao '" <hliao@telcordia.com>
Cc: "'mpls@UU.NET '" <mpls@UU.NET>
Subject: RE: Question for the RFC2961--Refresh reduction--trigger msg
Date: Tue, 11 Mar 2003 10:34:06 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

 
Ping  

Hello , I am Will Ferrell of Titan working at DISA on an MPLS security 
project. I have worked with Barry Green (Cisco) on a major DISA ACL project
of which he provided invaluable guidance/support/ tech reference that led to
the projects success.

Ive checked RFC's 2547,3036,2702 et. al.  It appears that there isnt a lot
of interest in securing MPLS. Can you refer me to other work for MPLS
security requirements and all phases of MPLS security to include secure
implementation. 

> > >William Ferrell 
> > >Information Assurance Eng. CCNP 
> > >Titan Corp. 
> > >703-882-2474 


-----Original Message-----
From: Ping Pan
To: Hong Liao
Cc: mpls@UU.NET
Sent: 3/10/03 4:13 PM
Subject: Re: Question for the RFC2961--Refresh reduction--trigger msg

Hong Liao wrote:
> Hi,
> 
> I have question for the trigger message.
> 
> In the RFC2961,section 4.5,
> 
> 
>>>When a node is sending a trigger message, the Message_Identifier
value
>>
> MUST have a value that is greater than any other value previously used
with
> the same Epoch field value.
> 
> so basically if it is a trigger message then message id should be
greater
> than previous one with the same epoch value;but does this mean that if
the
> message id is greater than previous one for the same epoch value, and
the
> rest of the contents are the same as the previous message, then should
the
> message be considered as trigger message ?  Can someone confirm this
for
> me?
> 

Hi,

A couple of points:

1. What qualify as a trigger message on a receiving node?

The idea of refresh reduction is to avoid looking at the content of the 
message. Thus by looking at the message-id, the epoch value, and 
RSVP-hop (that is, incoming interface, RSVP phop address), if there is 
no match to your local table, this is a trigger message. Process the 
message in detail.

2. Why incremental message-id's?

For mis-ordering. When processing a message that carries a message-id, 
from SESSION and SENDER_TEMPLATE, find the flow entry first. If the flow

entry records a message-id greater than what you have received, don't 
process the message - because this is an old junk. (Actually, I didn't 
see this condition in a customer's test net.)

To make sure you are OK with the msg-id roll-over, the routers always 
change to a new epoch number and start to assign messag-id from a small 
value again.

Hope this will help.

- Ping


From owner-mpls@UU.NET  Tue Mar 11 11:39:21 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26599
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 11:39:21 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofos16066
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 16:41:29 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofos15854;
	Tue, 11 Mar 2003 16:41:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofop17160
	for mpls-outgoing; Tue, 11 Mar 2003 15:50:51 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofop17154
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Mar 2003 15:50:42 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofop13541
	for <mpls@UU.NET>; Tue, 11 Mar 2003 15:49:53 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofop00010
	for <mpls@UU.NET>; Tue, 11 Mar 2003 15:49:52 GMT
Received: from bgslc03.burtongroup.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host3.burtongroup.com [63.99.125.3] (may be forged))
	id QQofop29986
	for <mpls@UU.NET>; Tue, 11 Mar 2003 15:49:52 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: {Possible Spam} Re: I-D  ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Tue, 11 Mar 2003 08:49:51 -0700
Message-ID: <53BBA8839E91D51194D200902728944E01D2EF73@bgslc03.burtongroup.com>
Thread-Topic: {Possible Spam} Re: I-D  ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Thread-Index: AcLn4avpPln6UzjZTRizrUJCVv84+gAA8TSQ
From: "Irwin Lazar" <ILazar@burtongroup.com>
To: "Ferrell, William" <William.Ferrell@titan.com>
Cc: <ccamp@ops.ietf.org>, <mpls@UU.NET>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA26599

There are a few drafts on the topic:

http://www.ietf.org/internet-drafts/draft-behringer-mpls-security-03.txt

http://www.ietf.org/internet-drafts/draft-tsenevir-smpls-02.txt


Also see: Cisco MPLS based VPNs: Equivalent to the security of Frame Relay and ATM - available at www.miercom.com

Irwin

> -----Original Message-----
> From: Ferrell, William [mailto:William.Ferrell@titan.com]
> Sent: Tuesday, March 11, 2003 10:07 AM
> To: 'Gert Grammel '; 'curtis@fictitious.org '
> Cc: 'Mark.Jones@mail.sprint.com '; 'ccamp@ops.ietf.org ';
> 'dwfedyk@nortelnetworks.com '; 'gash@att.com '; 'mpls@UU.NET '
> Subject: RE: {Possible Spam} Re: I-D
> ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
>  Gert / All
> 
>  I am Will Ferrell of Titan working at DISA on an MPLS security 
> project. I have worked with Barry Raveendran Greene (Cisco) 
> on a major DISA
> ACL project of which he provided invaluable guidance/support/ 
> tech reference
> that led to the projects success.
> 
> 
> Ive checked RFC's 2547,3036,2702 et. al.  It appears that 
> there isnt a lot
> of interest in securing MPLS. Can you refer me to other work for MPLS
> security requirements and all phases of MPLS security to 
> include secure
> implementation. 
> 
> > > > 
> > > >William Ferrell 
> > > >Information Assurance Eng. CCNP 
> > > >Titan Corp. 
> > > >703-882-2474 
> 
> 
> 
> -----Original Message-----
> From: Gert Grammel
> To: curtis@fictitious.org
> Cc: Mark.Jones@mail.sprint.com; ccamp@ops.ietf.org;
> dwfedyk@nortelnetworks.com; gash@att.com; mpls@UU.NET
> Sent: 3/10/03 7:24 AM
> Subject: Re: {Possible Spam} Re: I-D
> ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> Curtis,
> 
> you've wrote:
> 
>      It would be best if ITU members go off and waste their own time
>      pursuing ASON capabilities, just as the ATM Forum went off and
> wasted
>      their time on Q.2931 capability in UNI 3.x, 4.x, ...
> 
> and I don't agree with that. In my view it would be best if ITU-T
> members were
> able to understand and accept the ideas behind GMPLS and would provide
> valuable
> input to bring this work forward.
> 
> Regards
> 
> Gert
> 
> 
> Curtis Villamizar wrote:
> 
> > Coments inline.
> >
> > In message <3E679FB5.542FBF09@alcatel.de>, Gert Grammel writes:
> > >
> > > 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 (agai n informational) in IETF which do not 
> comply to
> > >      the purity of RSVP-TE. Due t o 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 solutio n on how to proceed. What I've seen so far was 
> a complete
> > > misperception of what i s 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 networkin g 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)
> >
> > SDH/SONET bandwidth on demand has never been deployed.  There is
> > serious question about whether this is a viable service.  The
> > technology has existed for about a decade (a little less maybe) for
> > provide ATM SVC service doing essentially the same thing.  Market
> > penetration after a decade is very close to zero for SVC.  Market
> > penetration for ATM SPVC/PVC is small and may be shrinking.  The FR
> > market seems to be shrinking as well.  FR SVC market is zero.
> > SDH/SONET does not have the bandwidth on demand capability but there
> > is ample evidence that implementing it would be a waste of time.
> >
> > ASON is a requirements document from ITU that assumes the SDH/SONET
> > BOND is a viable service.  This is an enormous leap of 
> faith given the
> > trends in the market.  The IETF doesn't buy into it.
> >
> > And yes, most of us are familiar with SS7 and the whole SCP/STP AIN
> > mess, so if you want to extend TCAP to support ASON, go right ahead.
> > We in the IETF would get a real good laugh over that.
> >
> > >   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.
> >
> > Initially IP and voice ran over TDM.  The bandwidth demands 
> of IP were
> > much less than voice a decade ago.  As IP penetration grew roughly
> > exponentially through the early, mid, and most of the late 
> 1990s, this
> > reversed and IP consumed far more bandwidth than voice.  Switched
> > services also grew but at a slower rate and in the late 1990s
> > experienced negative growth for many SPs.  One factor may have been
> > notable outages in FR (US nationwide one day at one major 
> provider and
> > intermittent for 10 days in another a few years later) shot 
> a big hole
> > in the "much more reliable than IP" story.
> >
> > Initially MPLS served as traffic enginnering strictly for 
> IP.  With IP
> > still growing substantially, voice growing very slowly (and losing
> > revenue) and switched services growing slowly to shrinking, 
> there was
> > motivation to carry voice, switched services, and leased 
> line services
> > over the IP and/or MPLS infrastructure and decommission older
> > SDH/SONET ADM and FR or ATM switches.  This led to the 
> tunneling work.
> >
> > Another factor which led to GMPLS was the (unrealized) 
> promise/hype of
> > optical switching in the very late 1990s.  IP over an ATM 
> overlay was
> > a poor design and IP providers did not want to repeat that 
> mistake so
> > the control of the underlying optical domain was 
> accommodated by what
> > has evolved into GMPLS.  GMPLS was extended to accommodate TDM in
> > addition to FSC, LSC and PSC.
> >
> > > 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.
> >
> > ASON was never accepted by the IETF as requirements and for 
> very good
> > reason.  To say that IETF must accept the ASON requirements simply
> > because they came in a liason statement and that the IETF must
> > accommodate this ITU folly is absurd.
> >
> > > 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 .
> >
> > Regardless of how this was handled in Yokohama, some of the
> > fundamental premise of ASON is flawed.  It would be best if ITU
> > members go off and waste their own time pursuing ASON capabilities,
> > just as the ATM Forum went off and wasted their time on Q.2931
> > capability in UNI 3.x, 4.x, but ITU should do so without extending
> > protocols which originated in the IETF.
> >
> > > 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
> >
> > I look forward to seeing the IETF come up with a formal statement of
> > liason policy.  It would be useful to have explicitly 
> documented that
> > liason statements carry no more weight than any individual
> > internet-draft submission.
> >
> > Curtis
> 
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de
> 
> 


From owner-mpls@UU.NET  Tue Mar 11 11:39:59 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26641
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 11:39:59 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofos29744
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 16:42:07 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofos29471;
	Tue, 11 Mar 2003 16:41:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofop17438
	for mpls-outgoing; Tue, 11 Mar 2003 15:53:35 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQofop17430
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Mar 2003 15:53:17 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofop16849
	for <mpls@uu.net>; Tue, 11 Mar 2003 15:53:07 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofop04188
	for <mpls@uu.net>; Tue, 11 Mar 2003 15:53:06 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQofop04172
	for <mpls@uu.net>; Tue, 11 Mar 2003 15:53:06 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2BFr2Sc019478
	for <mpls@uu.net>; Tue, 11 Mar 2003 10:53:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA15488 for <mpls@uu.net>; Tue, 11 Mar 2003 10:53:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2BFr2b14414 for mpls@uu.net; Tue, 11 Mar 2003 10:53:02 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQofop17054
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Mar 2003 15:49:09 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofop22212
	for <mpls@uu.net>; Tue, 11 Mar 2003 15:47:40 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofop08782
	for <mpls@uu.net>; Tue, 11 Mar 2003 15:47:39 GMT
Received: from mailrelay2.alcatel.de by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailrelay1.alcatel.de [194.113.59.75])
	id QQofop08766
	for <mpls@uu.net>; Tue, 11 Mar 2003 15:47:38 GMT
Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10])
	by mailrelay2.alcatel.de (8.9.3/8.9.3) with ESMTP id QAA13733;
	Tue, 11 Mar 2003 16:46:15 +0100 (MET)
Received: from slsv7at ([149.204.245.107] helo=slsv7a.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 18slyL-0007KB-00; Tue, 11 Mar 2003 16:47:21 +0100
Received: from sls5gi ([149.204.30.7] helo=alcatel.de) by slsv7a.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 18slyL-0006XS-00; Tue, 11 Mar 2003 16:47:21 +0100
Message-ID: <3E6E0508.D3ED7892@alcatel.de>
Date: Tue, 11 Mar 2003 16:47:20 +0100
From: Gert Grammel <Gert.Grammel@alcatel.de>
Organization: Alcatel TND Product Strategy
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en,de
MIME-Version: 1.0
To: "Lazer, Monica A, ALABS" <mlazer@att.com>
CC: Mark.Jones@mail.sprint.com, ccamp@ops.ietf.org, dwfedyk@nortelnetworks.com,
        "Ash, Gerald R (Jerry), ALABS" <gash@att.com>, mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <35BD167AAD17F34F84B265D79518556704072EDE@OCCLUST03EVS1.ugd.att.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Monica,

there is nothing wrong with improving a solution. The key is to know where to
start and where to go.
You may agree that CCAMP had another starting point than ITU-T/ASON.  However my
feeling is, that even this issue is not really understood by many of the folks
out there. If there is no acceptance that priorities in another SDO is different
from the own one, we won't come to an agreement at any time soon.
Look at the hottest issue under discussion: We are talking a lot about UNI
features like call/connection separation. Neither Mark nor Neil see the UNI
becoming service relevant at any time soon - so why is it under discussion right
now? Is this your priority 1 issue in ITU-T? Is Mark or Neil in a minority
position in ITU-T? Referring to the Yokohama Meeting this was basically
Kireeti's request: Please explain what you need and for what purpose.

What I am trying to achieve is to make the priorities transparent such that
either side can see where is the difference and where is the overlap. Otherwise
we will endlessly continue to discuss about feature requirements and whether
they seem to be relevant or not.

In short I repeat my previous statement using some of your own words:

     In my view, the main issue <snip> is about what is bringing more value
     to a carrier's network:

        * a single Control Plane Paradigm not optimized for a specific
          Layer or
        * a variety of control plane paradigms optimized for specific Layer
          needs

Regards

Gert


"Lazer, Monica A, ALABS" wrote:

> Gert,
> I have some comments, inline, below. The short of it is that I don't
> agree with your perspective.
> In my view, the main issue is not about taking sides in these debates,
> but about what is bringing more value to a carrier's network.
>
> Monica A. Lazer
> Network Architecture and Reliability
>
> 908 234 8462
> mlazer@att.com
>
> -----Original Message-----
> From: Gert Grammel [mailto:Gert.Grammel@alcatel.de]
> Sent: Monday, March 10, 2003 7:19 AM
> To: Lazer, Monica A, ALABS
> Cc: Mark.Jones@mail.sprint.com; ccamp@ops.ietf.org;
> dwfedyk@nortelnetworks.com; Ash, Gerald R (Jerry), ALABS; mpls@UU.NET
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> Monica,
>
> I think there were lots of discussions about what is best for layer XYZ
> and also
> Neil was arguing in this direction. This argumentation is of course
> valid if you
> focus on layer XYZ and look for a (new) control plane. Let's name it a
> classical
> ASON point ov view. What I tried to raise as an issue is, that from a
> CCAMP
> point of view the question is the other way round. You have already a
> control
> plane defined and the question is: how to apply it in the best way to
> layer XYZ?
> There is an issue about what is the main backwards compatibility issue
> here, I guess. From the ccamp perspective, it seems to be compatibility
> with the defined GMPLS work. From the network perspective, however, it
> means compatibility with how the transport network works. It may indeed
> be an issue of priorities.
> So coming back to your argument. You've said correctly:
>
>      ... while when going from HO to LO one is within the same paradigm.
>
> One conclusion could be: you should use the same Control Plane paradigm
> for
> different layers in order to let them interoperate seamlessly. First it
> needs to support each layer!
>  Further more, scalability becomes a very real issue
> To sum up a bit: in my view all the discussion about features of ASON
> and/or
> GMPLS is flawed right from the beginning if it is not clear what should
> be
> achieved:
>
>   1. If you focus on a single paradigm arcoss layers you should consider
> GMPLS
>      with all its features and limitations
> Why must one take things with limitations, what is wrong with
> improvements?
> The control plane focus is on saving operations cost for the given
> layer!
>
>   2. If you are interesting on getting some specialized control planes
> for
>      SDH/SONET you are free to choose anything.
>
> in ITU-T you have the choice, in IETF you have not. Do you really mean
> this?? That seems to be a flawed attitude. Saying that in ietf there is
> no choice, or room for improvements (your point above about accepting
> all its limitations) seems to be a serious judgment call on this forum.
> Are you saying that one should not even bother with problem statements
> or requirements?
>  For sure the choice is not
> between transport and packet technology, the choice is your focus.
>
> Regards
>
> Gert
>
> "Lazer, Monica A, ALABS" wrote:
>
> > 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
> > mlazer@att.com
> >
> > -----Original Message-----
> > From: Gert Grammel [mailto:Gert.Grammel@alcatel.de]
> > Sent: Thursday, March 06, 2003 3:38 PM
> > To: Mark.Jones@mail.sprint.com
> > Cc: ccamp@ops.ietf.org; dwfedyk@nortelnetworks.com; Ash, Gerald R
> > (Jerry), ALABS; mpls@UU.NET
> > 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
> >
> > Mark.Jones@mail.sprint.com 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
> > > Optical Transport and Networking
> > > Sprint - Wireline Technology Development
> > > 913-794-2139
> > >
> > >
> > > -----Original Message-----
> > > From: Gert.Grammel [mailto:Gert.Grammel@alcatel.de]
> > > Sent: Thursday, March 06, 2003 1:21 PM
> > > To: Mark.Jones
> > > Cc: ccamp; dwfedyk; gash; mpls
> > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > >
> > > 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
> > >
> > > Mark.Jones@mail.sprint.com 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
> > > > Optical Transport and Networking
> > > > Sprint - Wireline Technology Development
> > > > 913-794-2139
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Gert.Grammel [mailto:Gert.Grammel@alcatel.de]
> > > > Sent: Thursday, March 06, 2003 10:17 AM
> > > > To: Mark.Jones
> > > > Cc: dwfedyk; gash; ccamp; mpls
> > > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > > >
> > > > 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
> > > >
> > > > Mark.Jones@mail.sprint.com 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
> > > > > 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
> > > > > Optical Transport and Networking
> > > > > Sprint - Wireline Technology Development
> > > > > 913-794-2139
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: dwfedyk [mailto:dwfedyk@nortelnetworks.com]
> > > > > Sent: Thursday, March 06, 2003 7:49 AM
> > > > > To: gash
> > > > > Cc: mpls; ccamp
> > > > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > > > >
> > > > > 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
> > > >
> > > > --
> > > > Alcatel Optical Network Division    Gert Grammel
> > > > Network Strategy                    phone: +49 711 821 47368
> > > > Lorenzstrasse 10                    fax: +49 711 821 43169
> > > > D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de
> > >
> > > --
> > > Alcatel Optical Network Division    Gert Grammel
> > > Network Strategy                    phone: +49 711 821 47368
> > > Lorenzstrasse 10                    fax: +49 711 821 43169
> > > D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de
> >
> > --
> > Alcatel Optical Network Division    Gert Grammel
> > Network Strategy                    phone: +49 711 821 47368
> > Lorenzstrasse 10                    fax: +49 711 821 43169
> > D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de
>
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de




From owner-mpls@UU.NET  Tue Mar 11 12:13:33 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28306
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 12:13:33 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofov06220
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 17:15:41 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofov05755;
	Tue, 11 Mar 2003 17:15:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofot09714
	for mpls-outgoing; Tue, 11 Mar 2003 16:46:17 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofot09548
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Mar 2003 16:45:59 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofos12764
	for <mpls@uu.net>; Tue, 11 Mar 2003 16:43:53 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofos22967
	for <mpls@uu.net>; Tue, 11 Mar 2003 16:43:52 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQofos22962
	for <mpls@uu.net>; Tue, 11 Mar 2003 16:43:52 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2BGhnSc029465
	for <mpls@uu.net>; Tue, 11 Mar 2003 11:43:50 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA20075 for <mpls@uu.net>; Tue, 11 Mar 2003 11:43:49 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2BGhnj23165 for mpls@uu.net; Tue, 11 Mar 2003 11:43:49 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofos09087
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Mar 2003 16:42:05 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofos09159
	for <mpls@UU.NET>; Tue, 11 Mar 2003 16:41:39 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofos20935
	for <mpls@UU.NET>; Tue, 11 Mar 2003 16:41:39 GMT
Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQofos20921
	for <mpls@UU.NET>; Tue, 11 Mar 2003 16:41:38 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA75433;
	Tue, 11 Mar 2003 11:40:51 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303111640.LAA75433@workhorse.fictitious.org>
To: Gert Grammel <Gert.Grammel@alcatel.de>
cc: curtis@fictitious.org, Mark.Jones@mail.sprint.com, ccamp@ops.ietf.org,
        dwfedyk@nortelnetworks.com, gash@att.com, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: {Possible Spam} Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
In-reply-to: Your message of "Mon, 10 Mar 2003 13:24:06 +0100."
             <3E6C83E6.F94C0CD0@alcatel.de> 
Date: Tue, 11 Mar 2003 11:40:51 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <3E6C83E6.F94C0CD0@alcatel.de>, Gert Grammel writes:
> Curtis,
> 
> you've wrote:
> 
>      It would be best if ITU members go off and waste their own time
>      pursuing ASON capabilities, just as the ATM Forum went off and wasted
>      their time on Q.2931 capability in UNI 3.x, 4.x, ...
> 
> and I don't agree with that. In my view it would be best if ITU-T members
> were able to understand and accept the ideas behind GMPLS and would
> provide valuable input to bring this work forward.
> 
> Regards
> 
> Gert


I absolutely agree with your statement above.

If there is consensus in the IETF that ASON should not be considered
as a set of requirements it would also be best if ITU-T members tried
to understand why this consensus was reached rather than try to
initiate procedural changes to allow it to be jammed through
regardless of whether is makes technical sense.

Perhaps I should have qualified my statement that if ITU-T members
continue to behave as they are now doing, then "It would be best if
ITU members go off and waste their own time ...".

Curtis



From owner-mpls@UU.NET  Tue Mar 11 12:14:20 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28392
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 12:14:20 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofov04973
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 17:16:28 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofov04808;
	Tue, 11 Mar 2003 17:16:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofot09852
	for mpls-outgoing; Tue, 11 Mar 2003 16:48:42 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofot09841
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Mar 2003 16:48:32 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofot01091
	for <mpls@uu.net>; Tue, 11 Mar 2003 16:48:11 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofot28243
	for <mpls@uu.net>; Tue, 11 Mar 2003 16:48:11 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQofot28228
	for <mpls@uu.net>; Tue, 11 Mar 2003 16:48:10 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2BGm7Sc000334
	for <mpls@uu.net>; Tue, 11 Mar 2003 11:48:08 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA20448 for <mpls@uu.net>; Tue, 11 Mar 2003 11:48:06 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2BGm6X23837 for mpls@uu.net; Tue, 11 Mar 2003 11:48:06 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofot09595
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Mar 2003 16:46:07 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQofos13416
	for <mpls@UU.NET>; Tue, 11 Mar 2003 16:44:27 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofos02184
	for <mpls@UU.NET>; Tue, 11 Mar 2003 16:44:26 GMT
Received: from smtp805.mail.sc5.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: smtp805.mail.sc5.yahoo.com [66.163.168.184])
	id QQofos02178
	for <mpls@UU.NET>; Tue, 11 Mar 2003 16:44:26 GMT
Received: from adsl-66-127-240-73.dsl.sntc01.pacbell.net (HELO ciena.com) (pingpan999@66.127.240.73 with plain)
  by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 11 Mar 2003 16:44:25 -0000
Message-ID: <3E6E1269.9020905@ciena.com>
Date: Tue, 11 Mar 2003 08:44:25 -0800
From: Ping Pan <ppan@ciena.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Ferrell, William" <William.Ferrell@titan.com>
CC: "'mpls@UU.NET '" <mpls@UU.NET>
Subject: Re: Question for the RFC2961--Refresh reduction--trigger msg
References: <561621C69F17D511A3A20050047340EC01AAF5EE@VCMD-NT1>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

As for MPLS security, a customer had told me one incident on their 
network: they had received a storm of new RSVP Path messages from 
nowhere, and caused a lot of LSP's to be established. Based on that 
information, I would think you need to get that RFC on RSVP-MD5 working. 
IMHO, you need to take care of spoofing and DOS.

Hope this will help.

- Ping

Ferrell, William wrote:
>  
> Ive checked RFC's 2547,3036,2702 et. al.  It appears that there isnt a lot
> of interest in securing MPLS. Can you refer me to other work for MPLS
> security requirements and all phases of MPLS security to include secure
> implementation. 
> 
> 
>>>>William Ferrell 
>>>>Information Assurance Eng. CCNP 
>>>>Titan Corp. 
>>>>703-882-2474 
>>>



From owner-mpls@UU.NET  Tue Mar 11 12:45:58 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29364
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 12:45:58 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofox06446
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 17:48:06 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofox06122;
	Tue, 11 Mar 2003 17:47:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofov01069
	for mpls-outgoing; Tue, 11 Mar 2003 17:22:21 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQofov01044
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Mar 2003 17:22:14 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofov16133
	for <mpls@UU.NET>; Tue, 11 Mar 2003 17:21:58 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofov02629
	for <mpls@UU.NET>; Tue, 11 Mar 2003 17:21:58 GMT
Received: from dnsmx1pya.telcordia.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31])
	id QQofov02614
	for <mpls@UU.NET>; Tue, 11 Mar 2003 17:21:57 GMT
Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6])
	by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id MAA15469;
	Tue, 11 Mar 2003 12:21:05 -0500 (EST)
Subject: Re: Question for the RFC2961--Refresh reduction--trigger msg
To: David Charlap <David.Charlap@marconi.com>
Cc: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF7BF62D5C.0FDC8DE4-ON85256CE6.005BEE21@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Tue, 11 Mar 2003 12:21:06 -0500
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 03/11/2003 12:21:07 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


Please help me  with the three questions:

.>>If the message ID is greater, or the epoch is different, then the
message MIGHT be a trigger.  You still have to look up the LSP and
compare its state against the rest of the message in order to see if
anything significant has changed.

[1] If the message ID is greater, or the epoch is different,  and the LSP
and
 the rest of the message are  the same, Do   you still  consider this msg
a trigger msg?

Spec 1.1
<!--StartFragment-->Trigger messages are those RSVP messages that
   advertise state or any other information not previously transmitted.
   Trigger messages include messages advertising new state, a route
   change that alters a reservation path, or a modification to an
   existing RSVP session or reservation.<!--EndFragment-->

So if the LSPID is   different, and message ID is greater, or the epoch is
different, the msg is definitely trigger msg.

Spec  4.5
<!--StartFragment-->If the received Epoch values differs from the value
   previously received from the message sender, the message is a trigger
   message and the receiver MUST fully process the message.  <!
--EndFragment-->

[2]So if the LSPID is   different, and message ID is greater, or the epoch
is different in a Path msg, the msg is definitely trigger msg.
Here the 'Fully process the msg', means a Resv  msg   should be   sent
out,right?

If the message ID is greater, or the epoch is different,  and the LSP and
 the rest of the message are  the same, Do   you still  consider this msg
a trigger msg?

If the answer for the question above is YES, then
Here the 'Fully process the msg', it does not means that a Resv  msg
should be   sent  out.

[3]  If msg has the same epoch and different message id.  whether it should
be considered as trigger msg?

Thanks in  an advance.
Julia



From owner-mpls@UU.NET  Tue Mar 11 12:55:51 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29687
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 12:55:51 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofox04458
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 17:57:59 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofox04306;
	Tue, 11 Mar 2003 17:57:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofow01753
	for mpls-outgoing; Tue, 11 Mar 2003 17:32:21 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQofow01745
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Mar 2003 17:32:14 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofow25912
	for <mpls@UU.NET>; Tue, 11 Mar 2003 17:31:57 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofow11821
	for <mpls@UU.NET>; Tue, 11 Mar 2003 17:31:56 GMT
Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQofow11814
	for <mpls@UU.NET>; Tue, 11 Mar 2003 17:31:56 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA02433
	for <mpls@UU.NET>; Tue, 11 Mar 2003 12:31:54 -0500 (EST)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA22194
	for <mpls@UU.NET>; Tue, 11 Mar 2003 12:31:55 -0500 (EST)
Message-ID: <3E6E1DC5.5060908@marconi.com>
Date: Tue, 11 Mar 2003 12:32:53 -0500
From: David Charlap <David.Charlap@marconi.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210
X-Accept-Language: en-us, en, he
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Question for the RFC2961--Refresh reduction--trigger msg
References: <OF7BF62D5C.0FDC8DE4-ON85256CE6.005BEE21@cc.telcordia.com>
In-Reply-To: <OF7BF62D5C.0FDC8DE4-ON85256CE6.005BEE21@cc.telcordia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hong Liao wrote:
> 
> [1] If the message ID is greater, or the epoch is different,  and the LSP
> and the rest of the message are  the same, Do you still consider this msg
> a trigger msg?

No.  You yourself quoted the reason why:

> Spec 1.1
> <!--StartFragment-->Trigger messages are those RSVP messages that
>    advertise state or any other information not previously transmitted.
>    Trigger messages include messages advertising new state, a route
>    change that alters a reservation path, or a modification to an
>    existing RSVP session or reservation.<!--EndFragment-->

If the message is identical, then it is not advertising any new state. 
It's a simple refresh.

> So if the LSPID is different, and message ID is greater, or the epoch is
> different, the msg is definitely trigger msg.

The LSPID can never change for a given LSP.  The LSPID is part of what 
defines the LSP.

If you get a Path message, and then you get another Path which is 
completely identical, except for the LSPID, then it is a request for a 
new LSP and has absolutely nothing to do with the first LSP.

If I create LSP A, and then create LSP B, the creation of B is _NOT_ a 
modification of A.

I think you need to review what the LSPID field actually means.  You 
seem to think it's a modifiable attribute of an LSP.  It is not.

-- David



From owner-mpls@UU.NET  Tue Mar 11 13:24:09 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00616
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 13:24:08 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofoz08259
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 18:26:17 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofoz08182;
	Tue, 11 Mar 2003 18:26:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofoy09285
	for mpls-outgoing; Tue, 11 Mar 2003 18:00:52 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofoy09170
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Mar 2003 18:00:51 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQofox13710
	for <mpls@UU.NET>; Tue, 11 Mar 2003 17:59:46 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofox15653
	for <mpls@UU.NET>; Tue, 11 Mar 2003 17:59:46 GMT
Received: from hoemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail1.lucent.com [192.11.226.161])
	id QQofox15641
	for <mpls@UU.NET>; Tue, 11 Mar 2003 17:59:46 GMT
Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35])
	by hoemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2BHxiU07076
	for <mpls@UU.NET>; Tue, 11 Mar 2003 12:59:44 -0500 (EST)
Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19)
	id <1HW0SRK3>; Tue, 11 Mar 2003 12:59:44 -0500
Message-ID: <61B49BC6DA0DDE40957FB499E1835E3705FA845E@nj7460exch010u.ho.lucent.com>
From: "Varma, Eve L (Eve)" <evarma@lucent.com>
To: "'Gert Grammel'" <Gert.Grammel@alcatel.de>,
        "Lazer, Monica A, ALABS"
	 <mlazer@att.com>
Cc: Mark.Jones@mail.sprint.com, ccamp@ops.ietf.org, dwfedyk@nortelnetworks.com,
        "Ash, Gerald R (Jerry), ALABS" <gash@att.com>, mpls@UU.NET
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Tue, 11 Mar 2003 12:59:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Gert,

Just to clarify, the separation of calls and connections is useful for SPCs, not just UNI.
So it would not be appropriate to draw a conclusion re disconnects on the assumption that
call/connection separation is all about UNI.

By the way, call/connection separation was also mentioned within the ipo wg document

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


Best regards,
Eve


-----Original Message-----
From: Gert Grammel [mailto:Gert.Grammel@alcatel.de]
Sent: Tuesday, March 11, 2003 10:47 AM
To: Lazer, Monica A, ALABS
Cc: Mark.Jones@mail.sprint.com; ccamp@ops.ietf.org;
dwfedyk@nortelnetworks.com; Ash, Gerald R (Jerry), ALABS; mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt


Monica,

there is nothing wrong with improving a solution. The key is to know where to
start and where to go.
You may agree that CCAMP had another starting point than ITU-T/ASON.  However my
feeling is, that even this issue is not really understood by many of the folks
out there. If there is no acceptance that priorities in another SDO is different
from the own one, we won't come to an agreement at any time soon.
Look at the hottest issue under discussion: We are talking a lot about UNI
features like call/connection separation. Neither Mark nor Neil see the UNI
becoming service relevant at any time soon - so why is it under discussion right
now? Is this your priority 1 issue in ITU-T? Is Mark or Neil in a minority
position in ITU-T? Referring to the Yokohama Meeting this was basically
Kireeti's request: Please explain what you need and for what purpose.

What I am trying to achieve is to make the priorities transparent such that
either side can see where is the difference and where is the overlap. Otherwise
we will endlessly continue to discuss about feature requirements and whether
they seem to be relevant or not.

In short I repeat my previous statement using some of your own words:

     In my view, the main issue <snip> is about what is bringing more value
     to a carrier's network:

        * a single Control Plane Paradigm not optimized for a specific
          Layer or
        * a variety of control plane paradigms optimized for specific Layer
          needs

Regards

Gert


"Lazer, Monica A, ALABS" wrote:

> Gert,
> I have some comments, inline, below. The short of it is that I don't
> agree with your perspective.
> In my view, the main issue is not about taking sides in these debates,
> but about what is bringing more value to a carrier's network.
>
> Monica A. Lazer
> Network Architecture and Reliability
>
> 908 234 8462
> mlazer@att.com
>
> -----Original Message-----
> From: Gert Grammel [mailto:Gert.Grammel@alcatel.de]
> Sent: Monday, March 10, 2003 7:19 AM
> To: Lazer, Monica A, ALABS
> Cc: Mark.Jones@mail.sprint.com; ccamp@ops.ietf.org;
> dwfedyk@nortelnetworks.com; Ash, Gerald R (Jerry), ALABS; mpls@UU.NET
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> Monica,
>
> I think there were lots of discussions about what is best for layer XYZ
> and also
> Neil was arguing in this direction. This argumentation is of course
> valid if you
> focus on layer XYZ and look for a (new) control plane. Let's name it a
> classical
> ASON point ov view. What I tried to raise as an issue is, that from a
> CCAMP
> point of view the question is the other way round. You have already a
> control
> plane defined and the question is: how to apply it in the best way to
> layer XYZ?
> There is an issue about what is the main backwards compatibility issue
> here, I guess. From the ccamp perspective, it seems to be compatibility
> with the defined GMPLS work. From the network perspective, however, it
> means compatibility with how the transport network works. It may indeed
> be an issue of priorities.
> So coming back to your argument. You've said correctly:
>
>      ... while when going from HO to LO one is within the same paradigm.
>
> One conclusion could be: you should use the same Control Plane paradigm
> for
> different layers in order to let them interoperate seamlessly. First it
> needs to support each layer!
>  Further more, scalability becomes a very real issue
> To sum up a bit: in my view all the discussion about features of ASON
> and/or
> GMPLS is flawed right from the beginning if it is not clear what should
> be
> achieved:
>
>   1. If you focus on a single paradigm arcoss layers you should consider
> GMPLS
>      with all its features and limitations
> Why must one take things with limitations, what is wrong with
> improvements?
> The control plane focus is on saving operations cost for the given
> layer!
>
>   2. If you are interesting on getting some specialized control planes
> for
>      SDH/SONET you are free to choose anything.
>
> in ITU-T you have the choice, in IETF you have not. Do you really mean
> this?? That seems to be a flawed attitude. Saying that in ietf there is
> no choice, or room for improvements (your point above about accepting
> all its limitations) seems to be a serious judgment call on this forum.
> Are you saying that one should not even bother with problem statements
> or requirements?
>  For sure the choice is not
> between transport and packet technology, the choice is your focus.
>
> Regards
>
> Gert
>
> "Lazer, Monica A, ALABS" wrote:
>
> > 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
> > mlazer@att.com
> >
> > -----Original Message-----
> > From: Gert Grammel [mailto:Gert.Grammel@alcatel.de]
> > Sent: Thursday, March 06, 2003 3:38 PM
> > To: Mark.Jones@mail.sprint.com
> > Cc: ccamp@ops.ietf.org; dwfedyk@nortelnetworks.com; Ash, Gerald R
> > (Jerry), ALABS; mpls@UU.NET
> > 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
> >
> > Mark.Jones@mail.sprint.com 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
> > > Optical Transport and Networking
> > > Sprint - Wireline Technology Development
> > > 913-794-2139
> > >
> > >
> > > -----Original Message-----
> > > From: Gert.Grammel [mailto:Gert.Grammel@alcatel.de]
> > > Sent: Thursday, March 06, 2003 1:21 PM
> > > To: Mark.Jones
> > > Cc: ccamp; dwfedyk; gash; mpls
> > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > >
> > > 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
> > >
> > > Mark.Jones@mail.sprint.com 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
> > > > Optical Transport and Networking
> > > > Sprint - Wireline Technology Development
> > > > 913-794-2139
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Gert.Grammel [mailto:Gert.Grammel@alcatel.de]
> > > > Sent: Thursday, March 06, 2003 10:17 AM
> > > > To: Mark.Jones
> > > > Cc: dwfedyk; gash; ccamp; mpls
> > > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > > >
> > > > 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
> > > >
> > > > Mark.Jones@mail.sprint.com 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
> > > > > 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
> > > > > Optical Transport and Networking
> > > > > Sprint - Wireline Technology Development
> > > > > 913-794-2139
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: dwfedyk [mailto:dwfedyk@nortelnetworks.com]
> > > > > Sent: Thursday, March 06, 2003 7:49 AM
> > > > > To: gash
> > > > > Cc: mpls; ccamp
> > > > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > > > >
> > > > > 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
> > > >
> > > > --
> > > > Alcatel Optical Network Division    Gert Grammel
> > > > Network Strategy                    phone: +49 711 821 47368
> > > > Lorenzstrasse 10                    fax: +49 711 821 43169
> > > > D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de
> > >
> > > --
> > > Alcatel Optical Network Division    Gert Grammel
> > > Network Strategy                    phone: +49 711 821 47368
> > > Lorenzstrasse 10                    fax: +49 711 821 43169
> > > D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de
> >
> > --
> > Alcatel Optical Network Division    Gert Grammel
> > Network Strategy                    phone: +49 711 821 47368
> > Lorenzstrasse 10                    fax: +49 711 821 43169
> > D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de
>
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de




From owner-mpls@UU.NET  Tue Mar 11 14:38:57 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07055
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 14:38:57 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofpe27904
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 19:41:05 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofpe27612;
	Tue, 11 Mar 2003 19:40:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofpc16317
	for mpls-outgoing; Tue, 11 Mar 2003 19:14:32 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQofpc16275
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Mar 2003 19:14:20 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofpc24883
	for <mpls@UU.NET>; Tue, 11 Mar 2003 19:13:33 GMT
From: neil.2.harrison@bt.com
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofpc06999
	for <mpls@UU.NET>; Tue, 11 Mar 2003 19:13:32 GMT
Received: from mbibipnt08.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: saturn.bt.com [193.113.57.20])
	id QQofpc06979
	for <mpls@UU.NET>; Tue, 11 Mar 2003 19:13:32 GMT
Received: by mbibipnt08.nat.bt.com with Internet Mail Service (5.5.2653.19)
	id <FXRGCX38>; Tue, 11 Mar 2003 19:13:46 -0000
Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D65C3@i2km07-ukbr.domain1.systemhost.net>
To: Gert.Grammel@alcatel.de, mlazer@att.com
Cc: Mark.Jones@mail.sprint.com, ccamp@ops.ietf.org, dwfedyk@nortelnetworks.com,
        gash@att.com, mpls@UU.NET
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Tue, 11 Mar 2003 19:13:29 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Gert, I think some clarifications are in order here to make the BT
position (ie not just the NH position) clear.  Please see below.  regards,
Neil

Gert Grammel wrote 11 March 2003 15:47 to Monica Lazer:

<snipped>
> Look at the hottest issue under discussion: We are talking a 
> lot about UNI
> features like call/connection separation. Neither Mark nor 
> Neil see the UNI
> becoming service relevant at any time soon - so why is it 
> under discussion right
> now? Is this your priority 1 issue in ITU-T? Is Mark or Neil 
> in a minority
> position in ITU-T? Referring to the Yokohama Meeting this was 
> basically
> Kireeti's request: Please explain what you need and for what purpose.

NH=> A UNI at L1/0 is *not* something we see as important anytime soon.  We
also see no need for coupling with L2/3 (either commercially or
technically).  Thus we want to be able to choose best-of-breed functionality
for L1/0.  We *do* want call/connection separation however, and note this is
independent of the UNI...here is an extract from a colleague of mine on the
ITU lists which sort-of explains why:
"Anyone care to disagree with the notion of a call handle for SPCs in the
ITU-T as a means of bundling under one service instance a customer record
that handles
multiple connections e.g. Virtual Concatenation, with or without LCAS as a
valid application?
Anyone care to disagree that we might want to retrieve information on an SPC
using a single identifier (the call) that shows all connections associated
with that call and the performance of each connection and/or start end of
individual connections?
Anyone care to diagree that the call/connection model cannot be used for
restoration of SPCs?
As for those that want to do UNI on you go...but its not on BT priority
list."
> 
<snipped to end>


From owner-mpls@UU.NET  Tue Mar 11 15:30:53 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10996
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 15:30:53 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofpi01330
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 20:33:00 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofpi01154;
	Tue, 11 Mar 2003 20:32:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofpg23106
	for mpls-outgoing; Tue, 11 Mar 2003 20:01:33 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofpg23099
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Mar 2003 20:01:30 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofpg05958
	for <mpls@UU.NET>; Tue, 11 Mar 2003 20:00:12 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofpg15203
	for <mpls@UU.NET>; Tue, 11 Mar 2003 20:00:11 GMT
Received: from tsmtp2.mail.isp by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp.terra.es [213.4.129.129])
	id QQofpg15154
	for <mpls@UU.NET>; Tue, 11 Mar 2003 20:00:09 GMT
Received: from micasa ([80.37.133.192]) by tsmtp2.mail.isp
          (terra.es) with ESMTP id HBLOW600.56S for <mpls@UU.NET>; Tue, 11
          Mar 2003 21:00:06 +0100 
Message-ID: <004e01c2e808$d00276c0$2206c9d5@micasa>
From: "David Paraje Fillola" <dparaje@teleline.es>
To: <mpls@UU.NET>
References: <5.1.1.6.0.20030311124817.01b4cd10@212.103.160.18>
Subject: DisSubscribe
Date: Tue, 11 Mar 2003 21:00:03 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

DisSubscribe




From owner-mpls@UU.NET  Tue Mar 11 17:42:49 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15837
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 17:42:49 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofpq04938
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 22:44:57 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofpq04406;
	Tue, 11 Mar 2003 22:44:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofpp11086
	for mpls-outgoing; Tue, 11 Mar 2003 22:17:33 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofpp11079
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Mar 2003 22:17:28 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofpp23527
	for <mpls@uu.net>; Tue, 11 Mar 2003 22:17:06 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofpp05763
	for <mpls@uu.net>; Tue, 11 Mar 2003 22:17:05 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQofpp05753
	for <mpls@uu.net>; Tue, 11 Mar 2003 22:17:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2BMH2vD026257
	for <mpls@uu.net>; Tue, 11 Mar 2003 17:17:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA19136 for <mpls@uu.net>; Tue, 11 Mar 2003 17:17:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2BMH1517858 for mpls@uu.net; Tue, 11 Mar 2003 17:17:01 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofpo10589
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Mar 2003 22:14:59 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofpo19841
	for <mpls@uu.net>; Tue, 11 Mar 2003 22:14:51 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofpo16830
	for <mpls@uu.net>; Tue, 11 Mar 2003 22:14:51 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQofpo16825
	for <mpls@uu.net>; Tue, 11 Mar 2003 22:14:50 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2BMEnSc029766
	for <mpls@uu.net>; Tue, 11 Mar 2003 17:14:49 -0500 (EST)
Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA18929 for <mpls@uu.net>; Tue, 11 Mar 2003 17:14:48 -0500 (EST)
Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA13402 for <mpls@uu.net>; Tue, 11 Mar 2003 17:14:48 -0500 (EST)
Message-Id: <200303112214.RAA13402@bifocal.cisco.com>
X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs
To: mpls@UU.NET
Subject: Draft MPLS Agenda
Date: Tue, 11 Mar 2003 17:14:48 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


San Francisco                MPLS WG Agenda                    56th IETF

TUESDAY, March 18, 2002                                    Continental 6
0900-1130 


1.  Agenda bashing                                                 5 min
    
2.  Overview of ISOCORE Interoperability Tests

    Rajiv Papneja                                                 10 min

      
3.  TE related drafts

    Jean Philippe Vasseur                                         20 min
                                                    
        Reoptimization of an explicit loosely routed MPLS TE paths 
            <draft-vasseur-mpls-loose-path-reopt-01.txt> 
                                                    
        MPLS Traffic Engineering Fast reroute: bypass tunnel path 
          computation for bandwidth protection 
            <draft-vasseur-mpls-backup-computation-02.txt> 
         
        Definition of an RRO node-id subobject 
            <draft-vasseur-mpls-nodeid-subobject-00.txt> 


    Matthew Meyer                                                 10 min

        MPLS Traffic Engineering Soft preemption
            <draft-meyer-mpls-soft-preemption-00.txt>

 
4.  Graceful Restart

    Bob Thomas                                                    10 min

        LDP DoD Graceful Restart
            <draft-thomas-mpls-ldp-dod-restart-00.txt


5.  OAM

    Tom Nadeau                                                    10 min

        OAM Requirements for MPLS Networks
            <draft-nadeau-ietf-oam-requirements-01.txt

    Dave Allen                                                     5 min

        Y.1711 and LSP-PING
            <draft-allan-y1711-and-lsp-ping-00.txt>

    Kireeti Kompella                                              10 min

        Detecting MPLS Data Plane Liveness
            <draft-ietf-mpls-lsp-ping-02.txt>


6.  MIBs

    Tom Nadeau                                                    10 min

        Multiprotocol Label Switching (MPLS) Traffic Engineering 
          Management Information Base for Fast Reroute
            <draft-ietf-mpls-fastreroute-mib-01.txt

        Multiprotocol Label Switching (MPLS) Label-Controlled ATM
          and Frame-Relay Management Interface Definition
            <draft-nadeau-mpls-lc-if-mib-00.txt


7.  Explicitly routed Multicast

    Seisho Yasukawa                                               10 min

        Requirements for Point-to-Multipoint capability extension 
            <draft-yasukawa-mpls-p2mp-requirement-00.txt>

    Alan Kullberg                                                 10 min

        Extended RSVP-TE for Point-to-Multipoint LSP Tunnels
            <draft-yasukawa-mpls-rsvp-p2mp-01.txt>

    Rahul Aggarwal                                                10 min

        Multicast Traffic Engineering with MPLS
            <draft-raggarwa-mpls-mcast-te-00.txt>


8.  Header Compression

    Jerry Ash                                                     15 min

        Requirements for End-to-End VoIP Header Compression
            <draft-ash-e2e-voip-hdr-comp-rqmts-00.txt>
           
        End-to-End VoIP Header Compression Using cRTP
            <draft-ash-e2e-crtp-hdr-compress-01.txt>

        End-to-End VoIP over MPLS Header Compression
            <draft-ash-e2e-vompls-hdr-compress-01.txt>


9.  Draft Status Update

    George Swallow                                                 5 min


10. Charter Discussion                                            10 min













From owner-mpls@UU.NET  Tue Mar 11 17:50:15 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16080
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 17:50:15 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofpr19833
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 22:52:23 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofpr19307;
	Tue, 11 Mar 2003 22:52:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofpp11575
	for mpls-outgoing; Tue, 11 Mar 2003 22:25:13 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQofpp11560
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Mar 2003 22:25:11 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofpp26918
	for <mpls@uu.net>; Tue, 11 Mar 2003 22:25:08 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofpp20949
	for <mpls@uu.net>; Tue, 11 Mar 2003 22:25:07 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQofpp20894
	for <mpls@uu.net>; Tue, 11 Mar 2003 22:25:06 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2BMP3vD026860
	for <mpls@uu.net>; Tue, 11 Mar 2003 17:25:04 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA19862 for <mpls@uu.net>; Tue, 11 Mar 2003 17:25:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2BMP3f18601 for mpls@uu.net; Tue, 11 Mar 2003 17:25:03 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofpp11485
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Mar 2003 22:23:15 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofpp02354
	for <mpls@UU.NET>; Tue, 11 Mar 2003 22:22:52 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofpp00584
	for <mpls@UU.NET>; Tue, 11 Mar 2003 22:22:51 GMT
Received: from smtpgw5.sprintspectrum.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtpgw5.sprintspectrum.com [207.40.188.13])
	id QQofpp00556
	for <mpls@UU.NET>; Tue, 11 Mar 2003 22:22:51 GMT
Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com [208.10.75.139])
	by smtpgw5.sprintspectrum.com (8.12.8/8.12.8) with ESMTP id h2BMMPov013424;
	Tue, 11 Mar 2003 16:22:25 -0600 (CST)
Received: by pkcex004.sprintspectrum.com with Internet Mail Service (5.5.2654.89)
	id <17A314J2>; Tue, 11 Mar 2003 16:22:25 -0600
Message-ID: <61E1F62BC1ACDA449AA1072AEC6F544B4BBA67@PKDWB06C.ad.sprint.com>
From: "Jones, Mark L [GMG]" <Mark.Jones@mail.sprint.com>
To: "'Curtis Villamizar'" <curtis@fictitious.org>,
        Gert Grammel
	 <Gert.Grammel@alcatel.de>
Cc: ccamp@ops.ietf.org, dwfedyk@nortelnetworks.com, gash@att.com, mpls@UU.NET
Subject: RE: {Possible Spam} Re: I-D ACTION:draft-andersson-mpls-g-chng-pr
	oc-00.txt 
Date: Tue, 11 Mar 2003 16:22:20 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Curtis and Gert,

I would guess that many of us who participate mostly at the ITU-T would
support this position if it had not already proven to fail.  Many of those
at the ITU-T do understand the reasons for the IETF consensus, but they do
not believe it justifies adoption of the IETF solution for the ITU-T set of
requirements.  So, what do we do?

My guess is that the differences in scopes and points of view will always
lead to differences in opinion on what and how things should be done.  Where
a single application is being addressed, I had hoped that we could agree
between the two organizations, who should be the lead.  For most IP and IP
based protocols and applications, I think most see the IETF as the lead.
However, where L0/L1 applications are concerned, that is not the case.

The interest in refining procedures is simply a way of addressing the issue,
or maintaining a reasonable working relationship between the two groups.  I
hope your conversations at the upcoming IETF meeting help us resolve this
issue.

Regards,

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

-----Original Message-----
From: Curtis Villamizar [mailto:curtis@fictitious.org]
Sent: Tuesday, March 11, 2003 10:41 AM
To: Gert Grammel
Cc: curtis@fictitious.org; Jones, Mark L [GMG]; ccamp@ops.ietf.org;
dwfedyk@nortelnetworks.com; gash@att.com; mpls@UU.NET
Subject: Re: {Possible Spam} Re: I-D
ACTION:draft-andersson-mpls-g-chng-proc-00.txt 


[ post by non-subscriber.  with the massive amount of spam, it is easy to
miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner@ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

In message <3E6C83E6.F94C0CD0@alcatel.de>, Gert Grammel writes:
> Curtis,
> 
> you've wrote:
> 
>      It would be best if ITU members go off and waste their own time
>      pursuing ASON capabilities, just as the ATM Forum went off and wasted
>      their time on Q.2931 capability in UNI 3.x, 4.x, ...
> 
> and I don't agree with that. In my view it would be best if ITU-T members
> were able to understand and accept the ideas behind GMPLS and would
> provide valuable input to bring this work forward.
> 
> Regards
> 
> Gert


I absolutely agree with your statement above.

If there is consensus in the IETF that ASON should not be considered
as a set of requirements it would also be best if ITU-T members tried
to understand why this consensus was reached rather than try to
initiate procedural changes to allow it to be jammed through
regardless of whether is makes technical sense.

Perhaps I should have qualified my statement that if ITU-T members
continue to behave as they are now doing, then "It would be best if
ITU members go off and waste their own time ...".

Curtis





From owner-mpls@UU.NET  Tue Mar 11 23:52:11 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26108
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 23:52:10 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofqp17544
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 04:54:18 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofqp17371;
	Wed, 12 Mar 2003 04:54:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofqn28882
	for mpls-outgoing; Wed, 12 Mar 2003 04:26:36 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofqn28877
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 04:26:28 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofqn16595
	for <mpls@UU.NET>; Wed, 12 Mar 2003 04:26:22 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofqn05318
	for <mpls@UU.NET>; Wed, 12 Mar 2003 04:26:22 GMT
Received: from hotmail.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: bay1-f4.bay1.hotmail.com [65.54.245.4])
	id QQofqn05307
	for <mpls@UU.NET>; Wed, 12 Mar 2003 04:26:21 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 11 Mar 2003 20:26:20 -0800
Received: from 203.199.213.3 by by1fd.bay1.hotmail.msn.com with HTTP;
	Wed, 12 Mar 2003 04:26:20 GMT
X-Originating-IP: [203.199.213.3]
From: "Badarla Venkataramana" <vrbadarla@hotmail.com>
To: mpls@UU.NET
Subject: disSubscribe
Date: Wed, 12 Mar 2003 09:56:20 +0530
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY1-F4lb4oyXYtot4b00034b9c@hotmail.com>
X-OriginalArrivalTime: 12 Mar 2003 04:26:20.0968 (UTC) FILETIME=[887BF280:01C2E84F]
Sender: owner-mpls@UU.NET
Precedence: bulk







_________________________________________________________________
Cricket World Cup 2003- News, Views and Match Reports. 
http://server1.msn.co.in/msnspecials/worldcup03/



From owner-mpls@UU.NET  Tue Mar 11 23:56:03 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26162
	for <mpls-archive@lists.ietf.org>; Tue, 11 Mar 2003 23:56:02 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofqp21049
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 04:58:11 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofqp20267;
	Wed, 12 Mar 2003 04:57:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofqn28979
	for mpls-outgoing; Wed, 12 Mar 2003 04:29:56 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofqn28974
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 04:29:52 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofqn26117
	for <mpls@UU.NET>; Wed, 12 Mar 2003 04:29:34 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofqn26902
	for <mpls@UU.NET>; Wed, 12 Mar 2003 04:29:34 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: bay1-f154.bay1.hotmail.com [65.54.245.154])
	id QQofqn26888
	for <mpls@UU.NET>; Wed, 12 Mar 2003 04:29:33 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 11 Mar 2003 20:29:32 -0800
Received: from 203.199.213.3 by by1fd.bay1.hotmail.msn.com with HTTP;
	Wed, 12 Mar 2003 04:29:32 GMT
X-Originating-IP: [203.199.213.3]
From: "Badarla Venkataramana" <vrbadarla@hotmail.com>
To: mpls@UU.NET
Subject: DisSubscribe
Date: Wed, 12 Mar 2003 09:59:32 +0530
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY1-F1544a3Zi7Vb0j000346f0@hotmail.com>
X-OriginalArrivalTime: 12 Mar 2003 04:29:32.0867 (UTC) FILETIME=[FADD6930:01C2E84F]
Sender: owner-mpls@UU.NET
Precedence: bulk



_________________________________________________________________
Cricket World Cup 2003- News, Views and Match Reports. 
http://server1.msn.co.in/msnspecials/worldcup03/



From owner-mpls@UU.NET  Wed Mar 12 04:04:28 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26674
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 04:04:27 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofrg09612
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 09:06:35 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofrg09438;
	Wed, 12 Mar 2003 09:06:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofre00455
	for mpls-outgoing; Wed, 12 Mar 2003 08:40:56 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQofre00450
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 08:40:55 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofre03023
	for <mpls@UU.NET>; Wed, 12 Mar 2003 08:40:35 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofre18993
	for <mpls@UU.NET>; Wed, 12 Mar 2003 08:40:34 GMT
Received: from p-mail2 by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: p-mail2.rd.francetelecom.com [193.49.124.32])
	id QQofre18981
	for <mpls@UU.NET>; Wed, 12 Mar 2003 08:40:33 GMT
Received: from parsmtp1.rd.francetelecom.com ([10.193.117.128]) by p-mail2 with InterScan Messaging Security Suite; Wed, 12 Mar 2003 09:45:38 +0100
Received: from parmhs2.rd.francetelecom.fr ([10.193.117.61]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 12 Mar 2003 09:40:32 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: DisSubscribe
Date: Wed, 12 Mar 2003 09:40:31 +0100
Message-ID: <448914041F29D7499FA5F0B8ED1C708789AD8E@parmhs2.rd.francetelecom.fr>
Thread-Topic: DisSubscribe
Thread-Index: AcLoCX5IuQCMeRBnTAOzZfcj8ot+VQAaXF7A
From: "CHOU Sovatha FTRD/DAC/ISS" <sovatha.chou@rd.francetelecom.com>
To: <mpls@UU.NET>
X-OriginalArrivalTime: 12 Mar 2003 08:40:32.0492 (UTC) FILETIME=[0B19D2C0:01C2E873]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA26674

DisSubscribe


From owner-mpls@UU.NET  Wed Mar 12 05:16:26 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27949
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 05:16:26 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofrl18099
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 10:18:25 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofrl17687;
	Wed, 12 Mar 2003 10:18:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofrj24356
	for mpls-outgoing; Wed, 12 Mar 2003 09:51:46 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofrj24351
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 09:51:36 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofrj01810
	for <mpls@uu.net>; Wed, 12 Mar 2003 09:50:07 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofrj20947
	for <mpls@uu.net>; Wed, 12 Mar 2003 09:50:07 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQofrj20931
	for <mpls@uu.net>; Wed, 12 Mar 2003 09:50:06 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2C9o2vD010646
	for <mpls@uu.net>; Wed, 12 Mar 2003 04:50:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id EAA23811 for <mpls@uu.net>; Wed, 12 Mar 2003 04:50:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2C9o2J24259 for mpls@uu.net; Wed, 12 Mar 2003 04:50:02 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofrj24153
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 09:49:32 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofrj19196
	for <mpls@uu.net>; Wed, 12 Mar 2003 09:49:21 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofrj20227
	for <mpls@uu.net>; Wed, 12 Mar 2003 09:49:20 GMT
Received: from mailrelay2.alcatel.de by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailrelay1.alcatel.de [194.113.59.75])
	id QQofrj20205
	for <mpls@uu.net>; Wed, 12 Mar 2003 09:49:19 GMT
Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10])
	by mailrelay2.alcatel.de (8.9.3/8.9.3) with ESMTP id KAA05430;
	Wed, 12 Mar 2003 10:47:54 +0100 (MET)
Received: from slsv7at ([149.204.245.107] helo=slsv7a.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 18t2r7-0004xw-00; Wed, 12 Mar 2003 10:49:01 +0100
Received: from sls5gi ([149.204.30.7] helo=alcatel.de) by slsv7a.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 18t2r6-0001jN-00; Wed, 12 Mar 2003 10:49:00 +0100
Message-ID: <3E6F028B.F4026816@alcatel.de>
Date: Wed, 12 Mar 2003 10:48:59 +0100
From: Gert Grammel <Gert.Grammel@alcatel.de>
Organization: Alcatel TND Product Strategy
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en,de
MIME-Version: 1.0
To: "Varma, Eve L (Eve)" <evarma@lucent.com>
CC: "Lazer, Monica A, ALABS" <mlazer@att.com>, Mark.Jones@mail.sprint.com,
        ccamp@ops.ietf.org, dwfedyk@nortelnetworks.com,
        "Ash, Gerald R (Jerry), ALABS" <gash@att.com>, mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <61B49BC6DA0DDE40957FB499E1835E3705FA845E@nj7460exch010u.ho.lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Eve,

thank's for this comment. In the IPO document you refered to, I could only find the following
sentence as a motivator:

     To support many enhanced optical services, such as scheduled bandwidth on demand,
     diverse circuit provisioning and bundled connections, a call model based on the
     separation of call control and connection control is essential.

Probably we are in agreement when I say that from this sentence it is difficult to understand
*why* the separation is needed for these kind of services and potential others as you've
mentioned . So it could be beneficial to elaborate a bit on the question 'why is call
connection separation needed to support these kind of services'  to achieve a common
understanding and eventually agree on an implementation.

Regards

Gert

"Varma, Eve L (Eve)" wrote:

> Hi Gert,
>
> Just to clarify, the separation of calls and connections is useful for SPCs, not just UNI.
> So it would not be appropriate to draw a conclusion re disconnects on the assumption that
> call/connection separation is all about UNI.
>
> By the way, call/connection separation was also mentioned within the ipo wg document
>
> http://www.ietf.org/internet-drafts/draft-ietf-ipo-carrier-requirements-05.txt
>
> Best regards,
> Eve
>
> -----Original Message-----
> From: Gert Grammel [mailto:Gert.Grammel@alcatel.de]
> Sent: Tuesday, March 11, 2003 10:47 AM
> To: Lazer, Monica A, ALABS
> Cc: Mark.Jones@mail.sprint.com; ccamp@ops.ietf.org;
> dwfedyk@nortelnetworks.com; Ash, Gerald R (Jerry), ALABS; mpls@UU.NET
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> Monica,
>
> there is nothing wrong with improving a solution. The key is to know where to
> start and where to go.
> You may agree that CCAMP had another starting point than ITU-T/ASON.  However my
> feeling is, that even this issue is not really understood by many of the folks
> out there. If there is no acceptance that priorities in another SDO is different
> from the own one, we won't come to an agreement at any time soon.
> Look at the hottest issue under discussion: We are talking a lot about UNI
> features like call/connection separation. Neither Mark nor Neil see the UNI
> becoming service relevant at any time soon - so why is it under discussion right
> now? Is this your priority 1 issue in ITU-T? Is Mark or Neil in a minority
> position in ITU-T? Referring to the Yokohama Meeting this was basically
> Kireeti's request: Please explain what you need and for what purpose.
>
> What I am trying to achieve is to make the priorities transparent such that
> either side can see where is the difference and where is the overlap. Otherwise
> we will endlessly continue to discuss about feature requirements and whether
> they seem to be relevant or not.
>
> In short I repeat my previous statement using some of your own words:
>
>      In my view, the main issue <snip> is about what is bringing more value
>      to a carrier's network:
>
>         * a single Control Plane Paradigm not optimized for a specific
>           Layer or
>         * a variety of control plane paradigms optimized for specific Layer
>           needs
>
> Regards
>
> Gert
>
> "Lazer, Monica A, ALABS" wrote:
>
> > Gert,
> > I have some comments, inline, below. The short of it is that I don't
> > agree with your perspective.
> > In my view, the main issue is not about taking sides in these debates,
> > but about what is bringing more value to a carrier's network.
> >
> > Monica A. Lazer
> > Network Architecture and Reliability
> >
> > 908 234 8462
> > mlazer@att.com
> >
> > -----Original Message-----
> > From: Gert Grammel [mailto:Gert.Grammel@alcatel.de]
> > Sent: Monday, March 10, 2003 7:19 AM
> > To: Lazer, Monica A, ALABS
> > Cc: Mark.Jones@mail.sprint.com; ccamp@ops.ietf.org;
> > dwfedyk@nortelnetworks.com; Ash, Gerald R (Jerry), ALABS; mpls@UU.NET
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> > Monica,
> >
> > I think there were lots of discussions about what is best for layer XYZ
> > and also
> > Neil was arguing in this direction. This argumentation is of course
> > valid if you
> > focus on layer XYZ and look for a (new) control plane. Let's name it a
> > classical
> > ASON point ov view. What I tried to raise as an issue is, that from a
> > CCAMP
> > point of view the question is the other way round. You have already a
> > control
> > plane defined and the question is: how to apply it in the best way to
> > layer XYZ?
> > There is an issue about what is the main backwards compatibility issue
> > here, I guess. From the ccamp perspective, it seems to be compatibility
> > with the defined GMPLS work. From the network perspective, however, it
> > means compatibility with how the transport network works. It may indeed
> > be an issue of priorities.
> > So coming back to your argument. You've said correctly:
> >
> >      ... while when going from HO to LO one is within the same paradigm.
> >
> > One conclusion could be: you should use the same Control Plane paradigm
> > for
> > different layers in order to let them interoperate seamlessly. First it
> > needs to support each layer!
> >  Further more, scalability becomes a very real issue
> > To sum up a bit: in my view all the discussion about features of ASON
> > and/or
> > GMPLS is flawed right from the beginning if it is not clear what should
> > be
> > achieved:
> >
> >   1. If you focus on a single paradigm arcoss layers you should consider
> > GMPLS
> >      with all its features and limitations
> > Why must one take things with limitations, what is wrong with
> > improvements?
> > The control plane focus is on saving operations cost for the given
> > layer!
> >
> >   2. If you are interesting on getting some specialized control planes
> > for
> >      SDH/SONET you are free to choose anything.
> >
> > in ITU-T you have the choice, in IETF you have not. Do you really mean
> > this?? That seems to be a flawed attitude. Saying that in ietf there is
> > no choice, or room for improvements (your point above about accepting
> > all its limitations) seems to be a serious judgment call on this forum.
> > Are you saying that one should not even bother with problem statements
> > or requirements?
> >  For sure the choice is not
> > between transport and packet technology, the choice is your focus.
> >
> > Regards
> >
> > Gert
> >
> > "Lazer, Monica A, ALABS" wrote:
> >
> > > 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
> > > mlazer@att.com
> > >
> > > -----Original Message-----
> > > From: Gert Grammel [mailto:Gert.Grammel@alcatel.de]
> > > Sent: Thursday, March 06, 2003 3:38 PM
> > > To: Mark.Jones@mail.sprint.com
> > > Cc: ccamp@ops.ietf.org; dwfedyk@nortelnetworks.com; Ash, Gerald R
> > > (Jerry), ALABS; mpls@UU.NET
> > > 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
> > >
> > > Mark.Jones@mail.sprint.com 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
> > > > Optical Transport and Networking
> > > > Sprint - Wireline Technology Development
> > > > 913-794-2139
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Gert.Grammel [mailto:Gert.Grammel@alcatel.de]
> > > > Sent: Thursday, March 06, 2003 1:21 PM
> > > > To: Mark.Jones
> > > > Cc: ccamp; dwfedyk; gash; mpls
> > > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > > >
> > > > 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
> > > >
> > > > Mark.Jones@mail.sprint.com 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
> > > > > Optical Transport and Networking
> > > > > Sprint - Wireline Technology Development
> > > > > 913-794-2139
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Gert.Grammel [mailto:Gert.Grammel@alcatel.de]
> > > > > Sent: Thursday, March 06, 2003 10:17 AM
> > > > > To: Mark.Jones
> > > > > Cc: dwfedyk; gash; ccamp; mpls
> > > > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > > > >
> > > > > 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
> > > > >
> > > > > Mark.Jones@mail.sprint.com 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
> > > > > > 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
> > > > > > Optical Transport and Networking
> > > > > > Sprint - Wireline Technology Development
> > > > > > 913-794-2139
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: dwfedyk [mailto:dwfedyk@nortelnetworks.com]
> > > > > > Sent: Thursday, March 06, 2003 7:49 AM
> > > > > > To: gash
> > > > > > Cc: mpls; ccamp
> > > > > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > > > > >
> > > > > > 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
> > > > >
> > > > > --
> > > > > Alcatel Optical Network Division    Gert Grammel
> > > > > Network Strategy                    phone: +49 711 821 47368
> > > > > Lorenzstrasse 10                    fax: +49 711 821 43169
> > > > > D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de
> > > >
> > > > --
> > > > Alcatel Optical Network Division    Gert Grammel
> > > > Network Strategy                    phone: +49 711 821 47368
> > > > Lorenzstrasse 10                    fax: +49 711 821 43169
> > > > D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de
> > >
> > > --
> > > Alcatel Optical Network Division    Gert Grammel
> > > Network Strategy                    phone: +49 711 821 47368
> > > Lorenzstrasse 10                    fax: +49 711 821 43169
> > > D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de
> >
> > --
> > Alcatel Optical Network Division    Gert Grammel
> > Network Strategy                    phone: +49 711 821 47368
> > Lorenzstrasse 10                    fax: +49 711 821 43169
> > D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de
>
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de




From owner-mpls@UU.NET  Wed Mar 12 05:35:29 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28327
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 05:35:28 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofrm09416
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 10:37:36 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofrm09195;
	Wed, 12 Mar 2003 10:37:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofrk14533
	for mpls-outgoing; Wed, 12 Mar 2003 10:11:36 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofrk14527
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 10:11:33 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofrk21504
	for <mpls@uu.net>; Wed, 12 Mar 2003 10:10:20 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofrk09704
	for <mpls@uu.net>; Wed, 12 Mar 2003 10:10:19 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQofrk09693
	for <mpls@uu.net>; Wed, 12 Mar 2003 10:10:19 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2CAAFvD011761
	for <mpls@uu.net>; Wed, 12 Mar 2003 05:10:15 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id FAA24456 for <mpls@uu.net>; Wed, 12 Mar 2003 05:10:14 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2CAAEm26812 for mpls@uu.net; Wed, 12 Mar 2003 05:10:14 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofrk13558
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 10:09:09 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofrk15172
	for <mpls@uu.net>; Wed, 12 Mar 2003 10:08:12 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofrk07285
	for <mpls@uu.net>; Wed, 12 Mar 2003 10:08:12 GMT
Received: from mailrelay1.alcatel.de by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailrelay2.alcatel.de [194.113.59.71])
	id QQofrk07280
	for <mpls@uu.net>; Wed, 12 Mar 2003 10:08:11 GMT
Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10])
	by mailrelay1.alcatel.de (8.9.3/8.9.3) with ESMTP id LAA25015;
	Wed, 12 Mar 2003 11:07:28 +0100 (MET)
Received: from slsv7at ([149.204.245.107] helo=slsv7a.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 18t39R-0005Ii-00; Wed, 12 Mar 2003 11:07:57 +0100
Received: from sls5gi ([149.204.30.7] helo=alcatel.de) by slsv7a.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 18t39R-0002r3-00; Wed, 12 Mar 2003 11:07:57 +0100
Message-ID: <3E6F06FB.2362ED5C@alcatel.de>
Date: Wed, 12 Mar 2003 11:07:55 +0100
From: Gert Grammel <Gert.Grammel@alcatel.de>
Organization: Alcatel TND Product Strategy
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en,de
MIME-Version: 1.0
To: neil.2.harrison@bt.com
CC: mlazer@att.com, Mark.Jones@mail.sprint.com, ccamp@ops.ietf.org,
        dwfedyk@nortelnetworks.com, gash@att.com, mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <0536FC9B908BEC4597EE721BE6A35389025D65C3@i2km07-ukbr.domain1.systemhost.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Neil,

I think you haven't got my point about call/connection separation. Please have
also a look to my respone to Eve. There can be a discussion about
call/connection separation once there is a kind of shared view on 'why it is
needed'. In
http://www.ietf.org/internet-drafts/draft-ietf-ipo-carrier-requirements-05.txt
the only 'motivating sentence I could find was:

     To support many enhanced optical services, such as scheduled bandwidth
     on demand, diverse circuit provisioning and bundled connections, a
     call model based on the separation of call control and connection
     control is essential.

You gave some practical examples on where you see the need for that. Why not
putting it into a document and share it with everybody?

I also want to thank you to share with us your choice to go for a L0/1
functionality. This is a very clear statement.


Regards

Gert

neil.2.harrison@bt.com wrote:

> Hi Gert, I think some clarifications are in order here to make the BT
> position (ie not just the NH position) clear.  Please see below.  regards,
> Neil
>
> Gert Grammel wrote 11 March 2003 15:47 to Monica Lazer:
>
> <snipped>
> > Look at the hottest issue under discussion: We are talking a
> > lot about UNI
> > features like call/connection separation. Neither Mark nor
> > Neil see the UNI
> > becoming service relevant at any time soon - so why is it
> > under discussion right
> > now? Is this your priority 1 issue in ITU-T? Is Mark or Neil
> > in a minority
> > position in ITU-T? Referring to the Yokohama Meeting this was
> > basically
> > Kireeti's request: Please explain what you need and for what purpose.
>
> NH=> A UNI at L1/0 is *not* something we see as important anytime soon.  We
> also see no need for coupling with L2/3 (either commercially or
> technically).  Thus we want to be able to choose best-of-breed functionality
> for L1/0.  We *do* want call/connection separation however, and note this is
> independent of the UNI...here is an extract from a colleague of mine on the
> ITU lists which sort-of explains why:
> "Anyone care to disagree with the notion of a call handle for SPCs in the
> ITU-T as a means of bundling under one service instance a customer record
> that handles
> multiple connections e.g. Virtual Concatenation, with or without LCAS as a
> valid application?
> Anyone care to disagree that we might want to retrieve information on an SPC
> using a single identifier (the call) that shows all connections associated
> with that call and the performance of each connection and/or start end of
> individual connections?
> Anyone care to diagree that the call/connection model cannot be used for
> restoration of SPCs?
> As for those that want to do UNI on you go...but its not on BT priority
> list."
> >
> <snipped to end>

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de




From owner-mpls@UU.NET  Wed Mar 12 05:57:38 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29091
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 05:57:37 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofrn02483
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 10:59:45 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofrn01933;
	Wed, 12 Mar 2003 10:59:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofrm16203
	for mpls-outgoing; Wed, 12 Mar 2003 10:30:55 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQofrm16184
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 10:30:39 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofrm21887
	for <mpls@uu.net>; Wed, 12 Mar 2003 10:30:13 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofrm01531
	for <mpls@uu.net>; Wed, 12 Mar 2003 10:30:13 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQofrm01506
	for <mpls@uu.net>; Wed, 12 Mar 2003 10:30:12 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2CAU8Sc019659
	for <mpls@uu.net>; Wed, 12 Mar 2003 05:30:09 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id FAA25076 for <mpls@uu.net>; Wed, 12 Mar 2003 05:30:08 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2CAU8L00457 for mpls@uu.net; Wed, 12 Mar 2003 05:30:08 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQofrl16079
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 10:29:00 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofrl26389
	for <mpls@uu.net>; Wed, 12 Mar 2003 10:28:37 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofrl29651
	for <mpls@uu.net>; Wed, 12 Mar 2003 10:28:36 GMT
Received: from mailrelay2.alcatel.de by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailrelay1.alcatel.de [194.113.59.75])
	id QQofrl29622
	for <mpls@uu.net>; Wed, 12 Mar 2003 10:28:35 GMT
Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10])
	by mailrelay2.alcatel.de (8.9.3/8.9.3) with ESMTP id LAA14332;
	Wed, 12 Mar 2003 11:26:47 +0100 (MET)
Received: from slsv7at ([149.204.245.107] helo=slsv7a.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 18t3Sk-0005fl-00; Wed, 12 Mar 2003 11:27:54 +0100
Received: from sls5gi ([149.204.30.7] helo=alcatel.de) by slsv7a.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 18t3Sk-0003uc-00; Wed, 12 Mar 2003 11:27:54 +0100
Message-ID: <3E6F0BA8.74D057CE@alcatel.de>
Date: Wed, 12 Mar 2003 11:27:53 +0100
From: Gert Grammel <Gert.Grammel@alcatel.de>
Organization: Alcatel TND Product Strategy
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en,de
MIME-Version: 1.0
To: "Jones, Mark L [GMG]" <Mark.Jones@mail.sprint.com>
CC: "'Curtis Villamizar'" <curtis@fictitious.org>, ccamp@ops.ietf.org,
        dwfedyk@nortelnetworks.com, gash@att.com, mpls@UU.NET
Subject: Re: {Possible Spam} Re: I-D 
 ACTION:draft-andersson-mpls-g-chng-proc-00.txt
References: <61E1F62BC1ACDA449AA1072AEC6F544B4BBA67@PKDWB06C.ad.sprint.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Mark,

I feel sorry about your first sentence:

     I would guess that many of us who participate mostly at the ITU-T
     would support this position if it had not already proven to fail.

As been said in my first email, the match is 1:1 and I personally believe that
it would now be a good time for a second try. Anyhow it is good to hear that
there are some of us  thinking about how to come to a consented solution. Maybe
we don't share views on the concrete subject (In my view an SPC is an SPC
whether it is on L0/1 or L2/3, so what is *specific* there?). Anyhow I think
that this email discussion was helpful to understand where we are today and my
hope is that we were able to stimulate phantasy on both sides on how to proceed.

Best regards

Gert

"Jones, Mark L [GMG]" wrote:

> Curtis and Gert,
>
> I would guess that many of us who participate mostly at the ITU-T would
> support this position if it had not already proven to fail.  Many of those
> at the ITU-T do understand the reasons for the IETF consensus, but they do
> not believe it justifies adoption of the IETF solution for the ITU-T set of
> requirements.  So, what do we do?
>
> My guess is that the differences in scopes and points of view will always
> lead to differences in opinion on what and how things should be done.  Where
> a single application is being addressed, I had hoped that we could agree
> between the two organizations, who should be the lead.  For most IP and IP
> based protocols and applications, I think most see the IETF as the lead.
> However, where L0/L1 applications are concerned, that is not the case.
>
> The interest in refining procedures is simply a way of addressing the issue,
> or maintaining a reasonable working relationship between the two groups.  I
> hope your conversations at the upcoming IETF meeting help us resolve this
> issue.
>
> Regards,
>
> Mark Loyd Jones
> Optical Transport and Networking
> Sprint - Wireline Technology Development
> 913-794-2139
>
>
> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@fictitious.org]
> Sent: Tuesday, March 11, 2003 10:41 AM
> To: Gert Grammel
> Cc: curtis@fictitious.org; Jones, Mark L [GMG]; ccamp@ops.ietf.org;
> dwfedyk@nortelnetworks.com; gash@att.com; mpls@UU.NET
> Subject: Re: {Possible Spam} Re: I-D
> ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> [ post by non-subscriber.  with the massive amount of spam, it is easy to
> miss
>   and therefore delete posts by non-subscribers.  if you wish to regularly
>   post from an address that is not subscribed to this mailing list, send a
>   message to <listname>-owner@ops.ietf.org and ask to have the alternate
>   address added to the list of addresses from which submissions are
>   automatically accepted. ]
>
> In message <3E6C83E6.F94C0CD0@alcatel.de>, Gert Grammel writes:
> > Curtis,
> >
> > you've wrote:
> >
> >      It would be best if ITU members go off and waste their own time
> >      pursuing ASON capabilities, just as the ATM Forum went off and wasted
> >      their time on Q.2931 capability in UNI 3.x, 4.x, ...
> >
> > and I don't agree with that. In my view it would be best if ITU-T members
> > were able to understand and accept the ideas behind GMPLS and would
> > provide valuable input to bring this work forward.
> >
> > Regards
> >
> > Gert
>
> I absolutely agree with your statement above.
>
> If there is consensus in the IETF that ASON should not be considered
> as a set of requirements it would also be best if ITU-T members tried
> to understand why this consensus was reached rather than try to
> initiate procedural changes to allow it to be jammed through
> regardless of whether is makes technical sense.
>
> Perhaps I should have qualified my statement that if ITU-T members
> continue to behave as they are now doing, then "It would be best if
> ITU members go off and waste their own time ...".
>
> Curtis

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de




From owner-mpls@UU.NET  Wed Mar 12 06:06:59 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29893
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 06:06:58 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofro19745
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 11:09:07 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofro19388;
	Wed, 12 Mar 2003 11:08:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofrm17031
	for mpls-outgoing; Wed, 12 Mar 2003 10:40:04 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQofrm17020
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 10:39:58 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofrm12019
	for <mpls@UU.NET>; Wed, 12 Mar 2003 10:39:45 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofrm12140
	for <mpls@UU.NET>; Wed, 12 Mar 2003 10:39:44 GMT
Received: from smtp1.libero.it by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp1.libero.it [193.70.192.51])
	id QQofrm12123
	for <mpls@UU.NET>; Wed, 12 Mar 2003 10:39:44 GMT
Received: from libero.it (193.70.192.43) by smtp1.libero.it (6.7.015)
        id 3E68E7F100050446 for mpls@UU.NET; Wed, 12 Mar 2003 11:39:40 +0100
Date: Wed, 12 Mar 2003 11:39:40 +0100
Message-Id: <HBMTM4$875FAF0F2AFF01D1398F99ACE02AFA7C@libero.it>
Subject: =?iso-8859-1?Q?Between_OSPF_RSVP...?=
MIME-Version: 1.0
X-Sensitivity: 3
Content-Type: text/plain; charset=iso-8859-1
From: "=?iso-8859-1?Q?john151@libero.it?=" <john151@libero.it>
To: "=?iso-8859-1?Q?mpls?=" <mpls@UU.NET>
X-XaM3-API-Version: 3.2 R29 (B54 pl1)
X-type: 0
X-SenderIP: 81.73.170.22
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA29893

Hi all,
I' m interesting in protection/restoration (P/R) mechanisms and after having read some works, i' d like to do some observations.
In a TE path protection scenario, there are works dealing with the use of RSVP-TE messages to signal, in  example, 
a link failure.
But could it have sense this other way of recovery?
...After a detection of a failure, OSPF ( OSPF-TE ) uses the flooding mechanism to advertise the all network that one link is broken
( ... using opaque LSA? ); then all nodes, receiving the LSA with this information, could compute an analysis of what LSPs ( LSP having source in that node ) are interested by the failure. Then, in example, each node that wants to do restoration in a MPLS scenario could make a Label Switching if there is a Backup Path available. 
This approach has some problem:
-   a faster trigger on OSPF in detecting failure, since HELLO mechanism is slow;
-   the prioriting of the sequence ---flooding LSA---  and  then ---computing SPF algorithm--- to do faster;
-   the adding of intelligence in each node to do the Switching.

I know that these are only some observations containing ( i hope few ) errors and that aren't complete, but since i haven' t found any P/R mechanisms in a TE scenario using OSPF ( or any optimized version of this ), i' d like to make you a question:
is this a possible way of study ( as an alternative to RSVP signalling ) or is completely wrong and out of all standards?

Thanks in advance for your kind answers and observations.

Giovanni Di Giacomo



From owner-mpls@UU.NET  Wed Mar 12 06:22:16 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00159
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 06:22:16 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofrp04312
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 11:24:23 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofrp00512;
	Wed, 12 Mar 2003 11:23:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofrn18650
	for mpls-outgoing; Wed, 12 Mar 2003 10:53:50 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofrn18632
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 10:53:39 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofrn27285
	for <mpls@UU.NET>; Wed, 12 Mar 2003 10:52:43 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofrn02458
	for <mpls@UU.NET>; Wed, 12 Mar 2003 10:52:42 GMT
Received: from hoemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail1.lucent.com [192.11.226.161])
	id QQofrn02442
	for <mpls@UU.NET>; Wed, 12 Mar 2003 10:52:42 GMT
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by hoemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CAqed16644
	for <mpls@UU.NET>; Wed, 12 Mar 2003 05:52:40 -0500 (EST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19)
	id <DVZ3FCDJ>; Wed, 12 Mar 2003 11:52:35 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501157437@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Gert Grammel <Gert.Grammel@alcatel.de>, neil.2.harrison@bt.com
Cc: mlazer@att.com, Mark.Jones@mail.sprint.com, ccamp@ops.ietf.org,
        dwfedyk@nortelnetworks.com, gash@att.com, mpls@UU.NET
Subject: Why Call/Connection Separatation
Date: Wed, 12 Mar 2003 11:52:31 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

It is always interesting to see how a discussion on a
document that describes initial ideas on change control 
diverts into a discussion on other topics, in this case
the toipic of "Why Call/Connection Separation".

But people never change the subject line.
Oh well... if you want to continue this discussion, then PLEASE
use a proper subject line from now on.

Also if you decide to switch topics again, that you also change
the subject line.

Thanks,
Bert 

> -----Original Message-----
> From: Gert Grammel [mailto:Gert.Grammel@alcatel.de]
> Sent: woensdag 12 maart 2003 11:08
> To: neil.2.harrison@bt.com
> Cc: mlazer@att.com; Mark.Jones@mail.sprint.com; ccamp@ops.ietf.org;
> dwfedyk@nortelnetworks.com; gash@att.com; mpls@UU.NET
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> Neil,
> 
> I think you haven't got my point about call/connection 
> separation. Please have
> also a look to my respone to Eve. There can be a discussion about
> call/connection separation once there is a kind of shared 
> view on 'why it is
> needed'. In
> http://www.ietf.org/internet-drafts/draft-ietf-ipo-carrier-req
> uirements-05.txt
> the only 'motivating sentence I could find was:
> 
>      To support many enhanced optical services, such as 
> scheduled bandwidth
>      on demand, diverse circuit provisioning and bundled 
> connections, a
>      call model based on the separation of call control and connection
>      control is essential.
> 
> You gave some practical examples on where you see the need 
> for that. Why not
> putting it into a document and share it with everybody?
> 
> I also want to thank you to share with us your choice to go for a L0/1
> functionality. This is a very clear statement.
> 
> 
> Regards
> 
> Gert
> 
> neil.2.harrison@bt.com wrote:
> 
> > Hi Gert, I think some clarifications are in order here to 
> make the BT
> > position (ie not just the NH position) clear.  Please see 
> below.  regards,
> > Neil
> >
> > Gert Grammel wrote 11 March 2003 15:47 to Monica Lazer:
> >
> > <snipped>
> > > Look at the hottest issue under discussion: We are talking a
> > > lot about UNI
> > > features like call/connection separation. Neither Mark nor
> > > Neil see the UNI
> > > becoming service relevant at any time soon - so why is it
> > > under discussion right
> > > now? Is this your priority 1 issue in ITU-T? Is Mark or Neil
> > > in a minority
> > > position in ITU-T? Referring to the Yokohama Meeting this was
> > > basically
> > > Kireeti's request: Please explain what you need and for 
> what purpose.
> >
> > NH=> A UNI at L1/0 is *not* something we see as important 
> anytime soon.  We
> > also see no need for coupling with L2/3 (either commercially or
> > technically).  Thus we want to be able to choose 
> best-of-breed functionality
> > for L1/0.  We *do* want call/connection separation however, 
> and note this is
> > independent of the UNI...here is an extract from a 
> colleague of mine on the
> > ITU lists which sort-of explains why:
> > "Anyone care to disagree with the notion of a call handle 
> for SPCs in the
> > ITU-T as a means of bundling under one service instance a 
> customer record
> > that handles
> > multiple connections e.g. Virtual Concatenation, with or 
> without LCAS as a
> > valid application?
> > Anyone care to disagree that we might want to retrieve 
> information on an SPC
> > using a single identifier (the call) that shows all 
> connections associated
> > with that call and the performance of each connection 
> and/or start end of
> > individual connections?
> > Anyone care to diagree that the call/connection model 
> cannot be used for
> > restoration of SPCs?
> > As for those that want to do UNI on you go...but its not on 
> BT priority
> > list."
> > >
> > <snipped to end>
> 
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de
> 
> 
> 


From owner-mpls@UU.NET  Wed Mar 12 06:40:56 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00588
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 06:40:55 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofrq12471
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 11:43:04 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofrq12062;
	Wed, 12 Mar 2003 11:42:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofro07694
	for mpls-outgoing; Wed, 12 Mar 2003 11:07:13 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQofro07663
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 11:07:00 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofro04670
	for <mpls@uu.net>; Wed, 12 Mar 2003 11:06:53 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofro16739
	for <mpls@uu.net>; Wed, 12 Mar 2003 11:06:53 GMT
Received: from web20511.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web20511.mail.yahoo.com [216.136.175.150])
	id QQofro16712
	for <mpls@uu.net>; Wed, 12 Mar 2003 11:06:52 GMT
Message-ID: <20030312091019.90703.qmail@web20511.mail.yahoo.com>
Received: from [203.200.20.226] by web20511.mail.yahoo.com via HTTP; Wed, 12 Mar 2003 09:10:19 GMT
Date: Wed, 12 Mar 2003 09:10:19 +0000 (GMT)
From: =?iso-8859-1?q?John=20Smith?= <jsmith4112003@yahoo.co.uk>
Subject: ISIS as CE/PE protocol
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit

Hello,
draft-rosen-vpns-ospf-bgp-mpls-06.txt defines procedures which must be implemented within
the Provider's network when OSPF is used as the PE/CE routing protocol. Is there any
particular reason why there have been no such standards/procedures defined for running
ISIS as CE/PE protocol in BGP VPN domains.

Morever, are there any ISPs actually using ISIS for this purpose?

Any help in this regard will be appreciated!

Thanks and Regards,
John Smith


__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com


From owner-mpls@UU.NET  Wed Mar 12 07:16:39 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01395
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 07:16:39 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofrt25697
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 12:18:47 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofrt25455;
	Wed, 12 Mar 2003 12:18:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofrr11669
	for mpls-outgoing; Wed, 12 Mar 2003 11:52:55 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQofrr11658
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 11:52:51 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQofrr24799
	for <mpls@uu.net>; Wed, 12 Mar 2003 11:52:06 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofrr26838
	for <mpls@uu.net>; Wed, 12 Mar 2003 11:52:06 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQofrr26814
	for <mpls@uu.net>; Wed, 12 Mar 2003 11:52:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2CBq1Sc026125
	for <mpls@uu.net>; Wed, 12 Mar 2003 06:52:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA27945 for <mpls@uu.net>; Wed, 12 Mar 2003 06:52:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2CBq1O09738 for mpls@uu.net; Wed, 12 Mar 2003 06:52:01 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQofrr11460
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 11:50:50 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofrr06097
	for <mpls@uu.net>; Wed, 12 Mar 2003 11:50:34 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofrr05248
	for <mpls@uu.net>; Wed, 12 Mar 2003 11:50:34 GMT
Received: from mailrelay1.alcatel.de by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailrelay2.alcatel.de [194.113.59.71])
	id QQofrr05234
	for <mpls@uu.net>; Wed, 12 Mar 2003 11:50:33 GMT
Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10])
	by mailrelay1.alcatel.de (8.9.3/8.9.3) with ESMTP id MAA13918;
	Wed, 12 Mar 2003 12:49:35 +0100 (MET)
Received: from slsv7at ([149.204.245.107] helo=slsv7a.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 18t4kG-0007EN-00; Wed, 12 Mar 2003 12:50:04 +0100
Received: from sls5gi ([149.204.30.7] helo=alcatel.de) by slsv7a.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 18t4kG-0007lC-00; Wed, 12 Mar 2003 12:50:04 +0100
Message-ID: <3E6F1EEB.BBF421F9@alcatel.de>
Date: Wed, 12 Mar 2003 12:50:03 +0100
From: Gert Grammel <Gert.Grammel@alcatel.de>
Organization: Alcatel TND Product Strategy
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en,de
MIME-Version: 1.0
To: "Ferrell, William" <William.Ferrell@titan.com>
CC: "'curtis@fictitious.org '" <curtis@fictitious.org>,
        "'Mark.Jones@mail.sprint.com '" <Mark.Jones@mail.sprint.com>,
        "'ccamp@ops.ietf.org '" <ccamp@ops.ietf.org>,
        "'dwfedyk@nortelnetworks.com '" <dwfedyk@nortelnetworks.com>,
        "'gash@att.com '" <gash@att.com>, "'mpls@UU.NET '" <mpls@UU.NET>
Subject: security issues on MPLS
References: <561621C69F17D511A3A20050047340EC01AAF5EB@VCMD-NT1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

William,

I am not an expert in security issues but (G)MPLS security in particular rsvp is
based on RFC 2747. In and e2e case IPSEC can be used as well see (see RFC's 2402
and RFC 2406).

Regards

Gert

"Ferrell, William" wrote:

>  Gert / All
>
>  I am Will Ferrell of Titan working at DISA on an MPLS security
> project. I have worked with Barry Raveendran Greene (Cisco) on a major DISA
> ACL project of which he provided invaluable guidance/support/ tech reference
> that led to the projects success.
>
> Ive checked RFC's 2547,3036,2702 et. al.  It appears that there isnt a lot
> of interest in securing MPLS. Can you refer me to other work for MPLS
> security requirements and all phases of MPLS security to include secure
> implementation.
>
> > > >
> > > >William Ferrell
> > > >Information Assurance Eng. CCNP
> > > >Titan Corp.
> > > >703-882-2474
>
> -----Original Message-----
> From: Gert Grammel
> To: curtis@fictitious.org
> Cc: Mark.Jones@mail.sprint.com; ccamp@ops.ietf.org;
> dwfedyk@nortelnetworks.com; gash@att.com; mpls@UU.NET
> Sent: 3/10/03 7:24 AM
> Subject: Re: {Possible Spam} Re: I-D
> ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> Curtis,
>
> you've wrote:
>
>      It would be best if ITU members go off and waste their own time
>      pursuing ASON capabilities, just as the ATM Forum went off and
> wasted
>      their time on Q.2931 capability in UNI 3.x, 4.x, ...
>
> and I don't agree with that. In my view it would be best if ITU-T
> members were
> able to understand and accept the ideas behind GMPLS and would provide
> valuable
> input to bring this work forward.
>
> Regards
>
> Gert
>
> Curtis Villamizar wrote:
>
> > Coments inline.
> >
> > In message <3E679FB5.542FBF09@alcatel.de>, Gert Grammel writes:
> > >
> > > 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 (agai n informational) in IETF which do not comply to
> > >      the purity of RSVP-TE. Due t o 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 solutio n on how to proceed. What I've seen so far was a complete
> > > misperception of what i s 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 networkin g 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)
> >
> > SDH/SONET bandwidth on demand has never been deployed.  There is
> > serious question about whether this is a viable service.  The
> > technology has existed for about a decade (a little less maybe) for
> > provide ATM SVC service doing essentially the same thing.  Market
> > penetration after a decade is very close to zero for SVC.  Market
> > penetration for ATM SPVC/PVC is small and may be shrinking.  The FR
> > market seems to be shrinking as well.  FR SVC market is zero.
> > SDH/SONET does not have the bandwidth on demand capability but there
> > is ample evidence that implementing it would be a waste of time.
> >
> > ASON is a requirements document from ITU that assumes the SDH/SONET
> > BOND is a viable service.  This is an enormous leap of faith given the
> > trends in the market.  The IETF doesn't buy into it.
> >
> > And yes, most of us are familiar with SS7 and the whole SCP/STP AIN
> > mess, so if you want to extend TCAP to support ASON, go right ahead.
> > We in the IETF would get a real good laugh over that.
> >
> > >   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.
> >
> > Initially IP and voice ran over TDM.  The bandwidth demands of IP were
> > much less than voice a decade ago.  As IP penetration grew roughly
> > exponentially through the early, mid, and most of the late 1990s, this
> > reversed and IP consumed far more bandwidth than voice.  Switched
> > services also grew but at a slower rate and in the late 1990s
> > experienced negative growth for many SPs.  One factor may have been
> > notable outages in FR (US nationwide one day at one major provider and
> > intermittent for 10 days in another a few years later) shot a big hole
> > in the "much more reliable than IP" story.
> >
> > Initially MPLS served as traffic enginnering strictly for IP.  With IP
> > still growing substantially, voice growing very slowly (and losing
> > revenue) and switched services growing slowly to shrinking, there was
> > motivation to carry voice, switched services, and leased line services
> > over the IP and/or MPLS infrastructure and decommission older
> > SDH/SONET ADM and FR or ATM switches.  This led to the tunneling work.
> >
> > Another factor which led to GMPLS was the (unrealized) promise/hype of
> > optical switching in the very late 1990s.  IP over an ATM overlay was
> > a poor design and IP providers did not want to repeat that mistake so
> > the control of the underlying optical domain was accommodated by what
> > has evolved into GMPLS.  GMPLS was extended to accommodate TDM in
> > addition to FSC, LSC and PSC.
> >
> > > 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.
> >
> > ASON was never accepted by the IETF as requirements and for very good
> > reason.  To say that IETF must accept the ASON requirements simply
> > because they came in a liason statement and that the IETF must
> > accommodate this ITU folly is absurd.
> >
> > > 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 .
> >
> > Regardless of how this was handled in Yokohama, some of the
> > fundamental premise of ASON is flawed.  It would be best if ITU
> > members go off and waste their own time pursuing ASON capabilities,
> > just as the ATM Forum went off and wasted their time on Q.2931
> > capability in UNI 3.x, 4.x, but ITU should do so without extending
> > protocols which originated in the IETF.
> >
> > > 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
> >
> > I look forward to seeing the IETF come up with a formal statement of
> > liason policy.  It would be useful to have explicitly documented that
> > liason statements carry no more weight than any individual
> > internet-draft submission.
> >
> > Curtis
>
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de




From owner-mpls@UU.NET  Wed Mar 12 09:02:19 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03789
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 09:02:18 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofsa28135
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 14:04:26 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofsa27993;
	Wed, 12 Mar 2003 14:04:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofry26614
	for mpls-outgoing; Wed, 12 Mar 2003 13:39:23 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofry26603
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 13:39:15 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofry03747
	for <mpls@UU.NET>; Wed, 12 Mar 2003 13:38:44 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofry07551
	for <mpls@UU.NET>; Wed, 12 Mar 2003 13:38:44 GMT
Received: from bt0g2p.god.bel.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alc136.alcatel.be [195.207.101.136])
	id QQofry07543
	for <mpls@UU.NET>; Wed, 12 Mar 2003 13:38:43 GMT
Received: from bemail05.net.alcatel.be (relay3 [127.0.0.1])
	by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id h2CDcXs24015;
	Wed, 12 Mar 2003 14:38:33 +0100
Received: from alcatel.be ([138.203.64.155])
          by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11)
          with ESMTP id 2003031214383187:3187 ;
          Wed, 12 Mar 2003 14:38:31 +0100 
Message-ID: <3E6F3826.54B61499@alcatel.be>
Date: Wed, 12 Mar 2003 14:37:42 +0100
From: Dimitri.Papadimitriou@alcatel.be
Organization: optical network architecture (nta - antwerpen)
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
Cc: Gert.Grammel@alcatel.de, neil.2.harrison@bt.com, mlazer@att.com,
        Mark.Jones@mail.sprint.com, ccamp@ops.ietf.org,
        dwfedyk@nortelnetworks.com, gash@att.com, mpls@UU.NET
Subject: Re: Why Call/Connection Separation
References: <7D5D48D2CAA3D84C813F5B154F43B15501157437@nl0006exch001u.nl.lucent.com>
X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 03/12/2003 14:38:31,
	Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 03/12/2003 14:38:33,
	Serialize complete at 03/12/2003 14:38:33
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

all, in order to re-initiate the discussion w/i the 
ccamp wg an "ason functional req's" i-d has been (re-) 
initiated that should (hopefully) explain the reasons/
rationales (the "why") and the expectations (the "what") 
for call-connection control separation and other 
requirements such as crank back for instance

we plan to submit it right after the meeting (subm.
deadline being over for this meeting) in order to move 
a step forward with this discussion

hint: i'd be of great interest if the user community
(in particular ops folks) could give us their view-
point here as well

thanks,
- dimitri.

"Wijnen, Bert (Bert)" wrote:
> 
> It is always interesting to see how a discussion on a
> document that describes initial ideas on change control
> diverts into a discussion on other topics, in this case
> the toipic of "Why Call/Connection Separation".
> 
> But people never change the subject line.
> Oh well... if you want to continue this discussion, then PLEASE
> use a proper subject line from now on.
> 
> Also if you decide to switch topics again, that you also change
> the subject line.
> 
> Thanks,
> Bert
> 
> > -----Original Message-----
> > From: Gert Grammel [mailto:Gert.Grammel@alcatel.de]
> > Sent: woensdag 12 maart 2003 11:08
> > To: neil.2.harrison@bt.com
> > Cc: mlazer@att.com; Mark.Jones@mail.sprint.com; ccamp@ops.ietf.org;
> > dwfedyk@nortelnetworks.com; gash@att.com; mpls@UU.NET
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> >
> > Neil,
> >
> > I think you haven't got my point about call/connection
> > separation. Please have
> > also a look to my respone to Eve. There can be a discussion about
> > call/connection separation once there is a kind of shared
> > view on 'why it is
> > needed'. In
> > http://www.ietf.org/internet-drafts/draft-ietf-ipo-carrier-req
> > uirements-05.txt
> > the only 'motivating sentence I could find was:
> >
> >      To support many enhanced optical services, such as
> > scheduled bandwidth
> >      on demand, diverse circuit provisioning and bundled
> > connections, a
> >      call model based on the separation of call control and connection
> >      control is essential.
> >
> > You gave some practical examples on where you see the need
> > for that. Why not
> > putting it into a document and share it with everybody?
> >
> > I also want to thank you to share with us your choice to go for a L0/1
> > functionality. This is a very clear statement.
> >
> >
> > Regards
> >
> > Gert
> >
> > neil.2.harrison@bt.com wrote:
> >
> > > Hi Gert, I think some clarifications are in order here to
> > make the BT
> > > position (ie not just the NH position) clear.  Please see
> > below.  regards,
> > > Neil
> > >
> > > Gert Grammel wrote 11 March 2003 15:47 to Monica Lazer:
> > >
> > > <snipped>
> > > > Look at the hottest issue under discussion: We are talking a
> > > > lot about UNI
> > > > features like call/connection separation. Neither Mark nor
> > > > Neil see the UNI
> > > > becoming service relevant at any time soon - so why is it
> > > > under discussion right
> > > > now? Is this your priority 1 issue in ITU-T? Is Mark or Neil
> > > > in a minority
> > > > position in ITU-T? Referring to the Yokohama Meeting this was
> > > > basically
> > > > Kireeti's request: Please explain what you need and for
> > what purpose.
> > >
> > > NH=> A UNI at L1/0 is *not* something we see as important
> > anytime soon.  We
> > > also see no need for coupling with L2/3 (either commercially or
> > > technically).  Thus we want to be able to choose
> > best-of-breed functionality
> > > for L1/0.  We *do* want call/connection separation however,
> > and note this is
> > > independent of the UNI...here is an extract from a
> > colleague of mine on the
> > > ITU lists which sort-of explains why:
> > > "Anyone care to disagree with the notion of a call handle
> > for SPCs in the
> > > ITU-T as a means of bundling under one service instance a
> > customer record
> > > that handles
> > > multiple connections e.g. Virtual Concatenation, with or
> > without LCAS as a
> > > valid application?
> > > Anyone care to disagree that we might want to retrieve
> > information on an SPC
> > > using a single identifier (the call) that shows all
> > connections associated
> > > with that call and the performance of each connection
> > and/or start end of
> > > individual connections?
> > > Anyone care to diagree that the call/connection model
> > cannot be used for
> > > restoration of SPCs?
> > > As for those that want to do UNI on you go...but its not on
> > BT priority
> > > list."
> > > >
> > > <snipped to end>
> >
> > --
> > Alcatel Optical Network Division    Gert Grammel
> > Network Strategy                    phone: +49 711 821 47368
> > Lorenzstrasse 10                    fax: +49 711 821 43169
> > D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de
> >
> >
> >

-- 
Papadimitriou Dimitri 
E-mail : dimitri.papadimitriou@alcatel.be 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491


From owner-mpls@UU.NET  Wed Mar 12 09:50:18 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04887
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 09:50:18 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofsd15938
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 14:52:27 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofsd15668;
	Wed, 12 Mar 2003 14:52:15 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofsb17567
	for mpls-outgoing; Wed, 12 Mar 2003 14:25:43 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQofsb17562
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 14:25:39 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQofsb07493
	for <mpls@uu.net>; Wed, 12 Mar 2003 14:25:06 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofsb27066
	for <mpls@uu.net>; Wed, 12 Mar 2003 14:25:06 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQofsb27055
	for <mpls@uu.net>; Wed, 12 Mar 2003 14:25:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2CEP3Sc015077
	for <mpls@uu.net>; Wed, 12 Mar 2003 09:25:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA05011 for <mpls@uu.net>; Wed, 12 Mar 2003 09:25:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2CEP2O19711 for mpls@uu.net; Wed, 12 Mar 2003 09:25:02 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofsb17516
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 14:23:00 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofsb12584
	for <mpls@UU.NET>; Wed, 12 Mar 2003 14:22:21 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofsb17462
	for <mpls@UU.NET>; Wed, 12 Mar 2003 14:22:20 GMT
Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQofsb17422
	for <mpls@UU.NET>; Wed, 12 Mar 2003 14:22:19 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id JAA81656;
	Wed, 12 Mar 2003 09:21:37 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303121421.JAA81656@workhorse.fictitious.org>
To: "john151@libero.it" <john151@libero.it>
cc: "mpls" <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: Between OSPF RSVP... 
In-reply-to: Your message of "Wed, 12 Mar 2003 11:39:40 +0100."
             <HBMTM4$875FAF0F2AFF01D1398F99ACE02AFA7C@libero.it> 
Date: Wed, 12 Mar 2003 09:21:37 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <HBMTM4$875FAF0F2AFF01D1398F99ACE02AFA7C@libero.it>, "john151@libero
.it" writes:
> Hi all,
> I' m interesting in protection/restoration (P/R) mechanisms and after having 
> read some works, i' d like to do some observations.
> In a TE path protection scenario, there are works dealing with the use of RSV
> P-TE messages to signal, in  example, 
> a link failure.
> But could it have sense this other way of recovery?
> ...After a detection of a failure, OSPF ( OSPF-TE ) uses the flooding mechani
> sm to advertise the all network that one link is broken
> ( ... using opaque LSA? ); then all nodes, receiving the LSA with this inform
> ation, could compute an analysis of what LSPs ( LSP having source in that nod
> e ) are interested by the failure. Then, in example, each node that wants to 
> do restoration in a MPLS scenario could make a Label Switching if there is a 
> Backup Path available. 
> This approach has some problem:
> -   a faster trigger on OSPF in detecting failure, since HELLO mechanism is s
> low;
> -   the prioriting of the sequence ---flooding LSA---  and  then ---computing
>  SPF algorithm--- to do faster;
> -   the adding of intelligence in each node to do the Switching.
> 
> I know that these are only some observations containing ( i hope few ) errors
>  and that aren't complete, but since i haven' t found any P/R mechanisms in a
>  TE scenario using OSPF ( or any optimized version of this ), i' d like to ma
> ke you a question:
> is this a possible way of study ( as an alternative to RSVP signalling ) or i
> s completely wrong and out of all standards?
> 
> Thanks in advance for your kind answers and observations.
> 
> Giovanni Di Giacomo


OSPF/TE already uses the SONET framing detection to trigger fast
flooding of link down.  This is a FAQ.

Ingress then quickly find any affected LSPs (the quickly part is an
implementation detail, but reasonable implementations don't do a
search of all LSPs but rather have this information already available
as a data structure hung off the TE-LSDB entry for the link).

Presignaled disjoint backup LSPs from the ingress are known as
"standby" LSP and are implemented by most LSR as an alternate to FRR.
In practice, standby LSP provide anywhere from sub second to a few
second restoration AFAIK.  Otherwise the ingress must resignal the
affected LSPs on new paths.  This is supposed to take just a few
seconds but in practice if a lot of LSPs are affected most LSR seem to
fall back to IP forwarding and get the LSPs up in 10s of seconds.
Implementations are improving and getting this to consistently a few
seconds, even for large topologies and large numbers of affected LSPs
is being discussed elsewhere usually referred to as the "fast
convergence" problem.

LDP makes direct use of the OSPF derived next-hop.

Curtis



From owner-mpls@UU.NET  Wed Mar 12 10:04:45 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05497
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 10:04:44 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofse05931
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 15:06:54 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofse05784;
	Wed, 12 Mar 2003 15:06:47 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofsc18781
	for mpls-outgoing; Wed, 12 Mar 2003 14:40:15 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofsc18764
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 14:40:03 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQofsc09498
	for <mpls@uu.net>; Wed, 12 Mar 2003 14:39:08 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofsc11168
	for <mpls@uu.net>; Wed, 12 Mar 2003 14:39:07 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQofsc11160
	for <mpls@uu.net>; Wed, 12 Mar 2003 14:39:07 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2CEd4Sc017857
	for <mpls@uu.net>; Wed, 12 Mar 2003 09:39:05 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA05945 for <mpls@uu.net>; Wed, 12 Mar 2003 09:39:04 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2CEd4621347 for mpls@uu.net; Wed, 12 Mar 2003 09:39:04 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofsc18669
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 14:37:24 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofsc12646
	for <mpls@UU.NET>; Wed, 12 Mar 2003 14:37:22 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofsc24836
	for <mpls@UU.NET>; Wed, 12 Mar 2003 14:37:22 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQofsc24821
	for <mpls@UU.NET>; Wed, 12 Mar 2003 14:37:21 GMT
Received: from cisco.com (uzura.cisco.com [64.102.17.77])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2CEbJvD000784;
	Wed, 12 Mar 2003 09:37:19 -0500 (EST)
Received: from asimha-w2k.cisco.com (dhcp-64-102-38-125.cisco.com [64.102.38.125])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id JAA18257;
	Wed, 12 Mar 2003 09:37:19 -0500 (EST)
Received: by asimha-w2k.cisco.com (sSMTP sendmail emulation); Wed, 12 Mar 2003 09:37:18 -0500
Date: Wed, 12 Mar 2003 09:37:18 -0500
From: Ajay Simha <asimha@cisco.com>
To: John Smith <jsmith4112003@yahoo.co.uk>
Cc: mpls@UU.NET
Subject: Re: ISIS as CE/PE protocol
Message-ID: <20030312143718.GF1692@cisco.com>
References: <20030312091019.90703.qmail@web20511.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030312091019.90703.qmail@web20511.mail.yahoo.com>
User-Agent: Mutt/1.4i
Sender: owner-mpls@UU.NET
Precedence: bulk

On Wed Mar 12 09:10:19 2003, John Smith wrote:
> Hello,
> draft-rosen-vpns-ospf-bgp-mpls-06.txt defines procedures which must be implemented within
> the Provider's network when OSPF is used as the PE/CE routing protocol. Is there any
> particular reason why there have been no such standards/procedures defined for running
> ISIS as CE/PE protocol in BGP VPN domains.
> 
> Morever, are there any ISPs actually using ISIS for this purpose?

ISIS is primarly an ISP IGP. Usually the folks buying BGP VPN service from an SP are enterprises.
ISPs also buy this type of service but prefer to run BGP opposed to an IGP between themselves
and the BGP VPN provider.

-ajay
> 
> Any help in this regard will be appreciated!
> 
> Thanks and Regards,
> John Smith
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.com



From owner-mpls@UU.NET  Wed Mar 12 11:48:29 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10665
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 11:48:29 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofsl28073
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 16:50:38 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofsl27914;
	Wed, 12 Mar 2003 16:50:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofsj04342
	for mpls-outgoing; Wed, 12 Mar 2003 16:25:03 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQofsj04329
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 16:24:49 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofsj16003
	for <mpls@uu.net>; Wed, 12 Mar 2003 16:24:12 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofsj06952
	for <mpls@uu.net>; Wed, 12 Mar 2003 16:24:11 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQofsj06869
	for <mpls@uu.net>; Wed, 12 Mar 2003 16:24:06 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2CGO2Sc008907
	for <mpls@uu.net>; Wed, 12 Mar 2003 11:24:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA14508 for <mpls@uu.net>; Wed, 12 Mar 2003 11:24:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2CGO2m00620 for mpls@uu.net; Wed, 12 Mar 2003 11:24:02 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofsj04243
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 16:22:11 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofsj25680
	for <mpls@uu.net>; Wed, 12 Mar 2003 16:21:12 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofsj26701
	for <mpls@uu.net>; Wed, 12 Mar 2003 16:21:11 GMT
Received: from mailrelay1.alcatel.de by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailrelay2.alcatel.de [194.113.59.71])
	id QQofsj26685
	for <mpls@uu.net>; Wed, 12 Mar 2003 16:21:11 GMT
Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10])
	by mailrelay1.alcatel.de (8.9.3/8.9.3) with ESMTP id RAA03416;
	Wed, 12 Mar 2003 17:20:17 +0100 (MET)
Received: from slsv7at ([149.204.245.107] helo=slsv7a.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 18t8yE-0004bl-00; Wed, 12 Mar 2003 17:20:46 +0100
Received: from sls5gi ([149.204.30.7] helo=alcatel.de) by slsv7a.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 18t8yE-0004mj-00; Wed, 12 Mar 2003 17:20:46 +0100
Message-ID: <3E6F5E5D.AC3D3EFB@alcatel.de>
Date: Wed, 12 Mar 2003 17:20:45 +0100
From: Gert Grammel <Gert.Grammel@alcatel.de>
Organization: Alcatel TND Product Strategy
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en,de
MIME-Version: 1.0
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
CC: neil.2.harrison@bt.com, mlazer@att.com, Mark.Jones@mail.sprint.com,
        ccamp@ops.ietf.org, dwfedyk@nortelnetworks.com, gash@att.com,
        mpls@UU.NET
Subject: Re: Why Call/Connection Separatation
References: <7D5D48D2CAA3D84C813F5B154F43B15501157437@nl0006exch001u.nl.lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Bert,

of course you are right, that the subject line should reflect the discussion. It
was however not my intention to start yet another discussion on call/connection
separation but to use it as an example on how to solve issues which seem to be
clear on one side and unclear on the other one. I repeat that in our target
should be to find a solution which is shared between IETF and ITU-T. The way
forward is in my opinions to *help* everybody to understand the issues and to be
open to consider a variety of solutions. This way however requires that the
involved folks *want* to work together and really share a common target - not
sure if we are already there.

Regards

Gert




"Wijnen, Bert (Bert)" wrote:

> It is always interesting to see how a discussion on a
> document that describes initial ideas on change control
> diverts into a discussion on other topics, in this case
> the toipic of "Why Call/Connection Separation".
>
> But people never change the subject line.
> Oh well... if you want to continue this discussion, then PLEASE
> use a proper subject line from now on.
>
> Also if you decide to switch topics again, that you also change
> the subject line.
>
> Thanks,
> Bert
>
> > -----Original Message-----
> > From: Gert Grammel [mailto:Gert.Grammel@alcatel.de]
> > Sent: woensdag 12 maart 2003 11:08
> > To: neil.2.harrison@bt.com
> > Cc: mlazer@att.com; Mark.Jones@mail.sprint.com; ccamp@ops.ietf.org;
> > dwfedyk@nortelnetworks.com; gash@att.com; mpls@UU.NET
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> >
> > Neil,
> >
> > I think you haven't got my point about call/connection
> > separation. Please have
> > also a look to my respone to Eve. There can be a discussion about
> > call/connection separation once there is a kind of shared
> > view on 'why it is
> > needed'. In
> > http://www.ietf.org/internet-drafts/draft-ietf-ipo-carrier-req
> > uirements-05.txt
> > the only 'motivating sentence I could find was:
> >
> >      To support many enhanced optical services, such as
> > scheduled bandwidth
> >      on demand, diverse circuit provisioning and bundled
> > connections, a
> >      call model based on the separation of call control and connection
> >      control is essential.
> >
> > You gave some practical examples on where you see the need
> > for that. Why not
> > putting it into a document and share it with everybody?
> >
> > I also want to thank you to share with us your choice to go for a L0/1
> > functionality. This is a very clear statement.
> >
> >
> > Regards
> >
> > Gert
> >
> > neil.2.harrison@bt.com wrote:
> >
> > > Hi Gert, I think some clarifications are in order here to
> > make the BT
> > > position (ie not just the NH position) clear.  Please see
> > below.  regards,
> > > Neil
> > >
> > > Gert Grammel wrote 11 March 2003 15:47 to Monica Lazer:
> > >
> > > <snipped>
> > > > Look at the hottest issue under discussion: We are talking a
> > > > lot about UNI
> > > > features like call/connection separation. Neither Mark nor
> > > > Neil see the UNI
> > > > becoming service relevant at any time soon - so why is it
> > > > under discussion right
> > > > now? Is this your priority 1 issue in ITU-T? Is Mark or Neil
> > > > in a minority
> > > > position in ITU-T? Referring to the Yokohama Meeting this was
> > > > basically
> > > > Kireeti's request: Please explain what you need and for
> > what purpose.
> > >
> > > NH=> A UNI at L1/0 is *not* something we see as important
> > anytime soon.  We
> > > also see no need for coupling with L2/3 (either commercially or
> > > technically).  Thus we want to be able to choose
> > best-of-breed functionality
> > > for L1/0.  We *do* want call/connection separation however,
> > and note this is
> > > independent of the UNI...here is an extract from a
> > colleague of mine on the
> > > ITU lists which sort-of explains why:
> > > "Anyone care to disagree with the notion of a call handle
> > for SPCs in the
> > > ITU-T as a means of bundling under one service instance a
> > customer record
> > > that handles
> > > multiple connections e.g. Virtual Concatenation, with or
> > without LCAS as a
> > > valid application?
> > > Anyone care to disagree that we might want to retrieve
> > information on an SPC
> > > using a single identifier (the call) that shows all
> > connections associated
> > > with that call and the performance of each connection
> > and/or start end of
> > > individual connections?
> > > Anyone care to diagree that the call/connection model
> > cannot be used for
> > > restoration of SPCs?
> > > As for those that want to do UNI on you go...but its not on
> > BT priority
> > > list."
> > > >
> > > <snipped to end>
> >
> > --
> > Alcatel Optical Network Division    Gert Grammel
> > Network Strategy                    phone: +49 711 821 47368
> > Lorenzstrasse 10                    fax: +49 711 821 43169
> > D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de
> >
> >
> >

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de




From owner-mpls@UU.NET  Wed Mar 12 15:38:05 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21295
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 15:38:04 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofta03824
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 20:40:13 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofta02809;
	Wed, 12 Mar 2003 20:39:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofsy05666
	for mpls-outgoing; Wed, 12 Mar 2003 20:13:45 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQofsy05661
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 20:13:38 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofsy07027
	for <mpls@UU.NET>; Wed, 12 Mar 2003 20:12:51 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofsy27571
	for <mpls@UU.NET>; Wed, 12 Mar 2003 20:12:51 GMT
Received: from smtp0.libero.it by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp0.libero.it [193.70.192.33])
	id QQofsy27558
	for <mpls@UU.NET>; Wed, 12 Mar 2003 20:12:50 GMT
Received: from libero.it (193.70.192.57) by smtp0.libero.it (6.7.015)
        id 3E68E20400061B8F for mpls@UU.NET; Wed, 12 Mar 2003 21:12:50 +0100
Date: Wed, 12 Mar 2003 21:12:50 +0100
Message-Id: <HBNK5E$B65A1A02511883B158F736061C040B88@libero.it>
Subject: =?iso-8859-1?Q?Re:Re:_Between_OSPF_RSVP...?=
MIME-Version: 1.0
X-Sensitivity: 3
Content-Type: text/plain; charset=iso-8859-1
From: "=?iso-8859-1?Q?john151@libero.it?=" <john151@libero.it>
To: "=?iso-8859-1?Q?mpls?=" <mpls@UU.NET>
X-XaM3-API-Version: 3.2 R29 (B54 pl1)
X-type: 0
X-SenderIP: 81.73.170.22
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA21295

Hi Curtis hi all,
essentially my considerations are: if i have two pre-calculated disjoint backup paths and i use opaque LSA to flood the link failure information,
it could be a reasonable faster  way of proceeding instead of using RSVP if i have an intelligence in the source routers (routers have to be able to switch among the two LSPs if they receive that particular opaque LSA; note that for a restoration of many LSPs RSVP will work in series, but OSPF will work in parallel with its flooding mechanism).
So the basic question is: is it a reasonable way the use of OSPF  and opaque LSA? Is there a reason to the use always RSVP for path protection, since, i think, increasing the LSPs corrupted by one link failure (if there are many active LSPs on the link that goes down) the OSPF mechanism of flooding is more efficient than using many RSVP messages from node that detects the failure towards the LSPs senders?

Thanks in advance for your kind answers and observations.

Giovanni Di Giacomo


In message <HBMTM4$875FAF0F2AFF01D1398F99ACE02AFA7C@libero.it>, "john151@libero
.it" writes:
> Hi all,
> I' m interesting in protection/restoration (P/R) mechanisms and after having 
> read some works, i' d like to do some observations.
> In a TE path protection scenario, there are works dealing with the use of RSV
> P-TE messages to signal, in  example, 
> a link failure.
> But could it have sense this other way of recovery?
> ...After a detection of a failure, OSPF ( OSPF-TE ) uses the flooding mechani
> sm to advertise the all network that one link is broken
> ( ... using opaque LSA? ); then all nodes, receiving the LSA with this inform
> ation, could compute an analysis of what LSPs ( LSP having source in that nod
> e ) are interested by the failure. Then, in example, each node that wants to 
> do restoration in a MPLS scenario could make a Label Switching if there is a 
> Backup Path available. 
> This approach has some problem:
> -   a faster trigger on OSPF in detecting failure, since HELLO mechan
oriting of the sequence ---flooding LSA---  and  then ---computing
>  SPF algorithm--- to do faster;
> -   the adding of intelligence in each node to do the Switching.
> 
> I know that these are only some observations containing ( i hope few ) errors
>  and that aren't complete, but since i haven' t found any P/R mechanisms in a
>  TE scenario using OSPF ( or any optimized version of this ), i' d like to ma
> ke you a question:
> is this a possible way of study ( as an alternative to RSVP signalling ) or i
> s completely wrong and out of all standards?
> 
> Thanks in advance for your kind answers and observations.
> 
> Giovanni Di Giacomo


OSPF/TE already uses the SONET framing detection to trigger fast
flooding of link down.  This is a FAQ.

Ingress then quickly find any affected LSPs (the quickly part is an
implementation detail, but reasonable implementations don't do a
search of all LSPs but rather have this information already available
as a data structure hung off the TE-LSDB entry for the link).

Presignaled disjoint backup LSPs from the ingress are known as
"standby" LSP and are implemented by most LSR as an alternate to FRR.
In practice, standby LSP provide anywhere from sub second to a few
second restoration AFAIK.  Otherwise the ingress must resignal the
affected LSPs on new paths.  This is supposed to take just a few
seconds but in practice if a lot of LSPs are affected most LSR seem to
fall back to IP forwarding and get the LSPs up in 10s of seconds.
Implementations are improving and getting this to consistently a few
seconds, even for large topologies and large numbers of affected LSPs
is being discussed elsewhere usually referred to as the "fast
convergence" problem.

LDP makes direct use of the OSPF derived next-hop.

Curtis




From owner-mpls@UU.NET  Wed Mar 12 15:50:24 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21673
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 15:50:24 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftb04469
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 20:52:34 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoftb04299;
	Wed, 12 Mar 2003 20:52:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofsz06786
	for mpls-outgoing; Wed, 12 Mar 2003 20:26:30 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQofsz06780
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 20:26:26 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQofsz28940
	for <mpls@UU.NET>; Wed, 12 Mar 2003 20:25:40 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofsz17621
	for <mpls@UU.NET>; Wed, 12 Mar 2003 20:25:40 GMT
Received: from hoemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail1.lucent.com [192.11.226.161])
	id QQofsz17617
	for <mpls@UU.NET>; Wed, 12 Mar 2003 20:25:40 GMT
Received: from ma8117exch001u.wins.lucent.com (h152-148-89-175.lucent.com [152.148.89.175])
	by hoemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CKPcm19202
	for <mpls@UU.NET>; Wed, 12 Mar 2003 15:25:38 -0500 (EST)
Received: by ma8117exch001u.inse.lucent.com with Internet Mail Service (5.5.2653.19)
	id <FZ113P6G>; Wed, 12 Mar 2003 15:25:38 -0500
Message-ID: <C77B73BC1A3ED4118C2000508BAD8A7C0651F476@ma8117exch001u.inse.lucent.com>
From: "Nair, Girish (Girish)" <gnair@lucent.com>
To: "'john151@libero.it'" <john151@libero.it>, mpls <mpls@UU.NET>
Subject: RE: Re: Between OSPF RSVP...
Date: Wed, 12 Mar 2003 15:25:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Giovanni,

I agree. Link down LSP rerouting can be done a little more efficiently
using the IGP. This has been done in some proprietary signaling
implementations
and works well. It involves tighter coupling between the IGP and signaling
though.

Girish

-----Original Message-----
From: john151@libero.it [mailto:john151@libero.it]
Sent: Wednesday, March 12, 2003 3:13 PM
To: mpls
Subject: Re:Re: Between OSPF RSVP...


Hi Curtis hi all,
essentially my considerations are: if i have two pre-calculated disjoint
backup paths and i use opaque LSA to flood the link failure information,
it could be a reasonable faster  way of proceeding instead of using RSVP if
i have an intelligence in the source routers (routers have to be able to
switch among the two LSPs if they receive that particular opaque LSA; note
that for a restoration of many LSPs RSVP will work in series, but OSPF will
work in parallel with its flooding mechanism).
So the basic question is: is it a reasonable way the use of OSPF  and opaque
LSA? Is there a reason to the use always RSVP for path protection, since, i
think, increasing the LSPs corrupted by one link failure (if there are many
active LSPs on the link that goes down) the OSPF mechanism of flooding is
more efficient than using many RSVP messages from node that detects the
failure towards the LSPs senders?

Thanks in advance for your kind answers and observations.

Giovanni Di Giacomo


In message <HBMTM4$875FAF0F2AFF01D1398F99ACE02AFA7C@libero.it>,
"john151@libero
.it" writes:
> Hi all,
> I' m interesting in protection/restoration (P/R) mechanisms and after
having 
> read some works, i' d like to do some observations.
> In a TE path protection scenario, there are works dealing with the use of
RSV
> P-TE messages to signal, in  example, 
> a link failure.
> But could it have sense this other way of recovery?
> ...After a detection of a failure, OSPF ( OSPF-TE ) uses the flooding
mechani
> sm to advertise the all network that one link is broken
> ( ... using opaque LSA? ); then all nodes, receiving the LSA with this
inform
> ation, could compute an analysis of what LSPs ( LSP having source in that
nod
> e ) are interested by the failure. Then, in example, each node that wants
to 
> do restoration in a MPLS scenario could make a Label Switching if there is
a 
> Backup Path available. 
> This approach has some problem:
> -   a faster trigger on OSPF in detecting failure, since HELLO mechanism
is s
> low;
> -   the prioriting of the sequence ---flooding LSA---  and  then
---computing
>  SPF algorithm--- to do faster;
> -   the adding of intelligence in each node to do the Switching.
> 
> I know that these are only some observations containing ( i hope few )
errors
>  and that aren't complete, but since i haven' t found any P/R mechanisms
in a
>  TE scenario using OSPF ( or any optimized version of this ), i' d like to
ma
> ke you a question:
> is this a possible way of study ( as an alternative to RSVP signalling )
or i
> s completely wrong and out of all standards?
> 
> Thanks in advance for your kind answers and observations.
> 
> Giovanni Di Giacomo


OSPF/TE already uses the SONET framing detection to trigger fast
flooding of link down.  This is a FAQ.

Ingress then quickly find any affected LSPs (the quickly part is an
implementation detail, but reasonable implementations don't do a
search of all LSPs but rather have this information already available
as a data structure hung off the TE-LSDB entry for the link).

Presignaled disjoint backup LSPs from the ingress are known as
"standby" LSP and are implemented by most LSR as an alternate to FRR.
In practice, standby LSP provide anywhere from sub second to a few
second restoration AFAIK.  Otherwise the ingress must resignal the
affected LSPs on new paths.  This is supposed to take just a few
seconds but in practice if a lot of LSPs are affected most LSR seem to
fall back to IP forwarding and get the LSPs up in 10s of seconds.
Implementations are improving and getting this to consistently a few
seconds, even for large topologies and large numbers of affected LSPs
is being discussed elsewhere usually referred to as the "fast
convergence" problem.

LDP makes direct use of the OSPF derived next-hop.

Curtis



From owner-mpls@UU.NET  Wed Mar 12 16:19:45 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23428
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 16:19:44 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftd02896
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 21:21:54 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoftd02520;
	Wed, 12 Mar 2003 21:21:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoftb09291
	for mpls-outgoing; Wed, 12 Mar 2003 20:56:04 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoftb09176
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 20:55:59 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoftb27593
	for <mpls@UU.NET>; Wed, 12 Mar 2003 20:55:48 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftb22096
	for <mpls@UU.NET>; Wed, 12 Mar 2003 20:55:47 GMT
Received: from smtp1.libero.it by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp1.libero.it [193.70.192.51])
	id QQoftb22067
	for <mpls@UU.NET>; Wed, 12 Mar 2003 20:55:46 GMT
Received: from libero.it (193.70.192.36) by smtp1.libero.it (6.7.015)
        id 3E68E7F100060CA0 for mpls@UU.NET; Wed, 12 Mar 2003 21:55:42 +0100
Date: Wed, 12 Mar 2003 21:55:42 +0100
Message-Id: <HBNM4U$75158E71487E646885A071158FD175E2@libero.it>
Subject: =?iso-8859-1?Q?OSPF_RSVP...?=
MIME-Version: 1.0
X-Sensitivity: 3
Content-Type: text/plain; charset=iso-8859-1
From: "=?iso-8859-1?Q?john151@libero.it?=" <john151@libero.it>
To: "=?iso-8859-1?Q?mpls?=" <mpls@UU.NET>
X-XaM3-API-Version: 3.2 R29 (B54 pl1)
X-type: 0
X-SenderIP: 81.73.170.22
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA23428

Hi Girish,
can you give me some examples of these proprietary signaling
implementations?

Thanks in advance for your kind answer.

Giovanni Di Giacomo




Giovanni,

I agree. Link down LSP rerouting can be done a little more efficiently
using the IGP. This has been done in some proprietary signaling
implementations
and works well. It involves tighter coupling between the IGP and signaling
though.

Girish




From owner-mpls@UU.NET  Wed Mar 12 16:36:34 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24314
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 16:36:33 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofte04476
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 21:38:41 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofte04006;
	Wed, 12 Mar 2003 21:38:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoftc28566
	for mpls-outgoing; Wed, 12 Mar 2003 21:11:43 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoftc28555
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 21:11:39 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoftc10855
	for <mpls@uu.net>; Wed, 12 Mar 2003 21:11:07 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftc15331
	for <mpls@uu.net>; Wed, 12 Mar 2003 21:11:06 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoftc15309
	for <mpls@uu.net>; Wed, 12 Mar 2003 21:11:06 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2CLB2Sc001036
	for <mpls@uu.net>; Wed, 12 Mar 2003 16:11:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA08267 for <mpls@uu.net>; Wed, 12 Mar 2003 16:11:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2CLB1e17939 for mpls@uu.net; Wed, 12 Mar 2003 16:11:01 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoftc28071
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 21:09:09 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoftc23700
	for <mpls@UU.NET>; Wed, 12 Mar 2003 21:08:38 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftc11918
	for <mpls@UU.NET>; Wed, 12 Mar 2003 21:08:38 GMT
Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoftc11902
	for <mpls@UU.NET>; Wed, 12 Mar 2003 21:08:37 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA84597;
	Wed, 12 Mar 2003 16:07:53 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303122107.QAA84597@workhorse.fictitious.org>
To: "john151@libero.it" <john151@libero.it>
cc: "mpls" <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: Between OSPF RSVP... 
In-reply-to: Your message of "Wed, 12 Mar 2003 21:12:50 +0100."
             <HBNK5E$B65A1A02511883B158F736061C040B88@libero.it> 
Date: Wed, 12 Mar 2003 16:07:53 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <HBNK5E$B65A1A02511883B158F736061C040B88@libero.it>, "john151@libero
.it" writes:
> Hi Curtis hi all,
> essentially my considerations are: if i have two pre-calculated disjoint back
> up paths and i use opaque LSA to flood the link failure information,
> it could be a reasonable faster  way of proceeding instead of using RSVP if i
>  have an intelligence in the source routers (routers have to be able to switc
> h among the two LSPs if they receive that particular opaque LSA; note that fo
> r a restoration of many LSPs RSVP will work in series, but OSPF will work in 
> parallel with its flooding mechanism).
> So the basic question is: is it a reasonable way the use of OSPF  and opaque 
> LSA? Is there a reason to the use always RSVP for path protection, since, i t
> hink, increasing the LSPs corrupted by one link failure (if there are many ac
> tive LSPs on the link that goes down) the OSPF mechanism of flooding is more 
> efficient than using many RSVP messages from node that detects the failure to
> wards the LSPs senders?


You just described standby LSPs.

Apparently you don't understand how RSVP/TE works.

Each ingress discovers that the LSP is no longer feasible through RSVP
and through OSPF.  It determines how the topology has changed through
the flooded OSPF information.  If the paths are setup in advance, the
LSR doesn't care why one LSP is no longer feasible so it doesn't
matter if the RSVP or OSPF information arrives first.  It switches to
the other LSP immediately.

Not only is it reasonable, it is how existing implementations
currently work.

Curtis



From owner-mpls@UU.NET  Wed Mar 12 16:49:00 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24752
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 16:48:59 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftf13477
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 21:51:07 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoftf13227;
	Wed, 12 Mar 2003 21:50:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoftd00239
	for mpls-outgoing; Wed, 12 Mar 2003 21:24:44 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoftd00233
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 21:24:43 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoftd13126
	for <mpls@uu.net>; Wed, 12 Mar 2003 21:24:09 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftd06583
	for <mpls@uu.net>; Wed, 12 Mar 2003 21:24:08 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoftd06572
	for <mpls@uu.net>; Wed, 12 Mar 2003 21:24:08 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2CLO6Sc003458
	for <mpls@uu.net>; Wed, 12 Mar 2003 16:24:06 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA09331 for <mpls@uu.net>; Wed, 12 Mar 2003 16:24:05 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2CLO5Z19805 for mpls@uu.net; Wed, 12 Mar 2003 16:24:05 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoftd00040
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 21:22:12 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoftd12343
	for <mpls@UU.NET>; Wed, 12 Mar 2003 21:22:06 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftd15557
	for <mpls@UU.NET>; Wed, 12 Mar 2003 21:22:05 GMT
Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoftd15549
	for <mpls@UU.NET>; Wed, 12 Mar 2003 21:22:05 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA84764;
	Wed, 12 Mar 2003 16:21:18 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303122121.QAA84764@workhorse.fictitious.org>
To: "Nair, Girish (Girish)" <gnair@lucent.com>
cc: "'john151@libero.it'" <john151@libero.it>, mpls <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: Between OSPF RSVP... 
In-reply-to: Your message of "Wed, 12 Mar 2003 15:25:37 EST."
             <C77B73BC1A3ED4118C2000508BAD8A7C0651F476@ma8117exch001u.inse.lucent.com> 
Date: Wed, 12 Mar 2003 16:21:18 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <C77B73BC1A3ED4118C2000508BAD8A7C0651F476@ma8117exch001u.inse.lucent
.com>, "Nair, Girish (Girish)" writes:
> Giovanni,
> 
> I agree. Link down LSP rerouting can be done a little more efficiently
> using the IGP. This has been done in some proprietary signaling
> implementations
> and works well. It involves tighter coupling between the IGP and signaling
> though.
> 
> Girish


There is nothing proprietary about this.  ***All*** IP routers that
implement OSPF/TE and/or ISIS/TE do this AFAIK and probably all LSR
that implement OSPF/TE and/or ISIS/TE (the remaining subset is mostly
ATM switches).

I welcome corrections from anyone that knows of an LSR that implements
OSPF/TE or ISIS/TE that doesn't use the flooded information as a hint
that some of the LSPs are down.

Curtis



From owner-mpls@UU.NET  Wed Mar 12 17:50:19 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27064
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 17:50:19 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftj27932
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 22:52:28 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoftj27755;
	Wed, 12 Mar 2003 22:52:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofth23975
	for mpls-outgoing; Wed, 12 Mar 2003 22:26:35 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofth23970
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 22:26:29 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofth20845
	for <mpls@UU.NET>; Wed, 12 Mar 2003 22:25:32 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofth00651
	for <mpls@UU.NET>; Wed, 12 Mar 2003 22:25:31 GMT
Received: from auemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: auemail1.lucent.com [192.11.223.161])
	id QQofth00633
	for <mpls@UU.NET>; Wed, 12 Mar 2003 22:25:31 GMT
Received: from ma8117exch001u.wins.lucent.com (h152-148-89-175.lucent.com [152.148.89.175])
	by auemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CMPT004538
	for <mpls@UU.NET>; Wed, 12 Mar 2003 17:25:29 -0500 (EST)
Received: by ma8117exch001u.inse.lucent.com with Internet Mail Service (5.5.2653.19)
	id <FZ113S48>; Wed, 12 Mar 2003 17:25:28 -0500
Message-ID: <C77B73BC1A3ED4118C2000508BAD8A7C0651F47B@ma8117exch001u.inse.lucent.com>
From: "Nair, Girish (Girish)" <gnair@lucent.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>
Cc: "'john151@libero.it'" <john151@libero.it>, mpls <mpls@UU.NET>
Subject: RE: Between OSPF RSVP... 
Date: Wed, 12 Mar 2003 17:25:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk



-----Original Message-----
From: Curtis Villamizar [mailto:curtis@fictitious.org]
Sent: Wednesday, March 12, 2003 4:21 PM
To: Nair, Girish (Girish)
Cc: 'john151@libero.it'; mpls
Subject: Re: Between OSPF RSVP... 



In message
<C77B73BC1A3ED4118C2000508BAD8A7C0651F476@ma8117exch001u.inse.lucent
.com>, "Nair, Girish (Girish)" writes:
> Giovanni,
> 
> I agree. Link down LSP rerouting can be done a little more efficiently
> using the IGP. This has been done in some proprietary signaling
> implementations
> and works well. It involves tighter coupling between the IGP and signaling
> though.
> 
> Girish


	There is nothing proprietary about this.  ***All*** IP routers that
	implement OSPF/TE and/or ISIS/TE do this AFAIK and probably all LSR
	that implement OSPF/TE and/or ISIS/TE (the remaining subset is
mostly
	ATM switches).

	I welcome corrections from anyone that knows of an LSR that
implements
	OSPF/TE or ISIS/TE that doesn't use the flooded information as a
hint
	that some of the LSPs are down.

	Curtis


Curtis,

When a link goes down, the LERs which had an LSP over that
link, get a Path Tear and intermediate nodes Path Tears or 
Resv Tears for each LSP affected. If this PSB 
clean up happens via OSPF-TE first, and each node cleans up 
intelligently, do the nodes just ignore the Path Tear or 
Resv Tear messages coming later? 

Girish









From owner-mpls@UU.NET  Wed Mar 12 18:26:22 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29609
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 18:26:22 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftl25849
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 23:28:30 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoftl25388;
	Wed, 12 Mar 2003 23:28:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoftj25914
	for mpls-outgoing; Wed, 12 Mar 2003 22:49:24 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoftj25905
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 22:49:18 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoftj05659
	for <mpls@uu.net>; Wed, 12 Mar 2003 22:49:06 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftj13893
	for <mpls@uu.net>; Wed, 12 Mar 2003 22:49:05 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoftj13880
	for <mpls@uu.net>; Wed, 12 Mar 2003 22:49:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2CMn2vD013524
	for <mpls@uu.net>; Wed, 12 Mar 2003 17:49:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA16358 for <mpls@uu.net>; Wed, 12 Mar 2003 17:49:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2CMn2a28196 for mpls@uu.net; Wed, 12 Mar 2003 17:49:02 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoftj25746
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 22:47:06 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoftj28052
	for <mpls@UU.NET>; Wed, 12 Mar 2003 22:46:32 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftj22461
	for <mpls@UU.NET>; Wed, 12 Mar 2003 22:46:32 GMT
Received: from auemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: auemail1.lucent.com [192.11.223.161])
	id QQoftj22451
	for <mpls@UU.NET>; Wed, 12 Mar 2003 22:46:31 GMT
Received: from ma8117exch001u.wins.lucent.com (h152-148-89-175.lucent.com [152.148.89.175])
	by auemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2CMkU014598
	for <mpls@UU.NET>; Wed, 12 Mar 2003 17:46:30 -0500 (EST)
Received: by ma8117exch001u.inse.lucent.com with Internet Mail Service (5.5.2653.19)
	id <FZ113T1K>; Wed, 12 Mar 2003 17:46:29 -0500
Message-ID: <C77B73BC1A3ED4118C2000508BAD8A7C085AC057@ma8117exch001u.inse.lucent.com>
From: "Muthukrishnan, Karthik (Karthik)" <mkarthik@lucent.com>
To: curtis@fictitious.org, "Nair, Girish (Girish)" <gnair@lucent.com>
Cc: "'john151@libero.it'" <john151@libero.it>, mpls <mpls@UU.NET>
Subject: RE: Between OSPF RSVP... 
Date: Wed, 12 Mar 2003 17:46:28 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Curtis:

For the ignorant, does AFAIK stand for "As Far As I Know" ?

And ".. probably.. " imply these LSRs may or may not be capable of matching
IGP info with waiting-to-be-notified-of-failure LSPs ?

Maybe a good question to ask is "which IP routers that implement
OSPF/TE or ISIS/TE and use the flooded IGP information as a hint
that some of the LSPs are down?". We could then take lack of an answer
seriously.

John: to answer your question, pre-standard [proprietary] implementations
such as VNN have supported this for the last decade. For more details,
please feel free to unicast your questions to me.

-Karthik

-----Original Message-----
From: Curtis Villamizar [mailto:curtis@fictitious.org]
Sent: Wednesday, March 12, 2003 4:21 PM
To: Nair, Girish (Girish)
Cc: 'john151@libero.it'; mpls
Subject: Re: Between OSPF RSVP... 



In message
<C77B73BC1A3ED4118C2000508BAD8A7C0651F476@ma8117exch001u.inse.lucent
.com>, "Nair, Girish (Girish)" writes:
> Giovanni,
> 
> I agree. Link down LSP rerouting can be done a little more efficiently
> using the IGP. This has been done in some proprietary signaling
> implementations
> and works well. It involves tighter coupling between the IGP and signaling
> though.
> 
> Girish


There is nothing proprietary about this.  ***All*** IP routers that
implement OSPF/TE and/or ISIS/TE do this AFAIK and probably all LSR
that implement OSPF/TE and/or ISIS/TE (the remaining subset is mostly
ATM switches).

I welcome corrections from anyone that knows of an LSR that implements
OSPF/TE or ISIS/TE that doesn't use the flooded information as a hint
that some of the LSPs are down.

Curtis



From owner-mpls@UU.NET  Wed Mar 12 18:53:29 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00538
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 18:53:29 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftn18507
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 23:55:38 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoftn17817;
	Wed, 12 Mar 2003 23:55:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoftk02745
	for mpls-outgoing; Wed, 12 Mar 2003 23:01:05 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoftk02546
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 23:00:59 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoftk27476
	for <mpls@uu.net>; Wed, 12 Mar 2003 23:00:09 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftk04506
	for <mpls@uu.net>; Wed, 12 Mar 2003 23:00:08 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoftk04484
	for <mpls@uu.net>; Wed, 12 Mar 2003 23:00:07 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2CN04Sc018531
	for <mpls@uu.net>; Wed, 12 Mar 2003 18:00:04 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA17071 for <mpls@uu.net>; Wed, 12 Mar 2003 18:00:04 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2CN04j29748 for mpls@uu.net; Wed, 12 Mar 2003 18:00:04 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoftj26504
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 22:58:11 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoftj01268
	for <mpls@UU.NET>; Wed, 12 Mar 2003 22:57:51 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftj29581
	for <mpls@UU.NET>; Wed, 12 Mar 2003 22:57:51 GMT
Received: from ams-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ams-msg-core-1.cisco.com [144.254.74.60])
	id QQoftj29553
	for <mpls@UU.NET>; Wed, 12 Mar 2003 22:57:50 GMT
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2CMu6nB010578;
	Wed, 12 Mar 2003 23:56:06 +0100 (MET)
Received: from JVASSEUR-W2K.cisco.com (ch2-dhcp134-209.cisco.com [161.44.134.209])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id XAA26589;
	Wed, 12 Mar 2003 23:57:47 +0100 (MET)
Message-Id: <4.3.2.7.2.20030312175452.0528e018@paris.cisco.com>
X-Sender: jvasseur@paris.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 12 Mar 2003 17:57:46 -0500
To: "john151@libero.it" <john151@libero.it>
From: Jean Philippe Vasseur <jvasseur@cisco.com>
Subject: Re: Between OSPF RSVP...
Cc: "mpls" <mpls@UU.NET>
In-Reply-To: <HBMTM4$875FAF0F2AFF01D1398F99ACE02AFA7C@libero.it>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

At 11:39 12/03/2003 +0100, john151@libero.it wrote:
>Hi all,
>I' m interesting in protection/restoration (P/R) mechanisms and after 
>having read some works, i' d like to do some observations.
>In a TE path protection scenario, there are works dealing with the use of 
>RSVP-TE messages to signal, in  example,
>a link failure.
>But could it have sense this other way of recovery?
>...After a detection of a failure, OSPF ( OSPF-TE ) uses the flooding 
>mechanism to advertise the all network that one link is broken
>( ... using opaque LSA? ); then all nodes, receiving the LSA with this 
>information, could compute an analysis of what LSPs ( LSP having source in 
>that node ) are interested by the failure. Then, in example, each node 
>that wants to do restoration in a MPLS scenario could make a Label 
>Switching if there is a Backup Path available.
>This approach has some problem:
>-   a faster trigger on OSPF in detecting failure, since HELLO mechanism 
>is slow;
>-   the prioriting of the sequence ---flooding LSA---  and  then 
>---computing SPF algorithm--- to do faster;
>-   the adding of intelligence in each node to do the Switching.
>
>I know that these are only some observations containing ( i hope few ) 
>errors and that aren't complete, but since i haven' t found any P/R 
>mechanisms in a TE scenario using OSPF ( or any optimized version of this 
>), i' d like to make you a question:
>is this a possible way of study ( as an alternative to RSVP signalling ) 
>or is completely wrong and out of all standards?

any HE LSR detecting a TE LSP failure via any mean (receipt of Path Error, 
IGP notification, ...) does trigger the appropriate action: switch the 
traffic onto a secondary LSP (with Path Protection), reroute the TE LSP 
(global restoration) ...  So, yes, both the PERR and IGP notification are 
used by the HE LSR to monitor the TE LSP state.

JP.

>Thanks in advance for your kind answers and observations.
>
>Giovanni Di Giacomo



From owner-mpls@UU.NET  Wed Mar 12 18:56:38 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00621
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 18:56:38 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftn00595
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 23:58:46 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoftn00247;
	Wed, 12 Mar 2003 23:58:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoftk12265
	for mpls-outgoing; Wed, 12 Mar 2003 23:04:26 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoftk11825
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 23:04:22 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoftk23216
	for <mpls@uu.net>; Wed, 12 Mar 2003 23:04:08 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftk12459
	for <mpls@uu.net>; Wed, 12 Mar 2003 23:04:07 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoftk12427
	for <mpls@uu.net>; Wed, 12 Mar 2003 23:04:07 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2CN44vD014554
	for <mpls@uu.net>; Wed, 12 Mar 2003 18:04:04 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA17366 for <mpls@uu.net>; Wed, 12 Mar 2003 18:04:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2CN43400520 for mpls@uu.net; Wed, 12 Mar 2003 18:04:03 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoftk07092
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 23:02:48 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoftk19625
	for <mpls@UU.NET>; Wed, 12 Mar 2003 23:01:54 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftk07858
	for <mpls@UU.NET>; Wed, 12 Mar 2003 23:01:54 GMT
Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoftk07829
	for <mpls@UU.NET>; Wed, 12 Mar 2003 23:01:52 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id SAA85357;
	Wed, 12 Mar 2003 18:01:04 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303122301.SAA85357@workhorse.fictitious.org>
To: "Nair, Girish (Girish)" <gnair@lucent.com>
cc: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "'john151@libero.it'" <john151@libero.it>, mpls <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: Between OSPF RSVP... 
In-reply-to: Your message of "Wed, 12 Mar 2003 17:25:27 EST."
             <C77B73BC1A3ED4118C2000508BAD8A7C0651F47B@ma8117exch001u.inse.lucent.com> 
Date: Wed, 12 Mar 2003 18:01:04 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <C77B73BC1A3ED4118C2000508BAD8A7C0651F47B@ma8117exch001u.inse.lucent
.com>, "Nair, Girish (Girish)" writes:
> 
> 
> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@fictitious.org]
> Sent: Wednesday, March 12, 2003 4:21 PM
> To: Nair, Girish (Girish)
> Cc: 'john151@libero.it'; mpls
> Subject: Re: Between OSPF RSVP... 
> 
> 
> 
> In message
> <C77B73BC1A3ED4118C2000508BAD8A7C0651F476@ma8117exch001u.inse.lucent
> .com>, "Nair, Girish (Girish)" writes:
> > Giovanni,
> > 
> > I agree. Link down LSP rerouting can be done a little more efficiently
> > using the IGP. This has been done in some proprietary signaling
> > implementations
> > and works well. It involves tighter coupling between the IGP and signaling
> > though.
> > 
> > Girish
> 
> 
> 	There is nothing proprietary about this.  ***All*** IP routers that
> 	implement OSPF/TE and/or ISIS/TE do this AFAIK and probably all LSR
> 	that implement OSPF/TE and/or ISIS/TE (the remaining subset is
> mostly
> 	ATM switches).
> 
> 	I welcome corrections from anyone that knows of an LSR that
> implements
> 	OSPF/TE or ISIS/TE that doesn't use the flooded information as a
> hint
> 	that some of the LSPs are down.
> 
> 	Curtis
> 
> 
Curtis,
> 
> When a link goes down, the LERs which had an LSP over that
> link, get a Path Tear and intermediate nodes Path Tears or 
> Resv Tears for each LSP affected. If this PSB 
> clean up happens via OSPF-TE first, and each node cleans up 
> intelligently, do the nodes just ignore the Path Tear or 
> Resv Tear messages coming later? 
> 
> Girish


The path tear is specific to a particular LSP.  A new LSP is created,
sharing the resources (which handles the case where not all downstream
nodes know the original went down) but distinct from the first.
Traffic is switched to the new LSP.  The LSP is then torn down if the
Path Tear has not yet arrived.

If the path tear arrives after the new LSP comes up that's OK too
because the new LSP is distinct from the old one and is unaffected.
If tears are lost and some resources of the old LSP time out then
thats almost OK (in some cases, not really) since the new LSP shares
resources with the old.

AFAIK ***every*** LSR does this.

If the "new" LSP is presignaled then some time is saved and the
recovery is often complete before the path tear arrives.  This is very
much implementation dependent with some implementations flooding IGP
change faster than propogating RSVP and others propogating RSVP
changes faster.

This is the same procedure as a make-before-break reroute but with a
somewhat involuntary trigger on the reroute.

Curtis



From owner-mpls@UU.NET  Wed Mar 12 18:57:35 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00656
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 18:57:35 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftn27074
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 23:59:42 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoftn25966;
	Wed, 12 Mar 2003 23:59:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoftk12311
	for mpls-outgoing; Wed, 12 Mar 2003 23:04:27 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoftk11088
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 23:04:14 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoftk15624
	for <mpls@uu.net>; Wed, 12 Mar 2003 23:04:06 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftk10266
	for <mpls@uu.net>; Wed, 12 Mar 2003 23:04:05 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoftk10262
	for <mpls@uu.net>; Wed, 12 Mar 2003 23:04:04 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2CN42Sc019160
	for <mpls@uu.net>; Wed, 12 Mar 2003 18:04:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA17362 for <mpls@uu.net>; Wed, 12 Mar 2003 18:04:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2CN41S00474 for mpls@uu.net; Wed, 12 Mar 2003 18:04:01 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoftk06096
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 23:02:25 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoftk07478
	for <mpls@UU.NET>; Wed, 12 Mar 2003 23:02:09 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftk08342
	for <mpls@UU.NET>; Wed, 12 Mar 2003 23:02:08 GMT
Received: from ams-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ams-msg-core-1.cisco.com [144.254.74.60])
	id QQoftk08289
	for <mpls@UU.NET>; Wed, 12 Mar 2003 23:02:07 GMT
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2CN0LtO011085;
	Thu, 13 Mar 2003 00:00:21 +0100 (MET)
Received: from JVASSEUR-W2K.cisco.com (ch2-dhcp134-209.cisco.com [161.44.134.209])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id AAA26777;
	Thu, 13 Mar 2003 00:02:02 +0100 (MET)
Message-Id: <4.3.2.7.2.20030312180136.039b2958@paris.cisco.com>
X-Sender: jvasseur@paris.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 12 Mar 2003 18:02:00 -0500
To: "Nair, Girish (Girish)" <gnair@lucent.com>
From: Jean Philippe Vasseur <jvasseur@cisco.com>
Subject: RE: Re: Between OSPF RSVP...
Cc: "'john151@libero.it'" <john151@libero.it>, mpls <mpls@UU.NET>
In-Reply-To: <C77B73BC1A3ED4118C2000508BAD8A7C0651F476@ma8117exch001u.in
 se.lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

At 15:25 12/03/2003 -0500, Nair, Girish (Girish) wrote:
>Giovanni,
>
>I agree. Link down LSP rerouting can be done a little more efficiently
>using the IGP. This has been done in some proprietary signaling
>implementations
>and works well. It involves tighter coupling between the IGP and signaling
>though.

You do not need any proprietary signalling protocol here.

JP.

>Girish
>
>-----Original Message-----
>From: john151@libero.it [mailto:john151@libero.it]
>Sent: Wednesday, March 12, 2003 3:13 PM
>To: mpls
>Subject: Re:Re: Between OSPF RSVP...
>
>
>Hi Curtis hi all,
>essentially my considerations are: if i have two pre-calculated disjoint
>backup paths and i use opaque LSA to flood the link failure information,
>it could be a reasonable faster  way of proceeding instead of using RSVP if
>i have an intelligence in the source routers (routers have to be able to
>switch among the two LSPs if they receive that particular opaque LSA; note
>that for a restoration of many LSPs RSVP will work in series, but OSPF will
>work in parallel with its flooding mechanism).
>So the basic question is: is it a reasonable way the use of OSPF  and opaque
>LSA? Is there a reason to the use always RSVP for path protection, since, i
>think, increasing the LSPs corrupted by one link failure (if there are many
>active LSPs on the link that goes down) the OSPF mechanism of flooding is
>more efficient than using many RSVP messages from node that detects the
>failure towards the LSPs senders?
>
>Thanks in advance for your kind answers and observations.
>
>Giovanni Di Giacomo
>
>
>In message <HBMTM4$875FAF0F2AFF01D1398F99ACE02AFA7C@libero.it>,
>"john151@libero
>.it" writes:
> > Hi all,
> > I' m interesting in protection/restoration (P/R) mechanisms and after
>having
> > read some works, i' d like to do some observations.
> > In a TE path protection scenario, there are works dealing with the use of
>RSV
> > P-TE messages to signal, in  example,
> > a link failure.
> > But could it have sense this other way of recovery?
> > ...After a detection of a failure, OSPF ( OSPF-TE ) uses the flooding
>mechani
> > sm to advertise the all network that one link is broken
> > ( ... using opaque LSA? ); then all nodes, receiving the LSA with this
>inform
> > ation, could compute an analysis of what LSPs ( LSP having source in that
>nod
> > e ) are interested by the failure. Then, in example, each node that wants
>to
> > do restoration in a MPLS scenario could make a Label Switching if there is
>a
> > Backup Path available.
> > This approach has some problem:
> > -   a faster trigger on OSPF in detecting failure, since HELLO mechanism
>is s
> > low;
> > -   the prioriting of the sequence ---flooding LSA---  and  then
>---computing
> >  SPF algorithm--- to do faster;
> > -   the adding of intelligence in each node to do the Switching.
> >
> > I know that these are only some observations containing ( i hope few )
>errors
> >  and that aren't complete, but since i haven' t found any P/R mechanisms
>in a
> >  TE scenario using OSPF ( or any optimized version of this ), i' d like to
>ma
> > ke you a question:
> > is this a possible way of study ( as an alternative to RSVP signalling )
>or i
> > s completely wrong and out of all standards?
> >
> > Thanks in advance for your kind answers and observations.
> >
> > Giovanni Di Giacomo
>
>
>OSPF/TE already uses the SONET framing detection to trigger fast
>flooding of link down.  This is a FAQ.
>
>Ingress then quickly find any affected LSPs (the quickly part is an
>implementation detail, but reasonable implementations don't do a
>search of all LSPs but rather have this information already available
>as a data structure hung off the TE-LSDB entry for the link).
>
>Presignaled disjoint backup LSPs from the ingress are known as
>"standby" LSP and are implemented by most LSR as an alternate to FRR.
>In practice, standby LSP provide anywhere from sub second to a few
>second restoration AFAIK.  Otherwise the ingress must resignal the
>affected LSPs on new paths.  This is supposed to take just a few
>seconds but in practice if a lot of LSPs are affected most LSR seem to
>fall back to IP forwarding and get the LSPs up in 10s of seconds.
>Implementations are improving and getting this to consistently a few
>seconds, even for large topologies and large numbers of affected LSPs
>is being discussed elsewhere usually referred to as the "fast
>convergence" problem.
>
>LDP makes direct use of the OSPF derived next-hop.
>
>Curtis



From owner-mpls@UU.NET  Wed Mar 12 19:06:17 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00934
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 19:06:16 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofto12853
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 00:08:25 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofto12601;
	Thu, 13 Mar 2003 00:08:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoftl17554
	for mpls-outgoing; Wed, 12 Mar 2003 23:22:45 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoftl17540
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 23:22:38 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoftl13996
	for <mpls@uu.net>; Wed, 12 Mar 2003 23:22:12 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftl13468
	for <mpls@uu.net>; Wed, 12 Mar 2003 23:22:11 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoftl13439
	for <mpls@uu.net>; Wed, 12 Mar 2003 23:22:11 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2CNM7Sc021396
	for <mpls@uu.net>; Wed, 12 Mar 2003 18:22:08 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA18543 for <mpls@uu.net>; Wed, 12 Mar 2003 18:22:07 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2CNM7W04304 for mpls@uu.net; Wed, 12 Mar 2003 18:22:07 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoftl17260
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 23:20:13 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoftl17656
	for <mpls@UU.NET>; Wed, 12 Mar 2003 23:19:36 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftl27993
	for <mpls@UU.NET>; Wed, 12 Mar 2003 23:19:35 GMT
Received: from smtp1.phx.gblx.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp1.phx.gblx.net [64.208.25.103])
	id QQoftl27987
	for <mpls@UU.NET>; Wed, 12 Mar 2003 23:19:35 GMT
Received: (from daemon@localhost)
	by smtp1.phx.gblx.net (8.11.2/8.11.2) id h2CNJYn03497;
	Wed, 12 Mar 2003 16:19:34 -0700 (MST)
Received: from shell1.phx.gblx.net(64.208.25.102)
 via SMTP by smtp1.phx.gblx.net, id smtpdAAAFEaiZg; Wed Mar 12 16:19:24 2003
Received: (from mmeyer@localhost)
	by shell1.phx.gblx.net (8.9.3+Sun/8.9.3) id QAA28843;
	Wed, 12 Mar 2003 16:19:24 -0700 (MST)
Date: Wed, 12 Mar 2003 16:19:24 -0700
From: Matthew Meyer <mrm@gblx.net>
To: Curtis Villamizar <curtis@fictitious.org>
Cc: "Nair, Girish (Girish)" <gnair@lucent.com>,
        "'john151@libero.it'" <john151@libero.it>, mpls <mpls@UU.NET>
Subject: Re: Between OSPF RSVP...
Message-ID: <20030312231923.GP23300@gblx.net>
References: <C77B73BC1A3ED4118C2000508BAD8A7C0651F476@ma8117exch001u.inse.lucent.com> <200303122121.QAA84764@workhorse.fictitious.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200303122121.QAA84764@workhorse.fictitious.org>
User-Agent: Mutt/1.4i
Sender: owner-mpls@UU.NET
Precedence: bulk


Thus spake Curtis Villamizar (curtis@fictitious.org):

 |
 |I welcome corrections from anyone that knows of an LSR that implements
 |OSPF/TE or ISIS/TE that doesn't use the flooded information as a hint
 |that some of the LSPs are down.
 |

I know of one, though that may have been on old code.  Regardless,
for the sake of interoperability with less intelligent code, I'd
think folks would agree one would not want to skip sending the 
tears on link-down, at least by default.  

Another point to consider is that IGP convergence is a function of 
network size and IGP tuning. It wasn't too long ago that a number
vendors were less aggressive in their IGP tuning due to processor
constraints and other factors.  As a result it has been my 
observation that many networks have resisted the urge to 'jump in'
and retune their IGP (memories of meltdowns die hard).  Knowing 
that IGP arrival beats RSVP in a lab or on certain code + certain
vendor is one thing, assuming these features are deployed optimally
and on all platforms is quite another.

Because of the number of variables relating to customer and vendor 
implementation choices, a skip-sending-tear-on-link-down feature
would IMO get implemented (if at all) as a vendor specific knob.
Translate: this isn't standards material. :-/

Matthew



From owner-mpls@UU.NET  Wed Mar 12 19:10:51 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01032
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 19:10:51 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofto17991
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 00:13:00 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofto17876;
	Thu, 13 Mar 2003 00:12:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoftm18484
	for mpls-outgoing; Wed, 12 Mar 2003 23:32:27 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoftm18473
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 23:32:24 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoftm13792
	for <mpls@uu.net>; Wed, 12 Mar 2003 23:32:09 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftm03155
	for <mpls@uu.net>; Wed, 12 Mar 2003 23:32:09 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoftm03135
	for <mpls@uu.net>; Wed, 12 Mar 2003 23:32:08 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2CNW6vD016279
	for <mpls@uu.net>; Wed, 12 Mar 2003 18:32:06 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA19130 for <mpls@uu.net>; Wed, 12 Mar 2003 18:32:06 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2CNW5c07006 for mpls@uu.net; Wed, 12 Mar 2003 18:32:05 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoftl18158
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Mar 2003 23:29:49 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoftl01791
	for <mpls@UU.NET>; Wed, 12 Mar 2003 23:29:14 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftl23771
	for <mpls@UU.NET>; Wed, 12 Mar 2003 23:29:13 GMT
Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoftl23736
	for <mpls@UU.NET>; Wed, 12 Mar 2003 23:29:12 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id SAA85571;
	Wed, 12 Mar 2003 18:28:23 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303122328.SAA85571@workhorse.fictitious.org>
To: "Muthukrishnan, Karthik (Karthik)" <mkarthik@lucent.com>
cc: curtis@fictitious.org, "Nair, Girish (Girish)" <gnair@lucent.com>,
        "'john151@libero.it'" <john151@libero.it>, mpls <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: Between OSPF RSVP... 
In-reply-to: Your message of "Wed, 12 Mar 2003 17:46:28 EST."
             <C77B73BC1A3ED4118C2000508BAD8A7C085AC057@ma8117exch001u.inse.lucent.com> 
Date: Wed, 12 Mar 2003 18:28:23 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <C77B73BC1A3ED4118C2000508BAD8A7C085AC057@ma8117exch001u.inse.lucent
.com>, "Muthukrishnan, Karthik (Karthik)" writes:
> Curtis:
> 
> For the ignorant, does AFAIK stand for "As Far As I Know" ?

It has since USENET in the 1980s.

> And ".. probably.. " imply these LSRs may or may not be capable of matching
> IGP info with waiting-to-be-notified-of-failure LSPs ?

No.  "Probably" just meant that I have less confidence in the ATM
switch vendors in this area.

> Maybe a good question to ask is "which IP routers that implement
> OSPF/TE or ISIS/TE and use the flooded IGP information as a hint
> that some of the LSPs are down?". We could then take lack of an answer
> seriously.

OK.  I know for a fact that Avici does this.  Anyone else?

Since we've never explicitly tested for this, just assumed this
behaviour, it is possible that some other routers don't do this, but
this topic on the MPLS list dates back at least 5 years.

Both positive and negative responses welcome.

> John: to answer your question, pre-standard [proprietary] implementations
> such as VNN have supported this for the last decade. For more details,
> please feel free to unicast your questions to me.

Note that deployed LSRs are carrying over 1,000 MPLS/TE LSP per
direction on an interface (someone can chime in with a bigger number
if they like) so on failure, one OSPF LSA or ISIS LSPDU fragment needs
to be advertised and over 1,000 path tears on the ingress side, plus
resv tears since the same interface is the egress side of other LSPs.
Its more efficient to flood the one IGP packet upstream to the
multiple ingress that are affected than 2,000 other messages.

There is nothing magic about using the link state information to
deduce that a path is no longer feasible.  A good implementatio,
having chosen a path can add an LSP to the linked list of LSPs
dependent on each link.  When the link goes down, figuring out which
LSPs are affected amounts to walking a linked list.  Adds about 16
bytes of overhead per link in the path, but saves time on failure when
saving time matters.

> -Karthik

Curtis


> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@fictitious.org]
> Sent: Wednesday, March 12, 2003 4:21 PM
> To: Nair, Girish (Girish)
> Cc: 'john151@libero.it'; mpls
> Subject: Re: Between OSPF RSVP... 
> 
> 
> 
> In message
> <C77B73BC1A3ED4118C2000508BAD8A7C0651F476@ma8117exch001u.inse.lucent
> .com>, "Nair, Girish (Girish)" writes:
> > Giovanni,
> > 
> > I agree. Link down LSP rerouting can be done a little more efficiently
> > using the IGP. This has been done in some proprietary signaling
> > implementations
> > and works well. It involves tighter coupling between the IGP and signaling
> > though.
> > 
> > Girish
> 
> 
> There is nothing proprietary about this.  ***All*** IP routers that
> implement OSPF/TE and/or ISIS/TE do this AFAIK and probably all LSR
> that implement OSPF/TE and/or ISIS/TE (the remaining subset is mostly
> ATM switches).
> 
> I welcome corrections from anyone that knows of an LSR that implements
> OSPF/TE or ISIS/TE that doesn't use the flooded information as a hint
> that some of the LSPs are down.
> 
> Curtis
> 



From owner-mpls@UU.NET  Wed Mar 12 20:14:49 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02469
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 20:14:49 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftt16639
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 01:16:58 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoftt16439;
	Thu, 13 Mar 2003 01:16:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoftq12707
	for mpls-outgoing; Thu, 13 Mar 2003 00:36:49 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoftq12702
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 00:36:39 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoftq26787
	for <mpls@uu.net>; Thu, 13 Mar 2003 00:36:09 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftq09604
	for <mpls@uu.net>; Thu, 13 Mar 2003 00:36:07 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoftq09536
	for <mpls@uu.net>; Thu, 13 Mar 2003 00:36:06 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2D0a2Sc029094
	for <mpls@uu.net>; Wed, 12 Mar 2003 19:36:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA22607 for <mpls@uu.net>; Wed, 12 Mar 2003 19:36:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2D0a2r19001 for mpls@uu.net; Wed, 12 Mar 2003 19:36:02 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoftq12482
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 00:34:38 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoftq25160
	for <mpls@UU.NET>; Thu, 13 Mar 2003 00:34:04 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftq06408
	for <mpls@UU.NET>; Thu, 13 Mar 2003 00:34:01 GMT
Received: from ams-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ams-msg-core-1.cisco.com [144.254.74.60])
	id QQoftq06355
	for <mpls@UU.NET>; Thu, 13 Mar 2003 00:34:00 GMT
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2D0VlPm018783;
	Thu, 13 Mar 2003 01:31:47 +0100 (MET)
Received: from JVASSEUR-W2K.cisco.com (ch2-dhcp134-209.cisco.com [161.44.134.209])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id BAA00384;
	Thu, 13 Mar 2003 01:33:27 +0100 (MET)
Message-Id: <4.3.2.7.2.20030312192825.067979c0@paris.cisco.com>
X-Sender: jvasseur@paris.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 12 Mar 2003 19:33:26 -0500
To: curtis@fictitious.org
From: Jean Philippe Vasseur <jvasseur@cisco.com>
Subject: Re: Between OSPF RSVP... 
Cc: "Muthukrishnan, Karthik (Karthik)" <mkarthik@lucent.com>,
        curtis@fictitious.org, "Nair, Girish (Girish)" <gnair@lucent.com>,
        "'john151@libero.it'" <john151@libero.it>, mpls <mpls@UU.NET>
In-Reply-To: <200303122328.SAA85571@workhorse.fictitious.org>
References: <Your message of "Wed, 12 Mar 2003 17:46:28 EST." <C77B73BC1A3ED4118C2000508BAD8A7C085AC057@ma8117exch001u.inse.lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

At 18:28 12/03/2003 -0500, Curtis Villamizar wrote:

>In message 
><C77B73BC1A3ED4118C2000508BAD8A7C085AC057@ma8117exch001u.inse.lucent
>.com>, "Muthukrishnan, Karthik (Karthik)" writes:
> > Curtis:
> >
> > For the ignorant, does AFAIK stand for "As Far As I Know" ?
>
>It has since USENET in the 1980s.
>
> > And ".. probably.. " imply these LSRs may or may not be capable of matching
> > IGP info with waiting-to-be-notified-of-failure LSPs ?
>
>No.  "Probably" just meant that I have less confidence in the ATM
>switch vendors in this area.
>
> > Maybe a good question to ask is "which IP routers that implement
> > OSPF/TE or ISIS/TE and use the flooded IGP information as a hint
> > that some of the LSPs are down?". We could then take lack of an answer
> > seriously.
>
>OK.  I know for a fact that Avici does this.  Anyone else?

CISCO.

>Since we've never explicitly tested for this, just assumed this
>behaviour, it is possible that some other routers don't do this, but
>this topic on the MPLS list dates back at least 5 years.
>
>Both positive and negative responses welcome.
>
> > John: to answer your question, pre-standard [proprietary] implementations
> > such as VNN have supported this for the last decade. For more details,
> > please feel free to unicast your questions to me.
>
>Note that deployed LSRs are carrying over 1,000 MPLS/TE LSP per
>direction on an interface (someone can chime in with a bigger number
>if they like) so on failure, one OSPF LSA or ISIS LSPDU fragment needs
>to be advertised and over 1,000 path tears on the ingress side, plus
>resv tears since the same interface is the egress side of other LSPs.
>Its more efficient to flood the one IGP packet upstream to the
>multiple ingress that are affected than 2,000 other messages.

As previously mentioned both failures indication are detected by the HE 
(PERR and IGP). IGP LSA/LSP might (or not) get received after the PERR 
(depending on the IGP tuning) but as you also mentioned, that does not 
really matter.

We mentioned IGP update reporting a link failure. Same reasoning applies to 
ISIS LP w/ overload bit set, OSPF LSA Maxage, ...

JP.

>There is nothing magic about using the link state information to
>deduce that a path is no longer feasible.  A good implementatio,
>having chosen a path can add an LSP to the linked list of LSPs
>dependent on each link.  When the link goes down, figuring out which
>LSPs are affected amounts to walking a linked list.  Adds about 16
>bytes of overhead per link in the path, but saves time on failure when
>saving time matters.
>
> > -Karthik
>
>Curtis
>
>
> > -----Original Message-----
> > From: Curtis Villamizar [mailto:curtis@fictitious.org]
> > Sent: Wednesday, March 12, 2003 4:21 PM
> > To: Nair, Girish (Girish)
> > Cc: 'john151@libero.it'; mpls
> > Subject: Re: Between OSPF RSVP...
> >
> >
> >
> > In message
> > <C77B73BC1A3ED4118C2000508BAD8A7C0651F476@ma8117exch001u.inse.lucent
> > .com>, "Nair, Girish (Girish)" writes:
> > > Giovanni,
> > >
> > > I agree. Link down LSP rerouting can be done a little more efficiently
> > > using the IGP. This has been done in some proprietary signaling
> > > implementations
> > > and works well. It involves tighter coupling between the IGP and 
> signaling
> > > though.
> > >
> > > Girish
> >
> >
> > There is nothing proprietary about this.  ***All*** IP routers that
> > implement OSPF/TE and/or ISIS/TE do this AFAIK and probably all LSR
> > that implement OSPF/TE and/or ISIS/TE (the remaining subset is mostly
> > ATM switches).
> >
> > I welcome corrections from anyone that knows of an LSR that implements
> > OSPF/TE or ISIS/TE that doesn't use the flooded information as a hint
> > that some of the LSPs are down.
> >
> > Curtis
> >



From owner-mpls@UU.NET  Wed Mar 12 20:16:31 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02513
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 20:16:31 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftt24692
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 01:18:40 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoftt24459;
	Thu, 13 Mar 2003 01:18:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoftq12997
	for mpls-outgoing; Thu, 13 Mar 2003 00:42:21 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoftq12791
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 00:40:07 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoftq20223
	for <mpls@uu.net>; Thu, 13 Mar 2003 00:39:45 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftq19056
	for <mpls@uu.net>; Thu, 13 Mar 2003 00:39:22 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoftq18690
	for <mpls@uu.net>; Thu, 13 Mar 2003 00:39:15 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2D0d2Sc029333
	for <mpls@uu.net>; Wed, 12 Mar 2003 19:39:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA22735 for <mpls@uu.net>; Wed, 12 Mar 2003 19:39:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2D0d2h19159 for mpls@uu.net; Wed, 12 Mar 2003 19:39:02 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoftq12711
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 00:37:08 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoftq06813
	for <mpls@UU.NET>; Thu, 13 Mar 2003 00:36:41 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftq09127
	for <mpls@UU.NET>; Thu, 13 Mar 2003 00:36:39 GMT
Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoftq09027
	for <mpls@UU.NET>; Thu, 13 Mar 2003 00:36:37 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id TAA85838;
	Wed, 12 Mar 2003 19:35:40 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303130035.TAA85838@workhorse.fictitious.org>
To: Matthew Meyer <mrm@gblx.net>
cc: Curtis Villamizar <curtis@fictitious.org>,
        "Nair,
    Girish (Girish)" <gnair@lucent.com>,
        "'john151@libero.it'" <john151@libero.it>, mpls <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: Between OSPF RSVP... 
In-reply-to: Your message of "Wed, 12 Mar 2003 16:19:24 MST."
             <20030312231923.GP23300@gblx.net> 
Date: Wed, 12 Mar 2003 19:35:40 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <20030312231923.GP23300@gblx.net>, Matthew Meyer writes:
> 
> Thus spake Curtis Villamizar (curtis@fictitious.org):
> 
>  |
>  |I welcome corrections from anyone that knows of an LSR that implements
>  |OSPF/TE or ISIS/TE that doesn't use the flooded information as a hint
>  |that some of the LSPs are down.
>  |
> 
> I know of one, though that may have been on old code.  Regardless,
> for the sake of interoperability with less intelligent code, I'd
> think folks would agree one would not want to skip sending the 
> tears on link-down, at least by default.  

Absolutely.  Always send the tears becasue this does the resource
cleanup.  The IGP hint just makes convergence go faster.  The ingress
teardown can't replace the resv tears past the point of failure.  Also
multiple failures (due to SRLG) can create isolated middle segments of
the former path.  Getting the midpoints to clean up quickly frees
resources that may be needed.

> Another point to consider is that IGP convergence is a function of 
> network size and IGP tuning. It wasn't too long ago that a number
> vendors were less aggressive in their IGP tuning due to processor
> constraints and other factors.  As a result it has been my 
> observation that many networks have resisted the urge to 'jump in'
> and retune their IGP (memories of meltdowns die hard).  Knowing 
> that IGP arrival beats RSVP in a lab or on certain code + certain
> vendor is one thing, assuming these features are deployed optimally
> and on all platforms is quite another.

I'm quite sure you know this but for the benefit of others.

Two things changed.  One is that vendors used to start the SPF and
then flood.  Flooding was really slow and this issue was discussed as
operational experience at NANOG.  The other is that vendors decided
that the origination delay after quiescence should be zero.  Dave Katz
(Juniper) has argued for very fast reflood essentially eliminating any
protocol imposed flooding delay.

The result has been convergence has been getting faster for all of the
major routers who all seem to be paying attention to and participating
in this discussion at NANOG.  (Yes Scotty, there is intellegent life
at NANOG, and it seems friendly enough).

[Discussing operator experience as a means to improve protocols and
protocol implementations - what a concept!]

> Because of the number of variables relating to customer and vendor 
> implementation choices, a skip-sending-tear-on-link-down feature
> would IMO get implemented (if at all) as a vendor specific knob.
> Translate: this isn't standards material. :-/

The skip-sending-tear-on-link-down would be a real bad idea and I
don't think it should even be implemented as an option.

Sounds like you misinterpreted my suggestion or I missed something in
the suggestion that was originally posted.

The IGP and RSVP tears are both hints that the ingress can use to
determine that a link is down.  The former can be made more efficient
and faster but that doesn't mean the latter should be eliminated
because it still serves a purpose including among other things
interoperability.

> Matthew

In practice both arrive before all but a few CSPFs are redone so for
reroute its somewhat of a moot point.  For standby LSP the resoration
can be accomplished prior to processing a bombardment of PATH tears
and RESV tears that result from a failed link.  For subsecond standby
LSP resoration with lots of LSPs to restore this sort of optimization
is beneficial.

Curtis

ps - now back to out regularly scheduled arguments about
call/connection separation.  :(



From owner-mpls@UU.NET  Wed Mar 12 21:30:48 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04507
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 21:30:47 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofty20565
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 02:32:57 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofty20418;
	Thu, 13 Mar 2003 02:32:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoftw26323
	for mpls-outgoing; Thu, 13 Mar 2003 02:07:28 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoftw26318
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 02:07:21 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoftw02320
	for <mpls@uu.net>; Thu, 13 Mar 2003 02:07:05 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftw28529
	for <mpls@uu.net>; Thu, 13 Mar 2003 02:07:05 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoftw28510
	for <mpls@uu.net>; Thu, 13 Mar 2003 02:07:04 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2D272vD024113
	for <mpls@uu.net>; Wed, 12 Mar 2003 21:07:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA27088 for <mpls@uu.net>; Wed, 12 Mar 2003 21:07:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2D271u28101 for mpls@uu.net; Wed, 12 Mar 2003 21:07:01 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoftw25973
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 02:05:30 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoftw26962
	for <mpls@UU.NET>; Thu, 13 Mar 2003 02:05:20 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoftw10769
	for <mpls@UU.NET>; Thu, 13 Mar 2003 02:05:20 GMT
Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoftw10742
	for <mpls@UU.NET>; Thu, 13 Mar 2003 02:05:19 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id VAA86328;
	Wed, 12 Mar 2003 21:04:04 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303130204.VAA86328@workhorse.fictitious.org>
To: Jean Philippe Vasseur <jvasseur@cisco.com>
cc: curtis@fictitious.org,
        "Muthukrishnan,
    Karthik (Karthik)" <mkarthik@lucent.com>,
        "Nair,
    Girish (Girish)" <gnair@lucent.com>,
        "'john151@libero.it'" <john151@libero.it>, mpls <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: Between OSPF RSVP... 
In-reply-to: Your message of "Wed, 12 Mar 2003 19:33:26 EST."
             <4.3.2.7.2.20030312192825.067979c0@paris.cisco.com> 
Date: Wed, 12 Mar 2003 21:04:04 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <4.3.2.7.2.20030312192825.067979c0@paris.cisco.com>, Jean Philippe V
asseur writes:
> >
> >OK.  I know for a fact that Avici does this.  Anyone else?
> 
> CISCO.

Thank you.  I think we'll get a third affirmative shortly.

Curtis



From owner-mpls@UU.NET  Wed Mar 12 22:56:15 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06522
	for <mpls-archive@lists.ietf.org>; Wed, 12 Mar 2003 22:56:15 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofud15088
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 03:58:23 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofud14669;
	Thu, 13 Mar 2003 03:58:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofuc22351
	for mpls-outgoing; Thu, 13 Mar 2003 03:32:29 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofuc22341
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 03:32:22 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofuc11589
	for <mpls@UU.NET>; Thu, 13 Mar 2003 03:32:01 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofuc29661
	for <mpls@UU.NET>; Thu, 13 Mar 2003 03:32:00 GMT
Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQofuc29644
	for <mpls@UU.NET>; Thu, 13 Mar 2003 03:32:00 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2D3VxS09737;
	Wed, 12 Mar 2003 19:31:59 -0800 (PST)
	(envelope-from kireeti@juniper.net)
Received: from localhost (kireeti@localhost)
	by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h2D3VwF98302;
	Wed, 12 Mar 2003 19:31:59 -0800 (PST)
	(envelope-from kireeti@juniper.net)
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
Date: Wed, 12 Mar 2003 19:31:58 -0800 (PST)
From: Kireeti Kompella <kireeti@juniper.net>
To: Curtis Villamizar <curtis@fictitious.org>
cc: mpls <mpls@UU.NET>
Subject: Re: Between OSPF RSVP... 
In-Reply-To: <200303130204.VAA86328@workhorse.fictitious.org>
Message-ID: <20030312192338.O98279@kummer.juniper.net>
References: <200303130204.VAA86328@workhorse.fictitious.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Curtis et al,

On Wed, 12 Mar 2003, Curtis Villamizar wrote:

> > >OK.  I know for a fact that Avici does this.  Anyone else?
> >
> > CISCO.
>
> Thank you.  I think we'll get a third affirmative shortly.

Am I on cue? :-)

On the matter of OSPF vs. RSVP, in our experience, RSVP almost always
wins.  With Notifies instead of PathErrs (no hop-by-hop processing),
RSVP should always win (unless messages get lost).

Kireeti.


From owner-mpls@UU.NET  Thu Mar 13 00:42:47 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09496
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 00:42:47 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofuk07077
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 05:44:56 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofuk06786;
	Thu, 13 Mar 2003 05:44:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofuj06932
	for mpls-outgoing; Thu, 13 Mar 2003 05:17:49 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQofuj06922
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 05:17:47 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofuj15120
	for <mpls@uu.net>; Thu, 13 Mar 2003 05:16:11 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofuj18521
	for <mpls@uu.net>; Thu, 13 Mar 2003 05:16:09 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQofuj18471
	for <mpls@uu.net>; Thu, 13 Mar 2003 05:16:07 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2D5G2vD008445
	for <mpls@uu.net>; Thu, 13 Mar 2003 00:16:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id AAA05274 for <mpls@uu.net>; Thu, 13 Mar 2003 00:16:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2D5G2G09476 for mpls@uu.net; Thu, 13 Mar 2003 00:16:02 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofuj06682
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 05:15:04 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQofui16785
	for <mpls@UU.NET>; Thu, 13 Mar 2003 05:14:45 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofui20890
	for <mpls@UU.NET>; Thu, 13 Mar 2003 05:14:45 GMT
Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQofui20872
	for <mpls@UU.NET>; Thu, 13 Mar 2003 05:14:44 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id AAA87389;
	Thu, 13 Mar 2003 00:13:55 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303130513.AAA87389@workhorse.fictitious.org>
To: Kireeti Kompella <kireeti@juniper.net>
cc: Curtis Villamizar <curtis@fictitious.org>, mpls <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: Between OSPF RSVP... 
In-reply-to: Your message of "Wed, 12 Mar 2003 19:31:58 PST."
             <20030312192338.O98279@kummer.juniper.net> 
Date: Thu, 13 Mar 2003 00:13:55 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <20030312192338.O98279@kummer.juniper.net>, Kireeti Kompella writes:
> Hi Curtis et al,
> 
> On Wed, 12 Mar 2003, Curtis Villamizar wrote:
> 
> > > >OK.  I know for a fact that Avici does this.  Anyone else?
> > >
> > > CISCO.
> >
> > Thank you.  I think we'll get a third affirmative shortly.
> 
> Am I on cue? :-)
> 
> On the matter of OSPF vs. RSVP, in our experience, RSVP almost always
> wins.  With Notifies instead of PathErrs (no hop-by-hop processing),
> RSVP should always win (unless messages get lost).
> 
> Kireeti.


Kireeti,

Thanks for chiming in.

Regarding notifies.  They'd win unless you intentionally cheat and
give OSPF a head start because you want OSPF to win.  Even then
notfies could get there first.  I actually like path-err since they
clean up along the way and we find they don't beat OSPF often.

Absent any such cheating, internally prioritizing noticing TE-LSDB
changes and walking the linked list as soon as you hit a link down
shortcuts a lot of processing before restoration via standby.
Processing tha path-tear after restoration is then just state cleanup.

btw - Am I missing something or is there a direct notify to the
ingress that has been implimented in current MPLS code?  I know it has
been discussed in the GMPLS context.

When you say path-err almost always wins and notify should always win,
have you measured one OSPF LSA and say 1,000 path-err and 1,000
resv-err eminating from the same node and fanning out, and see if the
OSPF LSA gets there before some/most of the RSVP stuff.

A lot of things change when you go from a few LSPs in the lab to a few
hundred and even more so at a few thousand.  Needless to say we have
limited Juniper and Cisco gear in our lab and mostly for
interoperability testing and haven't noticed this with your stuff.

Curtis



From owner-mpls@UU.NET  Thu Mar 13 09:32:53 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01874
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 09:32:53 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofvu29807
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 14:35:00 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofvu29459;
	Thu, 13 Mar 2003 14:34:46 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofvs29974
	for mpls-outgoing; Thu, 13 Mar 2003 14:09:24 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQofvs29751
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 14:09:10 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofvs07101
	for <mpls@uu.net>; Thu, 13 Mar 2003 14:08:06 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofvs27395
	for <mpls@uu.net>; Thu, 13 Mar 2003 14:08:05 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQofvs27384
	for <mpls@uu.net>; Thu, 13 Mar 2003 14:08:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2DE82Sc019566
	for <mpls@uu.net>; Thu, 13 Mar 2003 09:08:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA00113 for <mpls@uu.net>; Thu, 13 Mar 2003 09:08:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2DE81704116 for mpls@uu.net; Thu, 13 Mar 2003 09:08:01 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofvs29618
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 14:06:45 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQofvs11597
	for <mpls@UU.NET>; Thu, 13 Mar 2003 14:06:02 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofvs24866
	for <mpls@UU.NET>; Thu, 13 Mar 2003 14:06:01 GMT
Received: from ams-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ams-msg-core-1.cisco.com [144.254.74.60])
	id QQofvs24816
	for <mpls@UU.NET>; Thu, 13 Mar 2003 14:06:00 GMT
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2DE48hM002706;
	Thu, 13 Mar 2003 15:04:09 +0100 (MET)
Received: from JVASSEUR-W2K.cisco.com (sjc-vpn2-477.cisco.com [10.21.113.221])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id PAA06325;
	Thu, 13 Mar 2003 15:05:46 +0100 (MET)
Message-Id: <4.3.2.7.2.20030313090357.067ab8b0@paris.cisco.com>
X-Sender: jvasseur@paris.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 13 Mar 2003 09:05:44 -0500
To: Kireeti Kompella <kireeti@juniper.net>
From: Jean Philippe Vasseur <jvasseur@cisco.com>
Subject: Re: Between OSPF RSVP... 
Cc: Curtis Villamizar <curtis@fictitious.org>, mpls <mpls@UU.NET>
In-Reply-To: <20030312192338.O98279@kummer.juniper.net>
References: <200303130204.VAA86328@workhorse.fictitious.org>
 <200303130204.VAA86328@workhorse.fictitious.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Kireeti,

At 19:31 12/03/2003 -0800, Kireeti Kompella wrote:
>Hi Curtis et al,
>
>On Wed, 12 Mar 2003, Curtis Villamizar wrote:
>
> > > >OK.  I know for a fact that Avici does this.  Anyone else?
> > >
> > > CISCO.
> >
> > Thank you.  I think we'll get a third affirmative shortly.
>
>Am I on cue? :-)
>
>On the matter of OSPF vs. RSVP, in our experience, RSVP almost always
>wins.  With Notifies instead of PathErrs (no hop-by-hop processing),
>RSVP should always win (unless messages get lost).

With appropriate RSVP message handling PERR is also pretty fast and allows 
states cleans up (see also Path Error State Removal).

Cheers.

JP.

>Kireeti.



From owner-mpls@UU.NET  Thu Mar 13 10:48:29 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06181
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 10:48:29 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofvz28340
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 15:50:40 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofvz28136;
	Thu, 13 Mar 2003 15:50:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofvx25564
	for mpls-outgoing; Thu, 13 Mar 2003 15:23:25 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofvx25552
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 15:23:13 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofvx09452
	for <mpls@UU.NET>; Thu, 13 Mar 2003 15:22:46 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofvx01003
	for <mpls@UU.NET>; Thu, 13 Mar 2003 15:22:46 GMT
Received: from thurn.corp.titan.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: thurn.corp.titan.com [159.62.51.20])
	id QQofvx00988
	for <mpls@UU.NET>; Thu, 13 Mar 2003 15:22:45 GMT
Received: from vcmd-nt1.validity.com (val114-005.validity.titan.com [159.62.114.5])
	by thurn.corp.titan.com (8.12.8/8.12.8) with ESMTP id h2DFMSEJ008494;
	Thu, 13 Mar 2003 07:22:29 -0800
Received: by VCMD-NT1 with Internet Mail Service (5.5.2655.55)
	id <1J0RK9XR>; Thu, 13 Mar 2003 10:21:46 -0500
Message-ID: <561621C69F17D511A3A20050047340EC01AAF5F9@VCMD-NT1>
From: "Ferrell, William" <William.Ferrell@titan.com>
To: "'George Swallow '" <swallow@cisco.com>, "'mpls@UU.NET '" <mpls@UU.NET>
Subject: RE: Draft MPLS Agenda
Date: Thu, 13 Mar 2003 10:21:45 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

 
 

Our scope of Securing MPLS is broad without going into SMPLS.
to me the most effective way of attacking the issue  is :
Id. MPLS overarching secuity issues from 
Access, inplementation,Operations to hardware/platforms.
keeping the LAbels, LDP , and LSP /LER attacks, through VPNs to the ISIS and
BGP routing Protocols in focus.
Each segment has its own security issues then to use them (BGP,ISIS,VPN)in
conjuction with MPLS may/maynot have a different impact. 
Again the scope is huge and there isnt a lot of research on the issue. 
Our goal is to write security requirments for each segment and the whole.

Will

-----Original Message-----
From: George Swallow
To: mpls@UU.NET
Sent: 3/11/03 5:14 PM
Subject: Draft MPLS Agenda


San Francisco                MPLS WG Agenda                    56th IETF

TUESDAY, March 18, 2002                                    Continental 6
0900-1130 


1.  Agenda bashing                                                 5 min
    
2.  Overview of ISOCORE Interoperability Tests

    Rajiv Papneja                                                 10 min

      
3.  TE related drafts

    Jean Philippe Vasseur                                         20 min
                                                    
        Reoptimization of an explicit loosely routed MPLS TE paths 
            <draft-vasseur-mpls-loose-path-reopt-01.txt> 
                                                    
        MPLS Traffic Engineering Fast reroute: bypass tunnel path 
          computation for bandwidth protection 
            <draft-vasseur-mpls-backup-computation-02.txt> 
         
        Definition of an RRO node-id subobject 
            <draft-vasseur-mpls-nodeid-subobject-00.txt> 


    Matthew Meyer                                                 10 min

        MPLS Traffic Engineering Soft preemption
            <draft-meyer-mpls-soft-preemption-00.txt>

 
4.  Graceful Restart

    Bob Thomas                                                    10 min

        LDP DoD Graceful Restart
            <draft-thomas-mpls-ldp-dod-restart-00.txt


5.  OAM

    Tom Nadeau                                                    10 min

        OAM Requirements for MPLS Networks
            <draft-nadeau-ietf-oam-requirements-01.txt

    Dave Allen                                                     5 min

        Y.1711 and LSP-PING
            <draft-allan-y1711-and-lsp-ping-00.txt>

    Kireeti Kompella                                              10 min

        Detecting MPLS Data Plane Liveness
            <draft-ietf-mpls-lsp-ping-02.txt>


6.  MIBs

    Tom Nadeau                                                    10 min

        Multiprotocol Label Switching (MPLS) Traffic Engineering 
          Management Information Base for Fast Reroute
            <draft-ietf-mpls-fastreroute-mib-01.txt

        Multiprotocol Label Switching (MPLS) Label-Controlled ATM
          and Frame-Relay Management Interface Definition
            <draft-nadeau-mpls-lc-if-mib-00.txt


7.  Explicitly routed Multicast

    Seisho Yasukawa                                               10 min

        Requirements for Point-to-Multipoint capability extension 
            <draft-yasukawa-mpls-p2mp-requirement-00.txt>

    Alan Kullberg                                                 10 min

        Extended RSVP-TE for Point-to-Multipoint LSP Tunnels
            <draft-yasukawa-mpls-rsvp-p2mp-01.txt>

    Rahul Aggarwal                                                10 min

        Multicast Traffic Engineering with MPLS
            <draft-raggarwa-mpls-mcast-te-00.txt>


8.  Header Compression

    Jerry Ash                                                     15 min

        Requirements for End-to-End VoIP Header Compression
            <draft-ash-e2e-voip-hdr-comp-rqmts-00.txt>
           
        End-to-End VoIP Header Compression Using cRTP
            <draft-ash-e2e-crtp-hdr-compress-01.txt>

        End-to-End VoIP over MPLS Header Compression
            <draft-ash-e2e-vompls-hdr-compress-01.txt>


9.  Draft Status Update

    George Swallow                                                 5 min


10. Charter Discussion                                            10 min












From owner-mpls@UU.NET  Thu Mar 13 10:50:58 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06263
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 10:50:58 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofvz00798
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 15:53:08 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofvz00155;
	Thu, 13 Mar 2003 15:52:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofvx25658
	for mpls-outgoing; Thu, 13 Mar 2003 15:25:46 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQofvx25651
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 15:25:43 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofvx10775
	for <mpls@UU.NET>; Thu, 13 Mar 2003 15:25:32 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofvx03326
	for <mpls@UU.NET>; Thu, 13 Mar 2003 15:25:31 GMT
Received: from thurn.corp.titan.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: thurn.corp.titan.com [159.62.51.20])
	id QQofvx03304
	for <mpls@UU.NET>; Thu, 13 Mar 2003 15:25:30 GMT
Received: from vcmd-nt1.validity.com (val114-005.validity.titan.com [159.62.114.5])
	by thurn.corp.titan.com (8.12.8/8.12.8) with ESMTP id h2DFOOEJ008626;
	Thu, 13 Mar 2003 07:24:25 -0800
Received: by VCMD-NT1 with Internet Mail Service (5.5.2655.55)
	id <1J0RK9X4>; Thu, 13 Mar 2003 10:23:43 -0500
Message-ID: <561621C69F17D511A3A20050047340EC01AAF5FA@VCMD-NT1>
From: "Ferrell, William" <William.Ferrell@titan.com>
To: "'Gert Grammel '" <Gert.Grammel@alcatel.de>,
        "Ferrell, William"
	 <William.Ferrell@titan.com>
Cc: "''curtis@fictitious.org ' '" <curtis@fictitious.org>,
        "''Mark.Jones@mail.sprint.com ' '" <Mark.Jones@mail.sprint.com>,
        "''ccamp@ops.ietf.org ' '" <ccamp@ops.ietf.org>,
        "''dwfedyk@nortelnetworks.com ' '" <dwfedyk@nortelnetworks.com>,
        "''gash@att.com ' '" <gash@att.com>, "''mpls@UU.NET ' '" <mpls@UU.NET>
Subject: RE: security issues on MPLS
Date: Thu, 13 Mar 2003 10:23:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

  
Gert
The problem is ... seems as though there are no experts on securing MPLS.
Its always overlooked from an operations perspective.

Our scope of Securing MPLS is broad without going into SMPLS.
to me the most effective way of attacking the issue  is :
Id. MPLS overarching secuity issues from 
Access, inplementation,Operations to hardware/platforms.
keeping the LAbels, LDP , and LSP /LER attacks, through VPNs to the ISIS and
BGP routing Protocols in focus.
Each segment has its own security issues then to use them (BGP,ISIS,VPN)in
conjuction with MPLS may/maynot have a different impact. 
Again the scope is huge and there isnt a lot of research on the issue. 
Our goal is to write security requirments for each segment and the whole.

Will


-----Original Message-----
From: Gert Grammel
To: Ferrell, William
Cc: 'curtis@fictitious.org '; 'Mark.Jones@mail.sprint.com ';
'ccamp@ops.ietf.org '; 'dwfedyk@nortelnetworks.com '; 'gash@att.com ';
'mpls@UU.NET '
Sent: 3/12/03 6:50 AM
Subject: security issues on MPLS

William,

I am not an expert in security issues but (G)MPLS security in particular
rsvp is
based on RFC 2747. In and e2e case IPSEC can be used as well see (see
RFC's 2402
and RFC 2406).

Regards

Gert

"Ferrell, William" wrote:

>  Gert / All
>
>  I am Will Ferrell of Titan working at DISA on an MPLS security
> project. I have worked with Barry Raveendran Greene (Cisco) on a major
DISA
> ACL project of which he provided invaluable guidance/support/ tech
reference
> that led to the projects success.
>
> Ive checked RFC's 2547,3036,2702 et. al.  It appears that there isnt a
lot
> of interest in securing MPLS. Can you refer me to other work for MPLS
> security requirements and all phases of MPLS security to include
secure
> implementation.
>
> > > >
> > > >William Ferrell
> > > >Information Assurance Eng. CCNP
> > > >Titan Corp.
> > > >703-882-2474
>
> -----Original Message-----
> From: Gert Grammel
> To: curtis@fictitious.org
> Cc: Mark.Jones@mail.sprint.com; ccamp@ops.ietf.org;
> dwfedyk@nortelnetworks.com; gash@att.com; mpls@UU.NET
> Sent: 3/10/03 7:24 AM
> Subject: Re: {Possible Spam} Re: I-D
> ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> Curtis,
>
> you've wrote:
>
>      It would be best if ITU members go off and waste their own time
>      pursuing ASON capabilities, just as the ATM Forum went off and
> wasted
>      their time on Q.2931 capability in UNI 3.x, 4.x, ...
>
> and I don't agree with that. In my view it would be best if ITU-T
> members were
> able to understand and accept the ideas behind GMPLS and would provide
> valuable
> input to bring this work forward.
>
> Regards
>
> Gert
>
> Curtis Villamizar wrote:
>
> > Coments inline.
> >
> > In message <3E679FB5.542FBF09@alcatel.de>, Gert Grammel writes:
> > >
> > > 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 (agai n informational) in IETF which do not comply
to
> > >      the purity of RSVP-TE. Due t o 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 solutio n on how to proceed. What I've seen so far was a
complete
> > > misperception of what i s 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 networkin g 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)
> >
> > SDH/SONET bandwidth on demand has never been deployed.  There is
> > serious question about whether this is a viable service.  The
> > technology has existed for about a decade (a little less maybe) for
> > provide ATM SVC service doing essentially the same thing.  Market
> > penetration after a decade is very close to zero for SVC.  Market
> > penetration for ATM SPVC/PVC is small and may be shrinking.  The FR
> > market seems to be shrinking as well.  FR SVC market is zero.
> > SDH/SONET does not have the bandwidth on demand capability but there
> > is ample evidence that implementing it would be a waste of time.
> >
> > ASON is a requirements document from ITU that assumes the SDH/SONET
> > BOND is a viable service.  This is an enormous leap of faith given
the
> > trends in the market.  The IETF doesn't buy into it.
> >
> > And yes, most of us are familiar with SS7 and the whole SCP/STP AIN
> > mess, so if you want to extend TCAP to support ASON, go right ahead.
> > We in the IETF would get a real good laugh over that.
> >
> > >   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.
> >
> > Initially IP and voice ran over TDM.  The bandwidth demands of IP
were
> > much less than voice a decade ago.  As IP penetration grew roughly
> > exponentially through the early, mid, and most of the late 1990s,
this
> > reversed and IP consumed far more bandwidth than voice.  Switched
> > services also grew but at a slower rate and in the late 1990s
> > experienced negative growth for many SPs.  One factor may have been
> > notable outages in FR (US nationwide one day at one major provider
and
> > intermittent for 10 days in another a few years later) shot a big
hole
> > in the "much more reliable than IP" story.
> >
> > Initially MPLS served as traffic enginnering strictly for IP.  With
IP
> > still growing substantially, voice growing very slowly (and losing
> > revenue) and switched services growing slowly to shrinking, there
was
> > motivation to carry voice, switched services, and leased line
services
> > over the IP and/or MPLS infrastructure and decommission older
> > SDH/SONET ADM and FR or ATM switches.  This led to the tunneling
work.
> >
> > Another factor which led to GMPLS was the (unrealized) promise/hype
of
> > optical switching in the very late 1990s.  IP over an ATM overlay
was
> > a poor design and IP providers did not want to repeat that mistake
so
> > the control of the underlying optical domain was accommodated by
what
> > has evolved into GMPLS.  GMPLS was extended to accommodate TDM in
> > addition to FSC, LSC and PSC.
> >
> > > 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.
> >
> > ASON was never accepted by the IETF as requirements and for very
good
> > reason.  To say that IETF must accept the ASON requirements simply
> > because they came in a liason statement and that the IETF must
> > accommodate this ITU folly is absurd.
> >
> > > 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 .
> >
> > Regardless of how this was handled in Yokohama, some of the
> > fundamental premise of ASON is flawed.  It would be best if ITU
> > members go off and waste their own time pursuing ASON capabilities,
> > just as the ATM Forum went off and wasted their time on Q.2931
> > capability in UNI 3.x, 4.x, but ITU should do so without extending
> > protocols which originated in the IETF.
> >
> > > 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
> >
> > I look forward to seeing the IETF come up with a formal statement of
> > liason policy.  It would be useful to have explicitly documented
that
> > liason statements carry no more weight than any individual
> > internet-draft submission.
> >
> > Curtis
>
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de



From owner-mpls@UU.NET  Thu Mar 13 11:09:45 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07117
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 11:09:44 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwa19455
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 16:11:55 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofwa19239;
	Thu, 13 Mar 2003 16:11:46 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofvz27271
	for mpls-outgoing; Thu, 13 Mar 2003 15:45:27 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofvz27262
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 15:45:16 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQofvy00186
	for <mpls@UU.NET>; Thu, 13 Mar 2003 15:43:39 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofvy21053
	for <mpls@UU.NET>; Thu, 13 Mar 2003 15:43:38 GMT
Received: from smtp3.libero.it by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp3.libero.it [193.70.192.127])
	id QQofvy21045
	for <mpls@UU.NET>; Thu, 13 Mar 2003 15:43:38 GMT
Received: from libero.it (193.70.192.42) by smtp3.libero.it (6.7.015)
        id 3E68E8E300073C2E for mpls@UU.NET; Thu, 13 Mar 2003 16:43:37 +0100
Date: Thu, 13 Mar 2003 16:43:37 +0100
Message-Id: <HBP2CP$6F20D5377D18994A28CE4DF5D4F8E331@libero.it>
Subject: =?iso-8859-1?Q?Observations_OSPF_RSVP..._?=
MIME-Version: 1.0
X-Sensitivity: 3
Content-Type: text/plain; charset=iso-8859-1
From: "=?iso-8859-1?Q?john151@libero.it?=" <john151@libero.it>
To: "=?iso-8859-1?Q?mpls?=" <mpls@UU.NET>
X-XaM3-API-Version: 3.2 R29 (B54 pl1)
X-type: 0
X-SenderIP: 81.73.170.22
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA07117

Hi all,

i see at least two advantages in using Opaque LSA insted of PathErr (quite the same for the Notifies ) in this scenario: precalculated and presignalled backup disjoint paths for protected LSPs in MPLS Network, availability of fast detection mechanism ( from lower levels ) of link failure.

1) Since Opaque LSAs don' t trigger an SPF calculation in the routers they cross, all the Network is soon informed about the link failure event and IN PARALLEL each router can do the label switching on the backup LSPs ( after having controlled the presence of protected LSPs starting from it and interested by the link failure ). 

2) Since i refer to protected LPSs ( they are relatively few ), thinking in a scenario in which there should be a return to the first active LSP when the link failed returns to be UP ( that is a second switch from backup LSP to the  first active LSP ), could it be not necessary to send the PathTears immediately to cleanup resources? This will bring two beneficts: no PathTears and ResvTear sent immediately in  the Network and no signalling messages storm when the link returns up ( after a not long period ), when it's probable that all the backup LSPs will return on that link (the link that went down). 

Thanks in advance for your kind answers and observations.

Giovanni di Giacomo



From owner-mpls@UU.NET  Thu Mar 13 11:29:14 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07793
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 11:29:13 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwc05868
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 16:31:22 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofwc05515;
	Thu, 13 Mar 2003 16:31:03 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofwa12183
	for mpls-outgoing; Thu, 13 Mar 2003 16:03:03 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofwa11929
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 16:03:00 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofwa12920
	for <mpls@UU.NET>; Thu, 13 Mar 2003 16:02:34 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwa07226
	for <mpls@UU.NET>; Thu, 13 Mar 2003 16:02:34 GMT
Received: from thurn.corp.titan.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: thurn.corp.titan.com [159.62.51.20])
	id QQofwa07212
	for <mpls@UU.NET>; Thu, 13 Mar 2003 16:02:33 GMT
Received: from vcmd-nt1.validity.com (val114-005.validity.titan.com [159.62.114.5])
	by thurn.corp.titan.com (8.12.8/8.12.8) with ESMTP id h2DG2PEJ011434;
	Thu, 13 Mar 2003 08:02:26 -0800
Received: by VCMD-NT1 with Internet Mail Service (5.5.2655.55)
	id <1J0RK95L>; Thu, 13 Mar 2003 11:01:44 -0500
Message-ID: <561621C69F17D511A3A20050047340EC01AAF5FD@VCMD-NT1>
From: "Ferrell, William" <William.Ferrell@titan.com>
To: "'john151@libero.it '" <john151@libero.it>, "'mpls '" <mpls@UU.NET>
Subject: RE: Observations OSPF RSVP... 
Date: Thu, 13 Mar 2003 11:01:40 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

 
 John/ Giovanni

The theory sounds interesting , the first thing that struck me is the term
"protected LSPs". In your second item you state that there arent that many ,
I want to know what protection mechanism is in place to establish them ?
Will

-----Original Message-----
From: john151@libero.it
To: mpls
Sent: 3/13/03 10:43 AM
Subject: Observations OSPF RSVP... 

Hi all,

i see at least two advantages in using Opaque LSA insted of PathErr
(quite the same for the Notifies ) in this scenario: precalculated and
presignalled backup disjoint paths for protected LSPs in MPLS Network,
availability of fast detection mechanism ( from lower levels ) of link
failure.

1) Since Opaque LSAs don' t trigger an SPF calculation in the routers
they cross, all the Network is soon informed about the link failure
event and IN PARALLEL each router can do the label switching on the
backup LSPs ( after having controlled the presence of protected LSPs
starting from it and interested by the link failure ). 

2) Since i refer to protected LPSs ( they are relatively few ), thinking
in a scenario in which there should be a return to the first active LSP
when the link failed returns to be UP ( that is a second switch from
backup LSP to the  first active LSP ), could it be not necessary to send
the PathTears immediately to cleanup resources? This will bring two
beneficts: no PathTears and ResvTear sent immediately in  the Network
and no signalling messages storm when the link returns up ( after a not
long period ), when it's probable that all the backup LSPs will return
on that link (the link that went down). 

Thanks in advance for your kind answers and observations.

Giovanni di Giacomo


From owner-mpls@UU.NET  Thu Mar 13 11:45:17 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08312
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 11:45:17 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwd26215
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 16:47:26 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofwd26122;
	Thu, 13 Mar 2003 16:47:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofwb18680
	for mpls-outgoing; Thu, 13 Mar 2003 16:19:47 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofwb18668
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 16:19:30 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofwb13557
	for <mpls@UU.NET>; Thu, 13 Mar 2003 16:19:17 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwb10984
	for <mpls@UU.NET>; Thu, 13 Mar 2003 16:19:17 GMT
Received: from rchss002.chiaro.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: rchss002.chiaro.com [63.88.196.82])
	id QQofwb10971
	for <mpls@UU.NET>; Thu, 13 Mar 2003 16:19:16 GMT
Received: (qmail 385 invoked from network); 13 Mar 2003 16:11:42 -0000
Received: from rchss002.chiaro.com (HELO mail.chiaro.com) (63.88.196.82)
  by rchss002.chiaro.com with SMTP; 13 Mar 2003 16:11:42 -0000
Received: by MAIL with Internet Mail Service (5.5.2653.19)
	id <GT079M4Q>; Thu, 13 Mar 2003 10:18:29 -0600
Message-ID: <F69EB380D594D611BBEA00065B3F14B4A3524C@MAIL>
From: Steve Yao <syao@chiaro.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>
Cc: mpls <mpls@UU.NET>
Subject: RE: Between OSPF RSVP... 
Date: Thu, 13 Mar 2003 10:18:21 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/mixed; boundary="=_IS_MIME_Boundary"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=_IS_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Curtis,

You mentioned a few times the linked list of LSPs hanging off the TE-LSDB.
However, the ingress does not necessarily know about all the links that an
LSP goes over even with RRO turned on.

Steve


>-----Original Message-----
>From: Curtis Villamizar [mailto:curtis@fictitious.org]
>Sent: Wednesday, March 12, 2003 11:14 PM
>To: Kireeti Kompella
>Cc: Curtis Villamizar; mpls
>Subject: Re: Between OSPF RSVP... 
>
>
>
>In message <20030312192338.O98279@kummer.juniper.net>, Kireeti 
>Kompella writes:
>> Hi Curtis et al,
>> 
>> On Wed, 12 Mar 2003, Curtis Villamizar wrote:
>> 
>> > > >OK.  I know for a fact that Avici does this.  Anyone else?
>> > >
>> > > CISCO.
>> >
>> > Thank you.  I think we'll get a third affirmative shortly.
>> 
>> Am I on cue? :-)
>> 
>> On the matter of OSPF vs. RSVP, in our experience, RSVP almost always
>> wins.  With Notifies instead of PathErrs (no hop-by-hop processing),
>> RSVP should always win (unless messages get lost).
>> 
>> Kireeti.
>
>
>Kireeti,
>
>Thanks for chiming in.
>
>Regarding notifies.  They'd win unless you intentionally cheat and
>give OSPF a head start because you want OSPF to win.  Even then
>notfies could get there first.  I actually like path-err since they
>clean up along the way and we find they don't beat OSPF often.
>
>Absent any such cheating, internally prioritizing noticing TE-LSDB
>changes and walking the linked list as soon as you hit a link down
>shortcuts a lot of processing before restoration via standby.
>Processing tha path-tear after restoration is then just state cleanup.
>
>btw - Am I missing something or is there a direct notify to the
>ingress that has been implimented in current MPLS code?  I know it has
>been discussed in the GMPLS context.
>
>When you say path-err almost always wins and notify should always win,
>have you measured one OSPF LSA and say 1,000 path-err and 1,000
>resv-err eminating from the same node and fanning out, and see if the
>OSPF LSA gets there before some/most of the RSVP stuff.
>
>A lot of things change when you go from a few LSPs in the lab to a few
>hundred and even more so at a few thousand.  Needless to say we have
>limited Juniper and Cisco gear in our lab and mostly for
>interoperability testing and haven't noticed this with your stuff.
>
>Curtis
>
--=_IS_MIME_Boundary
Content-Type: text/plain;charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

----------------------------------------- (on Chiaro SMTP Relay)

This e-mail and any files transmitted with it are the property
of Chiaro Networks, Ltd., and may contain confidential and 
privileged material for the sole use of the intended recipient(s)
to whom this e-mail is addressed. If you are not one of the named
recipient(s), or otherwise have reason to believe that you have 
received this message in error, please notify the sender and 
delete all copies from your system.  Any other use, retention, 
dissemination, forwarding, printing or copying of this e-mail is 
strictly prohibited.


---------------------------------------------------------

--=_IS_MIME_Boundary--


From owner-mpls@UU.NET  Thu Mar 13 11:50:29 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08545
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 11:50:29 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwd26442
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 16:52:38 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofwd26186;
	Thu, 13 Mar 2003 16:52:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofwb19103
	for mpls-outgoing; Thu, 13 Mar 2003 16:24:30 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofwb19096
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 16:24:29 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofwb26366
	for <mpls@UU.NET>; Thu, 13 Mar 2003 16:23:40 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwb17270
	for <mpls@UU.NET>; Thu, 13 Mar 2003 16:23:40 GMT
Received: from thurn.corp.titan.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: thurn.corp.titan.com [159.62.51.20])
	id QQofwb17258
	for <mpls@UU.NET>; Thu, 13 Mar 2003 16:23:39 GMT
Received: from vcmd-nt1.validity.com (val114-005.validity.titan.com [159.62.114.5])
	by thurn.corp.titan.com (8.12.8/8.12.8) with ESMTP id h2DGMuEJ012743;
	Thu, 13 Mar 2003 08:22:57 -0800
Received: by VCMD-NT1 with Internet Mail Service (5.5.2655.55)
	id <1J0RK965>; Thu, 13 Mar 2003 11:22:15 -0500
Message-ID: <561621C69F17D511A3A20050047340EC01AAF5FF@VCMD-NT1>
From: "Ferrell, William" <William.Ferrell@titan.com>
To: "'Jones, Mark L [GMG] '" <Mark.Jones@mail.sprint.com>,
        "''Curtis Villamizar' '" <curtis@fictitious.org>,
        "'Gert Grammel '"
	 <Gert.Grammel@alcatel.de>
Cc: "'ccamp@ops.ietf.org '" <ccamp@ops.ietf.org>,
        "'dwfedyk@nortelnetworks.com '" <dwfedyk@nortelnetworks.com>,
        "'gash@att.com '" <gash@att.com>, "'mpls@UU.NET '" <mpls@UU.NET>
Subject: RE: {Possible Spam} Re: I-D ACTION:draft-andersson-mpls-g-chng-pr
	 oc-00.txt 
Date: Thu, 13 Mar 2003 11:22:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

 
"Since MPLS implements the same routing protocols such as OSPF and BGP in
LSRs in performing routing functions, it would have  the same
vulnerabilities, such as routing tables being poisoned and IP header fields
being changed, as in the IP networks using regular routers in routing IP
traffic"

Same old arguement here : 
MPLS uses LDP is that to say that it is "like " OSPF ? NO. MPLS uses the
Routing protocol to get routing information. But ultimately , yes I agree
that by useing ISIS , OSPF and BGP the routing tables are suspect to attack
and same old vulnerbilities are now transposed onto the MPLS net, but
conversely so is the signalling and hellos in LDP.  

Will 


From owner-mpls@UU.NET  Thu Mar 13 12:11:28 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09062
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 12:11:27 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwe02806
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 17:13:36 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofwe02347;
	Thu, 13 Mar 2003 17:13:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofwd21323
	for mpls-outgoing; Thu, 13 Mar 2003 16:47:17 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofwd21271
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 16:46:55 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofwd25167
	for <mpls@UU.NET>; Thu, 13 Mar 2003 16:46:37 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwd20890
	for <mpls@UU.NET>; Thu, 13 Mar 2003 16:46:37 GMT
Received: from smtp0.libero.it by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp0.libero.it [193.70.192.33])
	id QQofwd20881
	for <mpls@UU.NET>; Thu, 13 Mar 2003 16:46:36 GMT
Received: from libero.it (193.70.192.42) by smtp0.libero.it (6.7.015)
        id 3E68E20400076F6C for mpls@UU.NET; Thu, 13 Mar 2003 17:46:36 +0100
Date: Thu, 13 Mar 2003 17:46:35 +0100
Message-Id: <HBP59N$8914D640D74825FBA4579393C411BAFA@libero.it>
Subject: =?iso-8859-1?Q?RE:_Observations_OSPF_RSVP...?=
MIME-Version: 1.0
X-Sensitivity: 3
Content-Type: text/plain; charset=iso-8859-1
From: "=?iso-8859-1?Q?john151@libero.it?=" <john151@libero.it>
To: "=?iso-8859-1?Q?mpls?=" <mpls@UU.NET>
X-XaM3-API-Version: 3.2 R29 (B54 pl1)
X-type: 0
X-SenderIP: 81.73.170.22
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA09062

Hi William hi all,
I intended for protected LSP an LSP with one (or more ) backup associated Path.
Then i see no changing in the way of establishing them in relation to what we already have (RSVP...)

Thanks in advance for your kind answers and observations.

Giovanni di Giacomo





 John/ Giovanni

The theory sounds interesting , the first thing that struck me is the term
"protected LSPs". In your second item you state that there arent that many ,
I want to know what protection mechanism is in place to establish them ?
Will

-----Original Message-----
From: john151@libero.it
To: mpls
Sent: 3/13/03 10:43 AM
Subject: Observations OSPF RSVP... 

Hi all,

i see at least two advantages in using Opaque LSA insted of PathErr
(quite the same for the Notifies ) in this scenario: precalculated and
presignalled backup disjoint paths for protected LSPs in MPLS Network,
availability of fast detection mechanism ( from lower levels ) of link
failure.

1) Since Opaque LSAs don' t trigger an SPF calculation in the routers
they cross, all the Network is soon informed about the link failure
event and IN PARALLEL each router can do the label switching on the
backup LSPs ( after having controlled the presence of protected LSPs
starting from it and interested by the link failure ). 

2) Since i refer to protected LPSs ( they are relatively few ), thinking
in a scenario in which there should be a return to the first active LSP
when the link failed returns to be UP ( that is a second switch from
backup LSP to the  first active LSP ), could it be not necessary to send
the PathTears immediately to cleanup resources? This will bring two
beneficts: no PathTears and ResvTear sent immediately in  the Network
and no signalling messages storm when the link returns up ( after a not
long period ), when it's probable that all the backup LSPs will return
on that link (the link that went down). 

Thanks in advance for your kind answers and observations.

Giovanni di Giacomo




From owner-mpls@UU.NET  Thu Mar 13 13:10:37 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11110
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 13:10:37 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwi03063
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 18:12:46 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofwi02458;
	Thu, 13 Mar 2003 18:12:30 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofwg14202
	for mpls-outgoing; Thu, 13 Mar 2003 17:44:06 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofwg14197
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 17:44:03 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofwg00287
	for <mpls@UU.NET>; Thu, 13 Mar 2003 17:43:59 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwg11423
	for <mpls@UU.NET>; Thu, 13 Mar 2003 17:43:59 GMT
Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQofwg11417
	for <mpls@UU.NET>; Thu, 13 Mar 2003 17:43:58 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2DHhvS44672;
	Thu, 13 Mar 2003 09:43:57 -0800 (PST)
	(envelope-from kireeti@juniper.net)
Received: from localhost (kireeti@localhost)
	by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h2DHhvE00985;
	Thu, 13 Mar 2003 09:43:57 -0800 (PST)
	(envelope-from kireeti@juniper.net)
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
Date: Thu, 13 Mar 2003 09:43:57 -0800 (PST)
From: Kireeti Kompella <kireeti@juniper.net>
To: Curtis Villamizar <curtis@fictitious.org>
cc: mpls <mpls@UU.NET>
Subject: Re: Between OSPF RSVP... 
In-Reply-To: <20030312192338.O98279@kummer.juniper.net>
Message-ID: <20030313094100.L966@kummer.juniper.net>
References: <200303130204.VAA86328@workhorse.fictitious.org>
 <20030312192338.O98279@kummer.juniper.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

> > Thank you.  I think we'll get a third affirmative shortly.
>
> Am I on cue? :-)

There are some who want me to spell it out, so here goes: if an
LSP goes over some link that subsequently fails, and the head end
learns this via OSPF/ISIS, the head end will switch to a backup,
or reroute the LSP.  The mechanism is pretty much what Curtis has
been describing.

No smoke, no mirrors :-)

Kireeti.


From owner-mpls@UU.NET  Thu Mar 13 13:15:11 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11287
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 13:15:10 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwj16390
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 18:17:20 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofwj16184;
	Thu, 13 Mar 2003 18:17:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofwh14841
	for mpls-outgoing; Thu, 13 Mar 2003 17:48:26 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofwh14836
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 17:48:23 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQofwh27490
	for <mpls@UU.NET>; Thu, 13 Mar 2003 17:47:52 GMT
From: neil.2.harrison@bt.com
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwh17505
	for <mpls@UU.NET>; Thu, 13 Mar 2003 17:47:52 GMT
Received: from cbibipnt03.HC.BT.COM by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: saturn.bt.com [193.113.57.20])
	id QQofwh17481
	for <mpls@UU.NET>; Thu, 13 Mar 2003 17:47:51 GMT
Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2654.89)
	id <G65F4S82>; Thu, 13 Mar 2003 17:48:04 -0000
Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D65E1@i2km07-ukbr.domain1.systemhost.net>
To: William.Ferrell@titan.com, Mark.Jones@mail.sprint.com
Cc: ccamp@ops.ietf.org, dwfedyk@nortelnetworks.com, gash@att.com, mpls@UU.NET
Subject: RE: {Possible Spam} Re: I-D ACTION:draft-andersson-mpls-g-chng-pr
	 oc-00.txt 
Date: Thu, 13 Mar 2003 17:47:36 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

William Ferrell wrote 13 March 2003 16:22
> "Since MPLS implements the same routing protocols such as 
> OSPF and BGP in
> LSRs in performing routing functions, it would have  the same
> vulnerabilities, such as routing tables being poisoned and IP 
> header fields
> being changed, as in the IP networks using regular routers in 
> routing IP
> traffic"
> 
> Same old arguement here : 
> MPLS uses LDP is that to say that it is "like " OSPF ? NO. 
> MPLS uses the
> Routing protocol to get routing information. But ultimately , 
> yes I agree
> that by useing ISIS , OSPF and BGP the routing tables are 
> suspect to attack
> and same old vulnerbilities are now transposed onto the MPLS net, but
> conversely so is the signalling and hellos in LDP.  
> 
Will,  Not really sure where you are going here but one thing you need to
think about is making sure the network itself has some form of self-checking
so that security problems don't arise as a results of network failures.  We
regard this as very important (especially for arbitrary X/MPLS client/server
relationships, eg ATMoverMPLS) so let me try and explain:

In a cnls network each/every pkt contains full SA/DA.  So you can pick a pkt
up from anywhere and drop it somewhere else and (subject to TTL exhaust) it
will find its way to the right destination.  Not true however in MPLS (any
type).

The links between MPLS nodes use link-connection identifiers, which are only
required to be unique for the link between a pair of adjacent nodes.  These
link-connection identifiers only possess networking currency when they are
allocated to a parent LSP entity at it's creation time.  Similarly, the
link-connection identifiers lose their networking currency when their parent
LSP entity is destroyed.

A specific link-connection identifier can be used: (i) on different links in
the same LSP, or (ii) on any links in other LSPs.  This means one cannot
take a packet out of a given LSP at any point and drop it into the network
at some other point and expect it to find it's way to the correct
destination.  There are 2 possible outcomes from doing this:

1	The packet will black-hole at the next receiving node if the
link-connection identifier has no currency at that node, ie it is not
allocated to some parent LSP;  or,

2	The packet will be forwarded at the next receiving node if the
link-connection identifier has currency at that node (and thereafter
forwarded on all subsequent links to the connection sink point), ie it is
allocated to some parent LSP.  Note also that this case can be *recursive*
if there are nested client/server LSP relationships....so the black-holing
or further forwarding behaviour can continue upwards in the affected client
LSPs.

Any failures that result in MPLS packets being misdirected raise traffic
integrity/security concerns.  So not only must such defects be automatically
detectable, but they must also automatically elicit the right type of
consequent actions, eg in this case squelch the traffic, as well as
informing the higher client (eg ATM) of the failure.....note that the client
network may be an external customer of the MPLS layer network
service-provider and so in a completely different management domain.

So this is why in SDH, for example, you find a trail-trace function in the
user-plane, ie a periodic identifier sent by the source to the sink so that
the sink can verify it has correct connectivity.  The same should also apply
to MPLS (or at least those versions of MPLS that are p2p.....mp2p LSPs raise
a whole raft of other issues).  The requirements for this are given in
Y.1710 and the solutions are given in Y.1711, ie we require that a
Connectivity Verification OAM packet be periodically sent in the user-plane
from the source to the sink that identifies where the pkt came from. In
doing so we can detect all failure modes, eg simple breaks, swapped LSPs,
and mismerged LSPs, and take the right consequent actions quickly.

This does not address all the security concerns of course, and its not
intended to protect against malicious attacks....it merely helps protect the
network from creating security breaches due to its own failures.

regards, Neil

 


From owner-mpls@UU.NET  Thu Mar 13 13:33:35 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11991
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 13:33:35 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwk02060
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 18:35:43 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofwk01736;
	Thu, 13 Mar 2003 18:35:30 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofwi03182
	for mpls-outgoing; Thu, 13 Mar 2003 18:04:07 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofwi03002
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 18:03:49 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofwi11267
	for <mpls@uu.net>; Thu, 13 Mar 2003 18:03:08 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwi28018
	for <mpls@uu.net>; Thu, 13 Mar 2003 18:03:08 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQofwi28010
	for <mpls@uu.net>; Thu, 13 Mar 2003 18:03:07 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2DI34vD025545
	for <mpls@uu.net>; Thu, 13 Mar 2003 13:03:05 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA20347 for <mpls@uu.net>; Thu, 13 Mar 2003 13:03:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2DI33324153 for mpls@uu.net; Thu, 13 Mar 2003 13:03:03 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofwi25978
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 18:01:55 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofwi29128
	for <mpls@UU.NET>; Thu, 13 Mar 2003 18:01:40 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwi26482
	for <mpls@UU.NET>; Thu, 13 Mar 2003 18:01:39 GMT
Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQofwi26453
	for <mpls@UU.NET>; Thu, 13 Mar 2003 18:01:38 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id NAA90189;
	Thu, 13 Mar 2003 13:00:43 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303131800.NAA90189@workhorse.fictitious.org>
To: Steve Yao <syao@chiaro.com>
cc: "'curtis@fictitious.org'" <curtis@fictitious.org>, mpls <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: Between OSPF RSVP... 
In-reply-to: Your message of "Thu, 13 Mar 2003 10:18:21 CST."
             <F69EB380D594D611BBEA00065B3F14B4A3524C@MAIL> 
Date: Thu, 13 Mar 2003 13:00:43 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <F69EB380D594D611BBEA00065B3F14B4A3524C@MAIL>, Steve Yao writes:
> 
> Hi Curtis,
> 
> You mentioned a few times the linked list of LSPs hanging off the TE-LSDB.
> However, the ingress does not necessarily know about all the links that an
> LSP goes over even with RRO turned on.
> 
> Steve


Then the path-tear and/or the directed notify would still notify the
ingress.

What circumstances are you thinking of.

Curtis



From owner-mpls@UU.NET  Thu Mar 13 13:52:46 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12586
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 13:52:46 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwl14275
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 18:54:55 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofwl13758;
	Thu, 13 Mar 2003 18:54:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofwj06461
	for mpls-outgoing; Thu, 13 Mar 2003 18:24:23 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQofwj06452
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 18:24:15 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofwj28096
	for <mpls@UU.NET>; Thu, 13 Mar 2003 18:24:08 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwj21565
	for <mpls@UU.NET>; Thu, 13 Mar 2003 18:24:06 GMT
Received: from rchss002.chiaro.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: rchss002.chiaro.com [63.88.196.82])
	id QQofwj21544
	for <mpls@UU.NET>; Thu, 13 Mar 2003 18:24:05 GMT
Received: (qmail 5204 invoked from network); 13 Mar 2003 18:15:56 -0000
Received: from rchss002.chiaro.com (HELO mail.chiaro.com) (63.88.196.82)
  by rchss002.chiaro.com with SMTP; 13 Mar 2003 18:15:56 -0000
Received: by MAIL with Internet Mail Service (5.5.2653.19)
	id <GT079M0P>; Thu, 13 Mar 2003 12:17:41 -0600
Message-ID: <F69EB380D594D611BBEA00065B3F14B4A3524F@MAIL>
From: Steve Yao <syao@chiaro.com>
To: "'Kireeti Kompella'" <kireeti@juniper.net>,
        Curtis Villamizar
	 <curtis@fictitious.org>
Cc: mpls <mpls@UU.NET>
Subject: RE: Between OSPF RSVP... 
Date: Thu, 13 Mar 2003 12:17:40 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/mixed; boundary="=_IS_MIME_Boundary"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=_IS_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"



>> > Thank you.  I think we'll get a third affirmative shortly.
>>
>> Am I on cue? :-)
>
>There are some who want me to spell it out, so here goes: if an
>LSP goes over some link that subsequently fails, and the head end
>learns this via OSPF/ISIS, the head end will switch to a backup,
>or reroute the LSP.  The mechanism is pretty much what Curtis has
>been describing.
>
>No smoke, no mirrors :-)
>
>Kireeti.
>

Chiaro does this too.

Steve
--=_IS_MIME_Boundary
Content-Type: text/plain;charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

----------------------------------------- (on Chiaro SMTP Relay)

This e-mail and any files transmitted with it are the property
of Chiaro Networks, Ltd., and may contain confidential and 
privileged material for the sole use of the intended recipient(s)
to whom this e-mail is addressed. If you are not one of the named
recipient(s), or otherwise have reason to believe that you have 
received this message in error, please notify the sender and 
delete all copies from your system.  Any other use, retention, 
dissemination, forwarding, printing or copying of this e-mail is 
strictly prohibited.


---------------------------------------------------------

--=_IS_MIME_Boundary--


From owner-mpls@UU.NET  Thu Mar 13 13:52:52 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12603
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 13:52:52 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwl14458
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 18:55:01 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofwl13807;
	Thu, 13 Mar 2003 18:54:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofwj06471
	for mpls-outgoing; Thu, 13 Mar 2003 18:24:28 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofwj06463
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 18:24:27 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofwj02905
	for <mpls@uu.net>; Thu, 13 Mar 2003 18:23:07 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwj18379
	for <mpls@uu.net>; Thu, 13 Mar 2003 18:23:07 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQofwj18371
	for <mpls@uu.net>; Thu, 13 Mar 2003 18:23:06 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2DIN4vD027307
	for <mpls@uu.net>; Thu, 13 Mar 2003 13:23:04 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA22127 for <mpls@uu.net>; Thu, 13 Mar 2003 13:23:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2DIN3B27234 for mpls@uu.net; Thu, 13 Mar 2003 13:23:03 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQofwj06362
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 18:21:20 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofwj16525
	for <mpls@UU.NET>; Thu, 13 Mar 2003 18:21:11 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwj18291
	for <mpls@UU.NET>; Thu, 13 Mar 2003 18:21:10 GMT
Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQofwj18265
	for <mpls@UU.NET>; Thu, 13 Mar 2003 18:21:09 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id NAA90253;
	Thu, 13 Mar 2003 13:20:13 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303131820.NAA90253@workhorse.fictitious.org>
To: "john151@libero.it" <john151@libero.it>
cc: "mpls" <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: Observations OSPF RSVP... 
In-reply-to: Your message of "Thu, 13 Mar 2003 16:43:37 +0100."
             <HBP2CP$6F20D5377D18994A28CE4DF5D4F8E331@libero.it> 
Date: Thu, 13 Mar 2003 13:20:13 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <HBP2CP$6F20D5377D18994A28CE4DF5D4F8E331@libero.it>, "john151@libero
.it" writes:
> Hi all,
> 
> i see at least two advantages in using Opaque LSA insted of PathErr (quite th
> e same for the Notifies ) in this scenario: precalculated and presignalled ba
> ckup disjoint paths for protected LSPs in MPLS Network, availability of fast 
> detection mechanism ( from lower levels ) of link failure.
> 
> 1) Since Opaque LSAs don' t trigger an SPF calculation in the routers they cr
> oss, all the Network is soon informed about the link failure event and IN PAR
> ALLEL each router can do the label switching on the backup LSPs ( after havin
> g controlled the presence of protected LSPs starting from it and interested b
> y the link failure ). 
> 
> 2) Since i refer to protected LPSs ( they are relatively few ), thinking in a
>  scenario in which there should be a return to the first active LSP when the 
> link failed returns to be UP ( that is a second switch from backup LSP to the
>   first active LSP ), could it be not necessary to send the PathTears immedia
> tely to cleanup resources? This will bring two beneficts: no PathTears and Re
> svTear sent immediately in  the Network and no signalling messages storm when
>  the link returns up ( after a not long period ), when it's probable that all
>  the backup LSPs will return on that link (the link that went down). 
> 
> Thanks in advance for your kind answers and observations.
> 
> Giovanni di Giacomo


The way this works in practice depends on whether the tunnel is
configured to take a specific primary path or is dymanicly routed but
in either case a *new* primary LSP is created with a new LSP-id but
sharing bandwidth as in make-before-break.

If path is configured, the LSR has two choices, 1) retry signaling on
a new primary LSP as long as the immediate next hop in the path is UP
(ie: don't trust the IGP, some argue don't run one), 2) wait until the
IGP indicates the path is feasible then signal a new primary LSP.  The
former is problematic particularly with no IGP at all (retry often and
incur high overhead, or long retry intervals and slow reaction
although this could be considered a feature - see below).

If the primary path is dynamic, then the standby will carry traffic
only as long as it take to bring up a new primary and a new standby.
At some point all three LSPs are up and sharing bandwidth.  Traffic is
switched to the new primary.  The new primary is again fully
protected, or if there is now only one link somewhere, maximally
protected.  If the link comes back up, the adaptivity implementation
(longer term timers) reoptimizes the bandwidth, gradually moving
traffic back to the previously failed link.

A good feature of dynamic path selection with adaptivity is that links
which fail once often come up and fail again very shortly after, often
more than once.  If traffic is slow to move back to it the impact of
subsequent failures is less.  If a link is intermittent with a short
cycle, it will remain unused, even during the time that it is up.

To directly answer your concern, the *new* primary LSP is distinct
from the old one.  The LSP-id is changed.  They share bandwidth.
Tearing down the old primary LSP has no impact on signaling a new one.

Curtis



From owner-mpls@UU.NET  Thu Mar 13 14:15:48 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13531
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 14:15:48 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwn00974
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 19:17:58 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofwn00518;
	Thu, 13 Mar 2003 19:17:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofwl09699
	for mpls-outgoing; Thu, 13 Mar 2003 18:52:30 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQofwl09646
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 18:52:20 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofwl29843
	for <mpls@UU.NET>; Thu, 13 Mar 2003 18:51:22 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwl18089
	for <mpls@UU.NET>; Thu, 13 Mar 2003 18:51:22 GMT
Received: from rchss002.chiaro.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: rchss002.chiaro.com [63.88.196.82])
	id QQofwl18079
	for <mpls@UU.NET>; Thu, 13 Mar 2003 18:51:21 GMT
Received: (qmail 6357 invoked from network); 13 Mar 2003 18:43:37 -0000
Received: from rchss002.chiaro.com (HELO mail.chiaro.com) (63.88.196.82)
  by rchss002.chiaro.com with SMTP; 13 Mar 2003 18:43:37 -0000
Received: by MAIL with Internet Mail Service (5.5.2653.19)
	id <GT079NBY>; Thu, 13 Mar 2003 12:45:05 -0600
Message-ID: <F69EB380D594D611BBEA00065B3F14B4A35250@MAIL>
From: Steve Yao <syao@chiaro.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>
Cc: mpls <mpls@UU.NET>
Subject: RE: Between OSPF RSVP... 
Date: Thu, 13 Mar 2003 12:45:04 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/mixed; boundary="=_IS_MIME_Boundary"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=_IS_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"



>
>
>Then the path-tear and/or the directed notify would still notify the
>ingress.
>
>What circumstances are you thinking of.
>
>Curtis
>

I guess it is suffice to say that the linked list mechanism does not cover
all the cases.

Steve
--=_IS_MIME_Boundary
Content-Type: text/plain;charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

----------------------------------------- (on Chiaro SMTP Relay)

This e-mail and any files transmitted with it are the property
of Chiaro Networks, Ltd., and may contain confidential and 
privileged material for the sole use of the intended recipient(s)
to whom this e-mail is addressed. If you are not one of the named
recipient(s), or otherwise have reason to believe that you have 
received this message in error, please notify the sender and 
delete all copies from your system.  Any other use, retention, 
dissemination, forwarding, printing or copying of this e-mail is 
strictly prohibited.


---------------------------------------------------------

--=_IS_MIME_Boundary--


From owner-mpls@UU.NET  Thu Mar 13 14:42:12 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14768
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 14:42:12 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwo02300
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 19:44:21 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofwo02016;
	Thu, 13 Mar 2003 19:44:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofwn00394
	for mpls-outgoing; Thu, 13 Mar 2003 19:17:31 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofwn00379
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 19:17:14 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofwn02783
	for <mpls@UU.NET>; Thu, 13 Mar 2003 19:15:53 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwn22539
	for <mpls@UU.NET>; Thu, 13 Mar 2003 19:15:53 GMT
Received: from ns2.vivacenetworks.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [64.221.212.135])
	id QQofwn22467
	for <mpls@UU.NET>; Thu, 13 Mar 2003 19:15:51 GMT
Received: from amalisxp.vivacenetworks.com ([10.120.0.2]) by vivacenetworks.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 13 Mar 2003 11:15:48 -0800
Message-Id: <5.2.0.9.0.20030313141235.04446540@mail.attbi.com>
X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 13 Mar 2003 14:15:06 -0500
To: George Swallow <swallow@cisco.com>, rahul@redback.com
From: "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>
Subject: Re: Draft MPLS Agenda
Cc: mpls@UU.NET
In-Reply-To: <200303112214.RAA13402@bifocal.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 13 Mar 2003 19:15:48.0810 (UTC) FILETIME=[F49C22A0:01C2E994]
Sender: owner-mpls@UU.NET
Precedence: bulk

George and Rahul,

Is draft-raggarwa-mpls-mcast-te-00.txt publicly available anywhere?  I 
certainly can't find it (nor can google).  If not, I don't think it should 
be on the agenda.

Thanks,
Andy

--------

At 3/11/2003 05:14 PM -0500, George Swallow wrote:


>San Francisco                MPLS WG Agenda                    56th IETF
>
>TUESDAY, March 18, 2002                                    Continental 6
>0900-1130
>
>
>1.  Agenda bashing                                                 5 min
>
>2.  Overview of ISOCORE Interoperability Tests
>
>     Rajiv Papneja                                                 10 min
>
>
>3.  TE related drafts
>
>     Jean Philippe Vasseur                                         20 min
>
>         Reoptimization of an explicit loosely routed MPLS TE paths
>             <draft-vasseur-mpls-loose-path-reopt-01.txt>
>
>         MPLS Traffic Engineering Fast reroute: bypass tunnel path
>           computation for bandwidth protection
>             <draft-vasseur-mpls-backup-computation-02.txt>
>
>         Definition of an RRO node-id subobject
>             <draft-vasseur-mpls-nodeid-subobject-00.txt>
>
>
>     Matthew Meyer                                                 10 min
>
>         MPLS Traffic Engineering Soft preemption
>             <draft-meyer-mpls-soft-preemption-00.txt>
>
>
>4.  Graceful Restart
>
>     Bob Thomas                                                    10 min
>
>         LDP DoD Graceful Restart
>             <draft-thomas-mpls-ldp-dod-restart-00.txt
>
>
>5.  OAM
>
>     Tom Nadeau                                                    10 min
>
>         OAM Requirements for MPLS Networks
>             <draft-nadeau-ietf-oam-requirements-01.txt
>
>     Dave Allen                                                     5 min
>
>         Y.1711 and LSP-PING
>             <draft-allan-y1711-and-lsp-ping-00.txt>
>
>     Kireeti Kompella                                              10 min
>
>         Detecting MPLS Data Plane Liveness
>             <draft-ietf-mpls-lsp-ping-02.txt>
>
>
>6.  MIBs
>
>     Tom Nadeau                                                    10 min
>
>         Multiprotocol Label Switching (MPLS) Traffic Engineering
>           Management Information Base for Fast Reroute
>             <draft-ietf-mpls-fastreroute-mib-01.txt
>
>         Multiprotocol Label Switching (MPLS) Label-Controlled ATM
>           and Frame-Relay Management Interface Definition
>             <draft-nadeau-mpls-lc-if-mib-00.txt
>
>
>7.  Explicitly routed Multicast
>
>     Seisho Yasukawa                                               10 min
>
>         Requirements for Point-to-Multipoint capability extension
>             <draft-yasukawa-mpls-p2mp-requirement-00.txt>
>
>     Alan Kullberg                                                 10 min
>
>         Extended RSVP-TE for Point-to-Multipoint LSP Tunnels
>             <draft-yasukawa-mpls-rsvp-p2mp-01.txt>
>
>     Rahul Aggarwal                                                10 min
>
>         Multicast Traffic Engineering with MPLS
>             <draft-raggarwa-mpls-mcast-te-00.txt>
>
>
>8.  Header Compression
>
>     Jerry Ash                                                     15 min
>
>         Requirements for End-to-End VoIP Header Compression
>             <draft-ash-e2e-voip-hdr-comp-rqmts-00.txt>
>
>         End-to-End VoIP Header Compression Using cRTP
>             <draft-ash-e2e-crtp-hdr-compress-01.txt>
>
>         End-to-End VoIP over MPLS Header Compression
>             <draft-ash-e2e-vompls-hdr-compress-01.txt>
>
>
>9.  Draft Status Update
>
>     George Swallow                                                 5 min
>
>
>10. Charter Discussion                                            10 min



From owner-mpls@UU.NET  Thu Mar 13 14:54:20 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15202
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 14:54:20 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwp02041
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 19:56:30 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofwp01790;
	Thu, 13 Mar 2003 19:56:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofwo01149
	for mpls-outgoing; Thu, 13 Mar 2003 19:30:06 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQofwo01138
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 19:30:02 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofwn07993
	for <mpls@uu.net>; Thu, 13 Mar 2003 19:29:12 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwn20387
	for <mpls@uu.net>; Thu, 13 Mar 2003 19:29:11 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQofwn20368
	for <mpls@uu.net>; Thu, 13 Mar 2003 19:29:10 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2DJT8vD005161
	for <mpls@uu.net>; Thu, 13 Mar 2003 14:29:08 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA28531 for <mpls@uu.net>; Thu, 13 Mar 2003 14:29:07 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2DJT7R05618 for mpls@uu.net; Thu, 13 Mar 2003 14:29:07 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofwn01019
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 19:27:19 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofwn19215
	for <mpls@UU.NET>; Thu, 13 Mar 2003 19:26:51 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwn15610
	for <mpls@UU.NET>; Thu, 13 Mar 2003 19:26:51 GMT
Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQofwn15571
	for <mpls@UU.NET>; Thu, 13 Mar 2003 19:26:50 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA90668;
	Thu, 13 Mar 2003 14:25:54 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303131925.OAA90668@workhorse.fictitious.org>
To: Steve Yao <syao@chiaro.com>
cc: "'curtis@fictitious.org'" <curtis@fictitious.org>, mpls <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: Between OSPF RSVP... 
In-reply-to: Your message of "Thu, 13 Mar 2003 12:45:04 CST."
             <F69EB380D594D611BBEA00065B3F14B4A35250@MAIL> 
Date: Thu, 13 Mar 2003 14:25:54 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <F69EB380D594D611BBEA00065B3F14B4A35250@MAIL>, Steve Yao writes:
> 
> 
> >Then the path-tear and/or the directed notify would still notify the
> >ingress.
> >
> >What circumstances are you thinking of.
> >
> >Curtis
> >
> 
> I guess it is suffice to say that the linked list mechanism does not cover
> all the cases.
> 
> Steve


It wasn't intended to cover all cases and does not depricate use of
path-tear.  You still didn't answer my question.

Curtis



From owner-mpls@UU.NET  Thu Mar 13 15:53:55 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18708
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 15:53:55 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwt03075
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 20:56:05 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofwt02614;
	Thu, 13 Mar 2003 20:55:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofwr24218
	for mpls-outgoing; Thu, 13 Mar 2003 20:28:13 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQofwr24213
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 20:28:11 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofwr02410
	for <mpls@UU.NET>; Thu, 13 Mar 2003 20:27:51 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwr12373
	for <mpls@UU.NET>; Thu, 13 Mar 2003 20:27:42 GMT
Received: from rchss002.chiaro.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: rchss002.chiaro.com [63.88.196.82])
	id QQofwr12346
	for <mpls@UU.NET>; Thu, 13 Mar 2003 20:27:41 GMT
Received: (qmail 10144 invoked from network); 13 Mar 2003 20:19:49 -0000
Received: from rchss002.chiaro.com (HELO mail.chiaro.com) (63.88.196.82)
  by rchss002.chiaro.com with SMTP; 13 Mar 2003 20:19:49 -0000
Received: by MAIL with Internet Mail Service (5.5.2653.19)
	id <GT079NMZ>; Thu, 13 Mar 2003 14:26:24 -0600
Message-ID: <F69EB380D594D611BBEA00065B3F14B4A35252@MAIL>
From: Steve Yao <syao@chiaro.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        Steve Yao
	 <syao@chiaro.com>
Cc: mpls <mpls@UU.NET>
Subject: RE: Between OSPF RSVP... 
Date: Thu, 13 Mar 2003 14:26:23 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/mixed; boundary="=_IS_MIME_Boundary"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=_IS_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"


>
>
>It wasn't intended to cover all cases and does not depricate use of
>path-tear.  You still didn't answer my question.
>
>Curtis
>

For one, ERO with loose hops. 

Steve
--=_IS_MIME_Boundary
Content-Type: text/plain;charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

----------------------------------------- (on Chiaro SMTP Relay)

This e-mail and any files transmitted with it are the property
of Chiaro Networks, Ltd., and may contain confidential and 
privileged material for the sole use of the intended recipient(s)
to whom this e-mail is addressed. If you are not one of the named
recipient(s), or otherwise have reason to believe that you have 
received this message in error, please notify the sender and 
delete all copies from your system.  Any other use, retention, 
dissemination, forwarding, printing or copying of this e-mail is 
strictly prohibited.


---------------------------------------------------------

--=_IS_MIME_Boundary--


From owner-mpls@UU.NET  Thu Mar 13 16:04:49 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19079
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 16:04:48 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwu23074
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 21:06:59 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofwu22725;
	Thu, 13 Mar 2003 21:06:46 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofws24954
	for mpls-outgoing; Thu, 13 Mar 2003 20:38:44 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofws24949
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 20:38:39 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofws03070
	for <mpls@UU.NET>; Thu, 13 Mar 2003 20:37:01 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofws28682
	for <mpls@UU.NET>; Thu, 13 Mar 2003 20:37:00 GMT
Received: from hoemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail1.lucent.com [192.11.226.161])
	id QQofws28661
	for <mpls@UU.NET>; Thu, 13 Mar 2003 20:37:00 GMT
Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58])
	by hoemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2DKavN18655;
	Thu, 13 Mar 2003 15:36:57 -0500 (EST)
Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.58.32]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id PAA19477; Thu, 13 Mar 2003 15:36:57 -0500 (EST)
Message-ID: <3E70EBE8.6E9673AF@lucent.com>
Date: Thu, 13 Mar 2003 15:36:56 -0500
From: Yangguang Xu <xuyg@lucent.com>
Organization: Lucent Technologies, Inc.
X-Mailer: Mozilla 4.7 [en]C-EMS-1.4  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: curtis@fictitious.org
CC: Steve Yao <syao@chiaro.com>, mpls <mpls@UU.NET>
Subject: Re: Between OSPF RSVP...
References: <200303131925.OAA90668@workhorse.fictitious.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


You were talking about implementation with linked list to each port to speed up
traversing. His point is, I think, the failure can happen any port/link in the
network, construct data structure according to the HE local ports may not
helpful in some cases. 

Curtis Villamizar wrote:
> 
> In message <F69EB380D594D611BBEA00065B3F14B4A35250@MAIL>, Steve Yao writes:
> >
> >
> > >Then the path-tear and/or the directed notify would still notify the
> > >ingress.
> > >
> > >What circumstances are you thinking of.
> > >
> > >Curtis
> > >
> >
> > I guess it is suffice to say that the linked list mechanism does not cover
> > all the cases.
> >
> > Steve
> 
> It wasn't intended to cover all cases and does not depricate use of
> path-tear.  You still didn't answer my question.
> 
> Curtis


From owner-mpls@UU.NET  Thu Mar 13 16:56:29 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20996
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 16:56:28 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwx29794
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 21:58:39 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofwx29211;
	Thu, 13 Mar 2003 21:58:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofwv17378
	for mpls-outgoing; Thu, 13 Mar 2003 21:18:05 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQofwv17362
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 21:17:56 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQofwv00937
	for <mpls@uu.net>; Thu, 13 Mar 2003 21:17:07 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwv20493
	for <mpls@uu.net>; Thu, 13 Mar 2003 21:17:06 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQofwv20462
	for <mpls@uu.net>; Thu, 13 Mar 2003 21:17:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2DLH3vD018683
	for <mpls@uu.net>; Thu, 13 Mar 2003 16:17:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA08540 for <mpls@uu.net>; Thu, 13 Mar 2003 16:17:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2DLH2M14750 for mpls@uu.net; Thu, 13 Mar 2003 16:17:02 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofwv17083
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 21:15:36 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofwv26766
	for <mpls@UU.NET>; Thu, 13 Mar 2003 21:15:31 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwv10019
	for <mpls@UU.NET>; Thu, 13 Mar 2003 21:15:31 GMT
Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQofwv10003
	for <mpls@UU.NET>; Thu, 13 Mar 2003 21:15:30 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA91906;
	Thu, 13 Mar 2003 16:14:22 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303132114.QAA91906@workhorse.fictitious.org>
To: Steve Yao <syao@chiaro.com>
cc: "'curtis@fictitious.org'" <curtis@fictitious.org>, mpls <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: Between OSPF RSVP... 
In-reply-to: Your message of "Thu, 13 Mar 2003 14:26:23 CST."
             <F69EB380D594D611BBEA00065B3F14B4A35252@MAIL> 
Date: Thu, 13 Mar 2003 16:14:22 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <F69EB380D594D611BBEA00065B3F14B4A35252@MAIL>, Steve Yao writes:
> --=_IS_MIME_Boundary
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> 
> >It wasn't intended to cover all cases and does not depricate use of
> >path-tear.  You still didn't answer my question.
> >
> >Curtis
> >
> 
> For one, ERO with loose hops. 
> 
> Steve


Which comes back as as a RESV with an RRO with the loose hops replaced
by the actual hops.  The ERO can then be changed to pin the path, but
if not, the RRO should get updated if the path changes.

Curtis



From owner-mpls@UU.NET  Thu Mar 13 17:03:49 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21233
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 17:03:49 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwy15254
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 22:06:00 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofwy14710;
	Thu, 13 Mar 2003 22:05:46 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofwv17755
	for mpls-outgoing; Thu, 13 Mar 2003 21:23:12 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofwv17732
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 21:23:00 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofwv28037
	for <mpls@UU.NET>; Thu, 13 Mar 2003 21:22:49 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwv23706
	for <mpls@UU.NET>; Thu, 13 Mar 2003 21:22:48 GMT
Received: from ns2.vivacenetworks.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [64.221.212.135])
	id QQofwv23668
	for <mpls@UU.NET>; Thu, 13 Mar 2003 21:22:47 GMT
Received: from amalisxp.vivacenetworks.com ([10.120.0.2]) by vivacenetworks.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 13 Mar 2003 13:22:45 -0800
Message-Id: <5.2.0.9.0.20030313162057.049d9b60@po1.vivacenetworks.com>
X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 13 Mar 2003 16:22:31 -0500
To: Steve Yao <syao@chiaro.com>
From: "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>
Subject: RE: Between OSPF RSVP... 
Cc: "'Kireeti Kompella'" <kireeti@juniper.net>,
        Curtis Villamizar <curtis@fictitious.org>, mpls <mpls@UU.NET>
In-Reply-To: <F69EB380D594D611BBEA00065B3F14B4A3524F@MAIL>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 13 Mar 2003 21:22:45.0894 (UTC) FILETIME=[B0BEEA60:01C2E9A6]
Sender: owner-mpls@UU.NET
Precedence: bulk


> >There are some who want me to spell it out, so here goes: if an
> >LSP goes over some link that subsequently fails, and the head end
> >learns this via OSPF/ISIS, the head end will switch to a backup,
> >or reroute the LSP.  The mechanism is pretty much what Curtis has
> >been describing.
> >
> >No smoke, no mirrors :-)
> >
> >Kireeti.
>
>Chiaro does this too.

And Vivace as well.

Cheers,
Andy



From owner-mpls@UU.NET  Thu Mar 13 17:25:39 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21985
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 17:25:38 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwz22682
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 22:27:49 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofwz22130;
	Thu, 13 Mar 2003 22:27:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofww18942
	for mpls-outgoing; Thu, 13 Mar 2003 21:37:17 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofww18923
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 21:37:10 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofww22130
	for <mpls@UU.NET>; Thu, 13 Mar 2003 21:36:24 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofww10510
	for <mpls@UU.NET>; Thu, 13 Mar 2003 21:36:24 GMT
Received: from rchss002.chiaro.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: rchss002.chiaro.com [63.88.196.82])
	id QQofww10496
	for <mpls@UU.NET>; Thu, 13 Mar 2003 21:36:23 GMT
Received: (qmail 12846 invoked from network); 13 Mar 2003 21:28:30 -0000
Received: from rchss002.chiaro.com (HELO mail.chiaro.com) (63.88.196.82)
  by rchss002.chiaro.com with SMTP; 13 Mar 2003 21:28:30 -0000
Received: by MAIL with Internet Mail Service (5.5.2653.19)
	id <GT079NWY>; Thu, 13 Mar 2003 15:35:29 -0600
Message-ID: <F69EB380D594D611BBEA00065B3F14B4A35254@MAIL>
From: Steve Yao <syao@chiaro.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>
Cc: mpls <mpls@UU.NET>
Subject: RE: Between OSPF RSVP... 
Date: Thu, 13 Mar 2003 15:35:28 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/mixed; boundary="=_IS_MIME_Boundary"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=_IS_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

>
>Which comes back as as a RESV with an RRO with the loose hops replaced
>by the actual hops.  The ERO can then be changed to pin the path, but
>if not, the RRO should get updated if the path changes.
>
>Curtis
>

The RRO received at the HE only contains the IP addresses that map to half
of the LSAs or LSPs that the LSP traversed. 

Steve
--=_IS_MIME_Boundary
Content-Type: text/plain;charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

----------------------------------------- (on Chiaro SMTP Relay)

This e-mail and any files transmitted with it are the property
of Chiaro Networks, Ltd., and may contain confidential and 
privileged material for the sole use of the intended recipient(s)
to whom this e-mail is addressed. If you are not one of the named
recipient(s), or otherwise have reason to believe that you have 
received this message in error, please notify the sender and 
delete all copies from your system.  Any other use, retention, 
dissemination, forwarding, printing or copying of this e-mail is 
strictly prohibited.


---------------------------------------------------------

--=_IS_MIME_Boundary--


From owner-mpls@UU.NET  Thu Mar 13 17:43:25 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22351
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 17:43:25 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofxb01305
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 22:45:33 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofxb00337;
	Thu, 13 Mar 2003 22:45:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofwy08560
	for mpls-outgoing; Thu, 13 Mar 2003 22:05:44 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofwy08549
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 22:05:43 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQofwy15260
	for <mpls@uu.net>; Thu, 13 Mar 2003 22:05:08 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwy13364
	for <mpls@uu.net>; Thu, 13 Mar 2003 22:05:07 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQofwy13329
	for <mpls@uu.net>; Thu, 13 Mar 2003 22:05:06 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2DM53Sc022558
	for <mpls@uu.net>; Thu, 13 Mar 2003 17:05:04 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA12454 for <mpls@uu.net>; Thu, 13 Mar 2003 17:05:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2DM53s21066 for mpls@uu.net; Thu, 13 Mar 2003 17:05:03 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQofwy02474
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 22:04:08 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQofwy06040
	for <mpls@uu.net>; Thu, 13 Mar 2003 22:03:36 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwy10208
	for <mpls@uu.net>; Thu, 13 Mar 2003 22:03:36 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQofwy10180
	for <mpls@uu.net>; Thu, 13 Mar 2003 22:03:35 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2DM3USc022346
	for <mpls@uu.net>; Thu, 13 Mar 2003 17:03:34 -0500 (EST)
Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA12329 for <mpls@uu.net>; Thu, 13 Mar 2003 17:03:29 -0500 (EST)
Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA07152 for <mpls@uu.net>; Thu, 13 Mar 2003 17:03:29 -0500 (EST)
Message-Id: <200303132203.RAA07152@bifocal.cisco.com>
X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs
To: mpls@UU.NET
Subject: [IETF Proceedings Administrator: Preliminary Submissions for IETF 56]
Date: Thu, 13 Mar 2003 17:03:29 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


As I interpret this, you only need to post a day before the meeting
time if you want you presentation available on the web.  But this is a
new procedure for getting your presentations into the minutes.  So if
you can make the deadline please do so.  If not, please post them
right after the MPLS meeting.

...George
 
========================================================================

This message is for all group chairs who will be attending the 56th IETF
in San Francisco.

All presentations must be submitted to minutes@ietf.org.

www.ietf.org/proceedings/03mar/

Presentations may be submitted before group meetings for a central
meeting archive.  Interim meeting materials will also be posted for
reference.  After March 14th, please allow one full business day for
materials to be posted online.

Please see www.ietf.org/proceedings/03mar/  for details and status.




From owner-mpls@UU.NET  Thu Mar 13 17:48:52 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22525
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 17:48:52 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofxb13536
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 22:51:00 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofxb13047;
	Thu, 13 Mar 2003 22:50:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofwz11377
	for mpls-outgoing; Thu, 13 Mar 2003 22:17:11 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofwz11340
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 22:16:59 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQofwz05258
	for <mpls@uu.net>; Thu, 13 Mar 2003 22:16:11 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwz03683
	for <mpls@uu.net>; Thu, 13 Mar 2003 22:16:10 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQofwz03666
	for <mpls@uu.net>; Thu, 13 Mar 2003 22:16:10 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2DMG7vD023791
	for <mpls@uu.net>; Thu, 13 Mar 2003 17:16:08 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA13376 for <mpls@uu.net>; Thu, 13 Mar 2003 17:16:07 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2DMG7r22891 for mpls@uu.net; Thu, 13 Mar 2003 17:16:07 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofwy10777
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 22:14:03 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofwy28168
	for <mpls@UU.NET>; Thu, 13 Mar 2003 22:13:55 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofwy16685
	for <mpls@UU.NET>; Thu, 13 Mar 2003 22:13:55 GMT
Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQofwy16659
	for <mpls@UU.NET>; Thu, 13 Mar 2003 22:13:53 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id RAA92148;
	Thu, 13 Mar 2003 17:12:41 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303132212.RAA92148@workhorse.fictitious.org>
To: Yangguang Xu <xuyg@lucent.com>
cc: curtis@fictitious.org, Steve Yao <syao@chiaro.com>, mpls <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: Between OSPF RSVP... 
In-reply-to: Your message of "Thu, 13 Mar 2003 15:36:56 EST."
             <3E70EBE8.6E9673AF@lucent.com> 
Date: Thu, 13 Mar 2003 17:12:41 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <3E70EBE8.6E9673AF@lucent.com>, Yangguang Xu writes:
> 
> You were talking about implementation with linked list to each port to speed 
> up
> traversing. His point is, I think, the failure can happen any port/link in th
> e
> network, construct data structure according to the HE local ports may not
> helpful in some cases. 


That is not what I suggested and yes it would not be of much use.

For each link in the path, not just the first hop (port), one entry is
created.  How to create this sort of data structure is grad school
data structures 101 material.

Besides, if you only had a pointer from the immediate hop then we
wouldn't be discussing flooding because the failure is on a directly
connected link and doesn't need to be flooded.

Curtis


> Curtis Villamizar wrote:
> > 
> > In message <F69EB380D594D611BBEA00065B3F14B4A35250@MAIL>, Steve Yao writes:
> > >
> > >
> > > >Then the path-tear and/or the directed notify would still notify the
> > > >ingress.
> > > >
> > > >What circumstances are you thinking of.
> > > >
> > > >Curtis
> > > >
> > >
> > > I guess it is suffice to say that the linked list mechanism does not cove
> r
> > > all the cases.
> > >
> > > Steve
> > 
> > It wasn't intended to cover all cases and does not depricate use of
> > path-tear.  You still didn't answer my question.
> > 
> > Curtis
> 



From owner-mpls@UU.NET  Thu Mar 13 18:58:23 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25856
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 18:58:23 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofxg04077
	for <mpls-archive@lists.ietf.org>; Fri, 14 Mar 2003 00:00:32 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofxg02540;
	Fri, 14 Mar 2003 00:00:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofxd05789
	for mpls-outgoing; Thu, 13 Mar 2003 23:26:18 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofxd05782
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 23:26:14 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofxd06821
	for <mpls@uu.net>; Thu, 13 Mar 2003 23:25:24 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofxd16631
	for <mpls@uu.net>; Thu, 13 Mar 2003 23:25:16 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQofxd16266
	for <mpls@uu.net>; Thu, 13 Mar 2003 23:25:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2DNP2Sc003229
	for <mpls@uu.net>; Thu, 13 Mar 2003 18:25:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA18383 for <mpls@uu.net>; Thu, 13 Mar 2003 18:25:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2DNP1s02176 for mpls@uu.net; Thu, 13 Mar 2003 18:25:01 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQofxd05564
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 23:24:11 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofxd16321
	for <mpls@UU.NET>; Thu, 13 Mar 2003 23:24:09 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofxd13370
	for <mpls@UU.NET>; Thu, 13 Mar 2003 23:24:08 GMT
Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQofxd13255
	for <mpls@UU.NET>; Thu, 13 Mar 2003 23:24:02 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id SAA92583;
	Thu, 13 Mar 2003 18:22:54 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303132322.SAA92583@workhorse.fictitious.org>
To: Steve Yao <syao@chiaro.com>
cc: "'curtis@fictitious.org'" <curtis@fictitious.org>, mpls <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: Between OSPF RSVP... 
In-reply-to: Your message of "Thu, 13 Mar 2003 15:35:28 CST."
             <F69EB380D594D611BBEA00065B3F14B4A35254@MAIL> 
Date: Thu, 13 Mar 2003 18:22:54 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <F69EB380D594D611BBEA00065B3F14B4A35254@MAIL>, Steve Yao writes:
> --=_IS_MIME_Boundary
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> 
> >
> >Which comes back as as a RESV with an RRO with the loose hops replaced
> >by the actual hops.  The ERO can then be changed to pin the path, but
> >if not, the RRO should get updated if the path changes.
> >
> >Curtis
> >
> 
> The RRO received at the HE only contains the IP addresses that map to half
> of the LSAs or LSPs that the LSP traversed. 
> 
> Steve


I'm not sure how you reach that conclusion.  There is both addr and
neighbor in the IGP TE extensions for numbered interfaces.  The RRO
hops match the neighbor side.  That gives the exact IGP LSAs or LSPDU
TLVs and gives the near side (the one likely to arrive first).

When a link goes down, one LSA or LSPDU fragment is originated by two
LSR, one on each side of the link.  When either LSA/LSPDU arrives, the
TE-LSDB unidirectional adjacency (or link) in both directions is
considered down.  The two unidirectional data structures each have a
set of MPLS LSP data structures linked to them (actually other small
structures that point to the LSP, but that's some of the data
structures 101 material).

If you mean that the LSA/LSPDU for the type-2/pseudonode of a
broadcast interface is not explicitly present, then quite frankly,
knowing the node of the previous hop and the next interface this is
not an incredibly hard problem to solve either.

If that's not what you meant, please let me know.

Curtis



From owner-mpls@UU.NET  Thu Mar 13 20:12:50 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27939
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 20:12:50 -0500 (EST)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofxa26423;
	Thu, 13 Mar 2003 22:30:18 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofww19068
	for mpls-outgoing; Thu, 13 Mar 2003 21:39:59 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofww19052
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 21:39:45 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQofww25183
	for <mpls@uu.net>; Thu, 13 Mar 2003 21:38:05 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofww25018
	for <mpls@uu.net>; Thu, 13 Mar 2003 21:38:05 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQofww25010
	for <mpls@uu.net>; Thu, 13 Mar 2003 21:38:04 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2DLc2vD020706
	for <mpls@uu.net>; Thu, 13 Mar 2003 16:38:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA10379 for <mpls@uu.net>; Thu, 13 Mar 2003 16:38:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2DLc1u17021 for mpls@uu.net; Thu, 13 Mar 2003 16:38:01 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofww18902
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Mar 2003 21:36:52 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofww02473
	for <mpls@UU.NET>; Thu, 13 Mar 2003 21:36:48 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofww11131
	for <mpls@UU.NET>; Thu, 13 Mar 2003 21:36:47 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQofww11098
	for <mpls@UU.NET>; Thu, 13 Mar 2003 21:36:46 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2DLadSc018102;
	Thu, 13 Mar 2003 16:36:39 -0500 (EST)
Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA10243; Thu, 13 Mar 2003 16:36:39 -0500 (EST)
Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA06982; Thu, 13 Mar 2003 16:36:38 -0500 (EST)
Message-Id: <200303132136.QAA06982@bifocal.cisco.com>
X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs
To: "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>
cc: George Swallow <swallow@cisco.com>, rahul@redback.com, mpls@UU.NET,
        swallow@cisco.com
Subject: Re: Draft MPLS Agenda 
In-reply-to: Your message of "Thu, 13 Mar 2003 14:15:06 EST."
             <5.2.0.9.0.20030313141235.04446540@mail.attbi.com> 
Date: Thu, 13 Mar 2003 16:36:38 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Rahul -

can you put it on a server and post a URL to the list?

Thanks,

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824



From owner-mpls@UU.NET  Thu Mar 13 20:22:24 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28065
	for <mpls-archive@lists.ietf.org>; Thu, 13 Mar 2003 20:22:24 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofxl04498
	for <mpls-archive@lists.ietf.org>; Fri, 14 Mar 2003 01:24:34 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofxl03524;
	Fri, 14 Mar 2003 01:24:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofxj00904
	for mpls-outgoing; Fri, 14 Mar 2003 00:58:45 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQofxj00891
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 14 Mar 2003 00:58:41 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofxj07910
	for <mpls@UU.NET>; Fri, 14 Mar 2003 00:58:31 GMT
From: dykwak@etri.re.kr
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofxj27731
	for <mpls@UU.NET>; Fri, 14 Mar 2003 00:58:30 GMT
Received: from cms1.etri.re.kr by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cms1.etri.re.kr [129.254.16.11])
	id QQofxj27696
	for <mpls@UU.NET>; Fri, 14 Mar 2003 00:58:29 GMT
Received: by cms1 with Internet Mail Service (5.5.2653.19)
	id <GRNPP22G>; Fri, 14 Mar 2003 09:58:00 +0900
Message-ID: <54A1DDB4ACD5D511B0F900D0B7A8DC089B3F85@cms1>
To: mpls@UU.NET
Subject: DisSubcribe
Date: Fri, 14 Mar 2003 09:58:00 +0900
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2E9C4.C23EE9C0"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2E9C4.C23EE9C0
Content-Type: text/plain;
	charset="euc-kr"

Dissubscribe 

------_=_NextPart_001_01C2E9C4.C23EE9C0
Content-Type: text/html;
	charset="euc-kr"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=euc-kr">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>DisSubcribe</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Dissubscribe</FONT> 
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2E9C4.C23EE9C0--


From owner-mpls@UU.NET  Fri Mar 14 05:34:48 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21232
	for <mpls-archive@lists.ietf.org>; Fri, 14 Mar 2003 05:34:48 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofyw05027
	for <mpls-archive@lists.ietf.org>; Fri, 14 Mar 2003 10:36:58 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofyw04653;
	Fri, 14 Mar 2003 10:36:46 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofyu07695
	for mpls-outgoing; Fri, 14 Mar 2003 10:11:40 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQofyu07690
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 14 Mar 2003 10:11:31 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofyu02373
	for <mpls@uu.net>; Fri, 14 Mar 2003 10:10:43 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofyu18065
	for <mpls@uu.net>; Fri, 14 Mar 2003 10:10:42 GMT
Received: from lut-ms-001.eu.anritsu.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.eu.anritsu.com [193.130.67.68])
	id QQofyu18040
	for <mpls@uu.net>; Fri, 14 Mar 2003 10:10:41 GMT
Received: from lut-ex-001.eu.anritsu.com (unverified) by 
    lut-ms-001.eu.anritsu.com (Content Technologies SMTPRS 4.3.6) with ESMTP 
    id <T60f86cf3aaac1c0126614@lut-ms-001.eu.anritsu.com> for <mpls@uu.net>; 
    Fri, 14 Mar 2003 10:12:30 +0000
Received: by ntlu-exchg.eu.anritsu.com with Internet Mail Service 
    (5.5.2653.19) id <DCQYNS55>; Fri, 14 Mar 2003 10:10:45 -0000
Message-ID: 
    <A8D0C34A94F2D548847BAA3E79146D5501B55ADD@ntlu-exchg.eu.anritsu.com>
From: "Grant, Ken" <Ken.Grant@eu.anritsu.com>
To: mpls@UU.NET
Subject: Dessubscribe
Date: Fri, 14 Mar 2003 10:10:44 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk




---------------------
This email message, together with any attachments, is for the exclusive and
confidential use of the addressee(s).  If you have received this message in
error, please notify the sender by email immediately, then delete the
message and any copies.  Any views or opinions presented herein are solely
those of the author and do not necessarily represent those of the Anritsu
group of companies.
Discover What's Possible - www.eu.anritsu.com
---------------------



From owner-mpls@UU.NET  Fri Mar 14 12:00:59 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02666
	for <mpls-archive@lists.ietf.org>; Fri, 14 Mar 2003 12:00:59 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofzw22883
	for <mpls-archive@lists.ietf.org>; Fri, 14 Mar 2003 17:03:10 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofzw22459;
	Fri, 14 Mar 2003 17:02:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofzu25768
	for mpls-outgoing; Fri, 14 Mar 2003 16:32:17 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofzu25740
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 14 Mar 2003 16:32:09 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofzu11616
	for <mpls@UU.NET>; Fri, 14 Mar 2003 16:31:21 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofzu02918
	for <mpls@UU.NET>; Fri, 14 Mar 2003 16:31:20 GMT
Received: from rchss002.chiaro.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: rchss002.chiaro.com [63.88.196.82])
	id QQofzt25401
	for <mpls@UU.NET>; Fri, 14 Mar 2003 16:28:57 GMT
Received: (qmail 21283 invoked from network); 14 Mar 2003 16:21:03 -0000
Received: from rchss002.chiaro.com (HELO mail.chiaro.com) (63.88.196.82)
  by rchss002.chiaro.com with SMTP; 14 Mar 2003 16:21:03 -0000
Received: by MAIL with Internet Mail Service (5.5.2653.19)
	id <GT079PGW>; Fri, 14 Mar 2003 10:27:40 -0600
Message-ID: <F69EB380D594D611BBEA00065B3F14B4A35257@MAIL>
From: Steve Yao <syao@chiaro.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>
Cc: mpls <mpls@UU.NET>
Subject: RE: Between OSPF RSVP... 
Date: Fri, 14 Mar 2003 10:27:39 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/mixed; boundary="=_IS_MIME_Boundary"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=_IS_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"




>
>I'm not sure how you reach that conclusion.  There is both addr and
>neighbor in the IGP TE extensions for numbered interfaces.  The RRO
>hops match the neighbor side.  That gives the exact IGP LSAs or LSPDU
>TLVs and gives the near side (the one likely to arrive first).
>

>When a link goes down, one LSA or LSPDU fragment is originated by two
>LSR, one on each side of the link.  When either LSA/LSPDU arrives, the
>TE-LSDB unidirectional adjacency (or link) in both directions is
>considered down.  The two unidirectional data structures each have a
>set of MPLS LSP data structures linked to them (actually other small
>structures that point to the LSP, but that's some of the data
>structures 101 material).
>
>If you mean that the LSA/LSPDU for the type-2/pseudonode of a
>broadcast interface is not explicitly present, then quite frankly,
>knowing the node of the previous hop and the next interface this is
>not an incredibly hard problem to solve either.
>
>If that's not what you meant, please let me know.
>
>Curtis
>

Yes. You are right. I missed the link ID and pseudonode.
Then there is the case where RRO may be too large. What cases were you
thinking of?

Steve
--=_IS_MIME_Boundary
Content-Type: text/plain;charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

----------------------------------------- (on Chiaro SMTP Relay)

This e-mail and any files transmitted with it are the property
of Chiaro Networks, Ltd., and may contain confidential and 
privileged material for the sole use of the intended recipient(s)
to whom this e-mail is addressed. If you are not one of the named
recipient(s), or otherwise have reason to believe that you have 
received this message in error, please notify the sender and 
delete all copies from your system.  Any other use, retention, 
dissemination, forwarding, printing or copying of this e-mail is 
strictly prohibited.


---------------------------------------------------------

--=_IS_MIME_Boundary--


From owner-mpls@UU.NET  Fri Mar 14 12:05:06 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02849
	for <mpls-archive@lists.ietf.org>; Fri, 14 Mar 2003 12:05:06 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofzw22375
	for <mpls-archive@lists.ietf.org>; Fri, 14 Mar 2003 17:07:16 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofzw21581;
	Fri, 14 Mar 2003 17:06:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofzu25971
	for mpls-outgoing; Fri, 14 Mar 2003 16:38:42 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQofzu25956
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 14 Mar 2003 16:38:32 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofzu12439
	for <mpls@UU.NET>; Fri, 14 Mar 2003 16:38:28 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofzu27446
	for <mpls@UU.NET>; Fri, 14 Mar 2003 16:38:27 GMT
Received: from kanmx1.ca.alcatel.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: m115-138.on.tac.net [209.202.115.138] (may be forged))
	id QQofzu27432
	for <mpls@UU.NET>; Fri, 14 Mar 2003 16:38:26 GMT
Received: (qmail 18097 invoked from network); 14 Mar 2003 16:46:15 -0000
Received: from unknown (HELO alcatel.com) (138.120.105.193)
  by kanmx1.ca.alcatel.com with SMTP; 14 Mar 2003 16:46:15 -0000
Message-ID: <3E720581.E7491F43@alcatel.com>
Date: Fri, 14 Mar 2003 11:38:25 -0500
From: Shafiq Pirbhai <shafiq.pirbhai@alcatel.com>
Organization: Alcatel CID
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: review of draft-ietf-mpls-te-mib-09.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


In the mplsInSegmentPerfTable and mplsOutSegmentPerfTable tables (in
draft-ietf-mpls-lsr-mib-09.txt) there are entries for
mplsInSegmentDiscards and mplsOutSegmentDiscards respectively.

However in the mplsTunnelPerfTable (in draft-ietf-mpls-te-mib-09.txt)
there is no entry for "mplsTunnelPerfDiscards" and
"mplsTunnelPerfHCDiscards".  Is there a reason why it is missing from
the mplsTunnelPerfTable table?  Packets can be discarded due to errors,
congestion and QOS.  Therefore viewing the mplsTunnelPerfErrors counter
does not give the full picture.




From owner-mpls@UU.NET  Fri Mar 14 12:33:05 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03444
	for <mpls-archive@lists.ietf.org>; Fri, 14 Mar 2003 12:33:04 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofzy16113
	for <mpls-archive@lists.ietf.org>; Fri, 14 Mar 2003 17:35:15 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofzy15158;
	Fri, 14 Mar 2003 17:34:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofzw15491
	for mpls-outgoing; Fri, 14 Mar 2003 17:04:46 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQofzw15481
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 14 Mar 2003 17:04:44 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofzw00544
	for <mpls@uu.net>; Fri, 14 Mar 2003 17:04:15 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofzw16193
	for <mpls@uu.net>; Fri, 14 Mar 2003 17:04:14 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQofzw16174
	for <mpls@uu.net>; Fri, 14 Mar 2003 17:04:13 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2EH46Sc010023
	for <mpls@uu.net>; Fri, 14 Mar 2003 12:04:06 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA15157 for <mpls@uu.net>; Fri, 14 Mar 2003 12:04:05 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2EH45u21133 for mpls@uu.net; Fri, 14 Mar 2003 12:04:05 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQofzw08499
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 14 Mar 2003 17:03:13 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofzw08271
	for <mpls@UU.NET>; Fri, 14 Mar 2003 17:01:51 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofzw21337
	for <mpls@UU.NET>; Fri, 14 Mar 2003 17:01:50 GMT
Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQofzw21300
	for <mpls@UU.NET>; Fri, 14 Mar 2003 17:01:49 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA99457;
	Fri, 14 Mar 2003 12:00:30 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303141700.MAA99457@workhorse.fictitious.org>
To: Steve Yao <syao@chiaro.com>
cc: "'curtis@fictitious.org'" <curtis@fictitious.org>, mpls <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: Between OSPF RSVP... 
In-reply-to: Your message of "Fri, 14 Mar 2003 10:27:39 CST."
             <F69EB380D594D611BBEA00065B3F14B4A35257@MAIL> 
Date: Fri, 14 Mar 2003 12:00:30 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <F69EB380D594D611BBEA00065B3F14B4A35257@MAIL>, Steve Yao writes:
> 
> 
> >I'm not sure how you reach that conclusion.  There is both addr and
> >neighbor in the IGP TE extensions for numbered interfaces.  The RRO
> >hops match the neighbor side.  That gives the exact IGP LSAs or LSPDU
> >TLVs and gives the near side (the one likely to arrive first).
> >
> 
> >When a link goes down, one LSA or LSPDU fragment is originated by two
> >LSR, one on each side of the link.  When either LSA/LSPDU arrives, the
> >TE-LSDB unidirectional adjacency (or link) in both directions is
> >considered down.  The two unidirectional data structures each have a
> >set of MPLS LSP data structures linked to them (actually other small
> >structures that point to the LSP, but that's some of the data
> >structures 101 material).
> >
> >If you mean that the LSA/LSPDU for the type-2/pseudonode of a
> >broadcast interface is not explicitly present, then quite frankly,
> >knowing the node of the previous hop and the next interface this is
> >not an incredibly hard problem to solve either.
> >
> >If that's not what you meant, please let me know.
> >
> >Curtis
> >
> 
> Yes. You are right. I missed the link ID and pseudonode.
> Then there is the case where RRO may be too large. What cases were you
> thinking of?
> 
> Steve


Steve,

In two messages prior you stated:

> The RRO received at the HE only contains the IP addresses that map to half
> of the LSAs or LSPs that the LSP traversed. 

You mentioned that only half the LSA/LSPDU were in the RRO, so the
question "What cases were you thinking of?" that you just asked should
be directed to you.

Since you brought up the issue "where RRO may be too large" why don't
you do the math and tell us 1) how big the RRO would have to be to be
too large and 2) how likely you think that is of occurring.  RSVPd
objects can be 64KB each.  The IPv4 address subobject is 8 bytes long,
including type and length.  Add a label subobject (8 bytes) and fit it
into a reasonable MTU and you're still at hundreds of hops.  I get
200+ into a 4KB MTU and most networks seem to be going for 8K MTU so I
get "not very likely" for question 2).

Curtis



From owner-mpls@UU.NET  Fri Mar 14 12:38:36 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03526
	for <mpls-archive@lists.ietf.org>; Fri, 14 Mar 2003 12:38:36 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofzy12430
	for <mpls-archive@lists.ietf.org>; Fri, 14 Mar 2003 17:40:46 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofzy11990;
	Fri, 14 Mar 2003 17:40:30 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofzw17518
	for mpls-outgoing; Fri, 14 Mar 2003 17:11:09 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQofzw17259
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 14 Mar 2003 17:10:56 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQofzw27199
	for <mpls@UU.NET>; Fri, 14 Mar 2003 17:10:41 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofzw03666
	for <mpls@UU.NET>; Fri, 14 Mar 2003 17:10:40 GMT
Received: from prattle.redback.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: prattle.redback.com [155.53.12.9])
	id QQofzw03653
	for <mpls@UU.NET>; Fri, 14 Mar 2003 17:10:40 GMT
Received: from malt (malt.redback.com [155.53.12.41])
	by prattle.redback.com (Postfix) with ESMTP
	id B6CDA3BB2A0; Fri, 14 Mar 2003 09:10:35 -0800 (PST)
Date: Fri, 14 Mar 2003 09:10:35 -0800 (PST)
From: Rahul Aggarwal <rahul@redback.com>
X-Sender: rahul@malt
To: George Swallow <swallow@cisco.com>
Cc: "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>, mpls@UU.NET
Subject: Re: Draft MPLS Agenda 
In-Reply-To: <200303132136.QAA06982@bifocal.cisco.com>
Message-ID: <Pine.GSO.4.10.10303140901500.382-100000@malt>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi George and Andy,

The intention was to make draft-raggarwa-mpls-mcast-te-00.txt publicly
available before the MPLS WG meeting. However it turns out that the 
draft will probably not be ready for posting before the MPLS WG meeting..

Thanks,

rahul

On Thu, 13 Mar 2003, George Swallow wrote:

> Rahul -
> 
> can you put it on a server and post a URL to the list?
> 
> Thanks,
> 
> ...George
> 
> ==================================================================
> George Swallow       Cisco Systems                  (978) 497-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
> 



From owner-mpls@UU.NET  Fri Mar 14 12:49:35 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03883
	for <mpls-archive@lists.ietf.org>; Fri, 14 Mar 2003 12:49:34 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofzz00611
	for <mpls-archive@lists.ietf.org>; Fri, 14 Mar 2003 17:51:44 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQofzz00391;
	Fri, 14 Mar 2003 17:51:30 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofzx18693
	for mpls-outgoing; Fri, 14 Mar 2003 17:23:47 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofzx18673
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 14 Mar 2003 17:23:39 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQofzx12315
	for <mpls@UU.NET>; Fri, 14 Mar 2003 17:22:51 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofzx17531
	for <mpls@UU.NET>; Fri, 14 Mar 2003 17:22:51 GMT
Received: from ns2.vivacenetworks.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [64.221.212.135])
	id QQofzx17523
	for <mpls@UU.NET>; Fri, 14 Mar 2003 17:22:50 GMT
Received: from amalisxp.vivacenetworks.com ([10.120.0.2]) by vivacenetworks.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Fri, 14 Mar 2003 09:22:48 -0800
Message-Id: <5.2.0.9.0.20030314122059.047a9d28@po1.vivacenetworks.com>
X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 14 Mar 2003 12:22:35 -0500
To: Rahul Aggarwal <rahul@redback.com>
From: "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>
Subject: Re: Draft MPLS Agenda 
Cc: George Swallow <swallow@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>, mpls@UU.NET
In-Reply-To: <Pine.GSO.4.10.10303140901500.382-100000@malt>
References: <200303132136.QAA06982@bifocal.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 14 Mar 2003 17:22:48.0824 (UTC) FILETIME=[55D61F80:01C2EA4E]
Sender: owner-mpls@UU.NET
Precedence: bulk

Rahul,

In that case, I definitely think it should be removed from the agenda - not 
having the draft makes it hard to prepare to discuss any issues. :-)

Cheers,
Andy

------

At 3/14/2003 09:10 AM -0800, Rahul Aggarwal wrote:


>Hi George and Andy,
>
>The intention was to make draft-raggarwa-mpls-mcast-te-00.txt publicly
>available before the MPLS WG meeting. However it turns out that the
>draft will probably not be ready for posting before the MPLS WG meeting..
>
>Thanks,
>
>rahul
>
>On Thu, 13 Mar 2003, George Swallow wrote:
>
> > Rahul -
> >
> > can you put it on a server and post a URL to the list?
> >
> > Thanks,
> >
> > ...George
> >
> > ==================================================================
> > George Swallow       Cisco Systems                  (978) 497-8143
> >                      250 Apollo Drive
> >                      Chelmsford, Ma 01824
> >



From owner-mpls@UU.NET  Fri Mar 14 13:16:31 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04557
	for <mpls-archive@lists.ietf.org>; Fri, 14 Mar 2003 13:16:31 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogab08635
	for <mpls-archive@lists.ietf.org>; Fri, 14 Mar 2003 18:18:41 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogab08314;
	Fri, 14 Mar 2003 18:18:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQofzz21117
	for mpls-outgoing; Fri, 14 Mar 2003 17:52:30 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQofzz21111
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 14 Mar 2003 17:52:29 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQofzz10558
	for <mpls@UU.NET>; Fri, 14 Mar 2003 17:52:00 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQofzz21269
	for <mpls@UU.NET>; Fri, 14 Mar 2003 17:52:00 GMT
Received: from rchss002.chiaro.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: rchss002.chiaro.com [63.88.196.82])
	id QQofzz21247
	for <mpls@UU.NET>; Fri, 14 Mar 2003 17:51:59 GMT
Received: (qmail 24279 invoked from network); 14 Mar 2003 17:44:20 -0000
Received: from rchss002.chiaro.com (HELO mail.chiaro.com) (63.88.196.82)
  by rchss002.chiaro.com with SMTP; 14 Mar 2003 17:44:20 -0000
Received: by MAIL with Internet Mail Service (5.5.2653.19)
	id <GT079P3B>; Fri, 14 Mar 2003 11:51:09 -0600
Message-ID: <F69EB380D594D611BBEA00065B3F14B4A3525A@MAIL>
From: Steve Yao <syao@chiaro.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>
Cc: mpls <mpls@UU.NET>
Subject: RE: Between OSPF RSVP... 
Date: Fri, 14 Mar 2003 11:51:09 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/mixed; boundary="=_IS_MIME_Boundary"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=_IS_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"



>Steve,
>
>In two messages prior you stated:
>
>> The RRO received at the HE only contains the IP addresses 
>that map to half
>> of the LSAs or LSPs that the LSP traversed. 
>
>You mentioned that only half the LSA/LSPDU were in the RRO, so the
>question "What cases were you thinking of?" that you just asked should
>be directed to you.

I asked the question since you mentioned earlier:

>It wasn't intended to cover all cases and does not depricate use of
>path-tear.  You still didn't answer my question.

But it is ok if you don't want to answer the question.

>
>Since you brought up the issue "where RRO may be too large" why don't
>you do the math and tell us 1) how big the RRO would have to be to be
>too large and 2) how likely you think that is of occurring.  RSVPd
>objects can be 64KB each.  The IPv4 address subobject is 8 bytes long,
>including type and length.  Add a label subobject (8 bytes) and fit it
>into a reasonable MTU and you're still at hundreds of hops.  I get
>200+ into a 4KB MTU and most networks seem to be going for 8K MTU so I
>get "not very likely" for question 2).
>
>Curtis
>

I agree that this is not very likely.

Steve
--=_IS_MIME_Boundary
Content-Type: text/plain;charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

----------------------------------------- (on Chiaro SMTP Relay)

This e-mail and any files transmitted with it are the property
of Chiaro Networks, Ltd., and may contain confidential and 
privileged material for the sole use of the intended recipient(s)
to whom this e-mail is addressed. If you are not one of the named
recipient(s), or otherwise have reason to believe that you have 
received this message in error, please notify the sender and 
delete all copies from your system.  Any other use, retention, 
dissemination, forwarding, printing or copying of this e-mail is 
strictly prohibited.


---------------------------------------------------------

--=_IS_MIME_Boundary--


From owner-mpls@UU.NET  Fri Mar 14 13:39:27 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06179
	for <mpls-archive@lists.ietf.org>; Fri, 14 Mar 2003 13:39:26 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogac28151
	for <mpls-archive@lists.ietf.org>; Fri, 14 Mar 2003 18:41:36 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogac27993;
	Fri, 14 Mar 2003 18:41:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogab11564
	for mpls-outgoing; Fri, 14 Mar 2003 18:15:46 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQogab11549
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 14 Mar 2003 18:15:44 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQogab27737
	for <mpls@uu.net>; Fri, 14 Mar 2003 18:15:14 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogab03591
	for <mpls@uu.net>; Fri, 14 Mar 2003 18:15:12 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQogab03457
	for <mpls@uu.net>; Fri, 14 Mar 2003 18:15:09 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2EIF6Sc020951
	for <mpls@uu.net>; Fri, 14 Mar 2003 13:15:06 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA20613 for <mpls@uu.net>; Fri, 14 Mar 2003 13:15:06 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2EIF6A29276 for mpls@uu.net; Fri, 14 Mar 2003 13:15:06 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQogaa11252
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 14 Mar 2003 18:14:25 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQogaa25485
	for <mpls@UU.NET>; Fri, 14 Mar 2003 18:14:12 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogaa24083
	for <mpls@UU.NET>; Fri, 14 Mar 2003 18:14:12 GMT
Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQogaa24078
	for <mpls@UU.NET>; Fri, 14 Mar 2003 18:14:11 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id NAA00328;
	Fri, 14 Mar 2003 13:13:03 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303141813.NAA00328@workhorse.fictitious.org>
To: Steve Yao <syao@chiaro.com>
cc: "'curtis@fictitious.org'" <curtis@fictitious.org>, mpls <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: Between OSPF RSVP... 
In-reply-to: Your message of "Fri, 14 Mar 2003 11:51:09 CST."
             <F69EB380D594D611BBEA00065B3F14B4A3525A@MAIL> 
Date: Fri, 14 Mar 2003 13:13:03 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <F69EB380D594D611BBEA00065B3F14B4A3525A@MAIL>, Steve Yao writes:
> 
> 
> >It wasn't intended to cover all cases and does not depricate use of
> >path-tear.  You still didn't answer my question.
> 
> But it is ok if you don't want to answer the question.


OK.  I wasn't trying to avoid a question, just lost track of which
question you were referring to.  There are a couple of cases.

The topic of running MPLS with an external path computation and
explicitly configured paths comes up from time to time.  Some carriers
claim they'd do this without running an IGP at all.  I don't know of
anyone that has successfully done this and I personnally think it is a
very bad idea but MPLS with explicitly configured paths and no IGP
running is a supported feature for many LSR anyway.

In inter-area MPLS, if hierarchical LSP were not used, the ingress
would set up paths across areas not it would not be notified of links
that went down in other areas.  Not running hierarchical LSP in this
case is probably not very scalable and creates this problem as well
but that network design issue is a matter of best practices.  The LSR
should "do the right thing" even if the network design is poor.

Those were the types of cases I was thinking of.

Curtis



From owner-mpls@UU.NET  Fri Mar 14 15:48:41 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13881
	for <mpls-archive@lists.ietf.org>; Fri, 14 Mar 2003 15:48:41 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogal18802
	for <mpls-archive@lists.ietf.org>; Fri, 14 Mar 2003 20:50:51 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogal18364;
	Fri, 14 Mar 2003 20:50:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogaj28307
	for mpls-outgoing; Fri, 14 Mar 2003 20:25:06 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQogaj28288
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 14 Mar 2003 20:24:54 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQogaj00515
	for <mpls@uu.net>; Fri, 14 Mar 2003 20:24:08 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogaj28109
	for <mpls@uu.net>; Fri, 14 Mar 2003 20:24:07 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQogaj28101
	for <mpls@uu.net>; Fri, 14 Mar 2003 20:24:07 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2EKO4Sc012554
	for <mpls@uu.net>; Fri, 14 Mar 2003 15:24:05 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA01996 for <mpls@uu.net>; Fri, 14 Mar 2003 15:24:04 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2EKO4r07496 for mpls@uu.net; Fri, 14 Mar 2003 15:24:04 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQogaj28216
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 14 Mar 2003 20:22:52 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQogaj10073
	for <mpls@uu.net>; Fri, 14 Mar 2003 20:22:36 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogaj25782
	for <mpls@uu.net>; Fri, 14 Mar 2003 20:22:35 GMT
Received: from auemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: auemail2.lucent.com [192.11.223.163])
	id QQogaj25770
	for <mpls@uu.net>; Fri, 14 Mar 2003 20:22:34 GMT
Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36])
	by auemail2.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2EKMXh20607
	for <mpls@uu.net>; Fri, 14 Mar 2003 15:22:33 -0500 (EST)
Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2653.19)
	id <FWCNFAMW>; Fri, 14 Mar 2003 15:22:33 -0500
Message-ID: <B99995113B318D44BBE87DC50092EDA961404A@nj7460exch006u.ho.lucent.com>
From: "Narayanaswamy, Naga (Naga)" <nn4@lucent.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: subscribe
Date: Fri, 14 Mar 2003 15:22:32 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

subscribe



From owner-mpls@UU.NET  Fri Mar 14 18:02:50 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17651
	for <mpls-archive@lists.ietf.org>; Fri, 14 Mar 2003 18:02:50 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogau04745
	for <mpls-archive@lists.ietf.org>; Fri, 14 Mar 2003 23:04:57 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogau04354;
	Fri, 14 Mar 2003 23:04:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogas15368
	for mpls-outgoing; Fri, 14 Mar 2003 22:36:39 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQogas15363
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 14 Mar 2003 22:36:33 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQogas02910
	for <mpls@uu.net>; Fri, 14 Mar 2003 22:36:14 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogas09271
	for <mpls@uu.net>; Fri, 14 Mar 2003 22:36:13 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQogas09261
	for <mpls@uu.net>; Fri, 14 Mar 2003 22:36:13 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2EMaASc002437
	for <mpls@uu.net>; Fri, 14 Mar 2003 17:36:10 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA11612 for <mpls@uu.net>; Fri, 14 Mar 2003 17:36:09 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2EMa9b15832 for mpls@uu.net; Fri, 14 Mar 2003 17:36:09 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQogas15113
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 14 Mar 2003 22:34:26 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQogas16983
	for <mpls@UU.NET>; Fri, 14 Mar 2003 22:34:15 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogas04241
	for <mpls@UU.NET>; Fri, 14 Mar 2003 22:34:14 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQogas04195
	for <mpls@UU.NET>; Fri, 14 Mar 2003 22:34:12 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2EMY8Sc002121;
	Fri, 14 Mar 2003 17:34:09 -0500 (EST)
Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA11465; Fri, 14 Mar 2003 17:34:04 -0500 (EST)
Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA20194; Fri, 14 Mar 2003 17:34:04 -0500 (EST)
Message-Id: <200303142234.RAA20194@bifocal.cisco.com>
X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs
To: "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>
cc: Rahul Aggarwal <rahul@redback.com>, George Swallow <swallow@cisco.com>,
        mpls@UU.NET, swallow@cisco.com
Subject: Re: Draft MPLS Agenda 
In-reply-to: Your message of "Fri, 14 Mar 2003 12:22:35 EST."
             <5.2.0.9.0.20030314122059.047a9d28@po1.vivacenetworks.com> 
Date: Fri, 14 Mar 2003 17:34:04 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

> In that case, I definitely think it should be removed from the agenda - not 
> having the draft makes it hard to prepare to discuss any issues. :-)

Yes - "No ticky, no shirty"

But you've put together a preliminary draft, no?  Is there a reason you
can't post that?

...George   

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824



From owner-mpls@UU.NET  Fri Mar 14 20:38:02 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22367
	for <mpls-archive@lists.ietf.org>; Fri, 14 Mar 2003 20:38:01 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogbe20477
	for <mpls-archive@lists.ietf.org>; Sat, 15 Mar 2003 01:40:12 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogbe20175;
	Sat, 15 Mar 2003 01:40:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogbc22467
	for mpls-outgoing; Sat, 15 Mar 2003 01:14:41 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQogbc22462
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 15 Mar 2003 01:14:33 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQogbc09106
	for <mpls@UU.NET>; Sat, 15 Mar 2003 01:14:23 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogbc20947
	for <mpls@UU.NET>; Sat, 15 Mar 2003 01:14:22 GMT
Received: from prattle.redback.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: prattle.redback.com [155.53.12.9])
	id QQogbc20932
	for <mpls@UU.NET>; Sat, 15 Mar 2003 01:14:22 GMT
Received: from malt (malt.redback.com [155.53.12.41])
	by prattle.redback.com (Postfix) with ESMTP
	id A4007204FDA; Fri, 14 Mar 2003 17:14:21 -0800 (PST)
Date: Fri, 14 Mar 2003 17:14:21 -0800 (PST)
From: Rahul Aggarwal <rahul@redback.com>
X-Sender: rahul@malt
To: George Swallow <swallow@cisco.com>
Cc: "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>, mpls@UU.NET
Subject: Re: Draft MPLS Agenda 
In-Reply-To: <200303142234.RAA20194@bifocal.cisco.com>
Message-ID: <Pine.GSO.4.10.10303141709130.382-100000@malt>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk



On Fri, 14 Mar 2003, George Swallow wrote:

> > In that case, I definitely think it should be removed from the agenda - not 
> > having the draft makes it hard to prepare to discuss any issues. :-)
> 
> Yes - "No ticky, no shirty"
> 
> But you've put together a preliminary draft, no?  Is there a reason you
> can't post that?

The draft needs some revisions and I would prefer posting a relatively
stable version. There are a couple of drafts on P2MP TE LSPs being
discussed in the MPLS WG at the upcoming IETF. Given that background a
presentation introducing the approach of
draft-raggarwa-mpls-mcast-te-00.xt may help in rounding the discussion.
That said I am fine with waiting for the next IETF.

Thanks,
rahul

> 
> ...George   
> 
> ==================================================================
> George Swallow       Cisco Systems                  (978) 497-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
> 
> 



From owner-mpls@UU.NET  Mon Mar 17 09:35:08 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14290
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 09:34:51 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogko16076
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 14:36:57 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogko15332;
	Mon, 17 Mar 2003 14:36:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogkm23451
	for mpls-outgoing; Mon, 17 Mar 2003 14:10:42 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQogkm23434
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 14:10:38 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQogkm12153
	for <mpls@UU.NET>; Mon, 17 Mar 2003 14:09:25 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogkm18111
	for <mpls@UU.NET>; Mon, 17 Mar 2003 14:09:24 GMT
Received: from thurn.corp.titan.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: thurn.corp.titan.com [159.62.51.20])
	id QQogkm18042
	for <mpls@UU.NET>; Mon, 17 Mar 2003 14:09:23 GMT
Received: from vcmd-nt1.validity.com (val114-005.validity.titan.com [159.62.114.5])
	by thurn.corp.titan.com (8.12.8/8.12.8) with ESMTP id h2HE8ErF018580;
	Mon, 17 Mar 2003 06:08:15 -0800
Received: by VCMD-NT1 with Internet Mail Service (5.5.2655.55)
	id <HCMW773F>; Mon, 17 Mar 2003 09:07:32 -0500
Message-ID: <561621C69F17D511A3A20050047340EC01AAF610@VCMD-NT1>
From: "Ferrell, William" <William.Ferrell@titan.com>
To: "'Steve Yao '" <syao@chiaro.com>,
        "''curtis@fictitious.org' '"
	 <curtis@fictitious.org>
Cc: "'mpls '" <mpls@UU.NET>
Subject: RE: Between OSPF RSVP... 
Date: Mon, 17 Mar 2003 09:07:30 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

 
Steve 

I ask a simple question or two. 
1. how detrimental could this be to our MPLS implementation and 
2. What should we do to mitigate the risk ?
Will

-----Original Message-----
From: Steve Yao
To: 'curtis@fictitious.org'
Cc: mpls
Sent: 3/14/03 12:51 PM
Subject: RE: Between OSPF RSVP... 



>Steve,
>
>In two messages prior you stated:
>
>> The RRO received at the HE only contains the IP addresses 
>that map to half
>> of the LSAs or LSPs that the LSP traversed. 
>
>You mentioned that only half the LSA/LSPDU were in the RRO, so the
>question "What cases were you thinking of?" that you just asked should
>be directed to you.

I asked the question since you mentioned earlier:

>It wasn't intended to cover all cases and does not depricate use of
>path-tear.  You still didn't answer my question.

But it is ok if you don't want to answer the question.

>
>Since you brought up the issue "where RRO may be too large" why don't
>you do the math and tell us 1) how big the RRO would have to be to be
>too large and 2) how likely you think that is of occurring.  RSVPd
>objects can be 64KB each.  The IPv4 address subobject is 8 bytes long,
>including type and length.  Add a label subobject (8 bytes) and fit it
>into a reasonable MTU and you're still at hundreds of hops.  I get
>200+ into a 4KB MTU and most networks seem to be going for 8K MTU so I
>get "not very likely" for question 2).
>
>Curtis
>

I agree that this is not very likely.

Steve
 <<ATT77972.txt>> 


From owner-mpls@UU.NET  Mon Mar 17 11:06:00 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18270
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 11:06:00 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogku02958
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 16:08:12 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogku02309;
	Mon, 17 Mar 2003 16:07:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogks18899
	for mpls-outgoing; Mon, 17 Mar 2003 15:41:56 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQogks18889
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 15:41:47 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQogks28827
	for <mpls@uu.net>; Mon, 17 Mar 2003 15:41:38 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogks17099
	for <mpls@uu.net>; Mon, 17 Mar 2003 15:41:37 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQogks17074
	for <mpls@uu.net>; Mon, 17 Mar 2003 15:41:37 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2HFfYSc008256
	for <mpls@uu.net>; Mon, 17 Mar 2003 10:41:34 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA28729 for <mpls@uu.net>; Mon, 17 Mar 2003 10:41:34 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2HFfXX00751 for mpls@uu.net; Mon, 17 Mar 2003 10:41:33 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQogks18668
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 15:39:27 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQogks26104
	for <mpls@UU.NET>; Mon, 17 Mar 2003 15:39:14 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogks19302
	for <mpls@UU.NET>; Mon, 17 Mar 2003 15:39:13 GMT
Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQogks19258
	for <mpls@UU.NET>; Mon, 17 Mar 2003 15:39:11 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id KAA30574;
	Mon, 17 Mar 2003 10:37:08 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303171537.KAA30574@workhorse.fictitious.org>
To: "Ferrell, William" <William.Ferrell@titan.com>
cc: "'Steve Yao '" <syao@chiaro.com>,
        "''curtis@fictitious.org' '" <curtis@fictitious.org>,
        "'mpls '" <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: Between OSPF RSVP... 
In-reply-to: Your message of "Mon, 17 Mar 2003 09:07:30 EST."
             <561621C69F17D511A3A20050047340EC01AAF610@VCMD-NT1> 
Date: Mon, 17 Mar 2003 10:37:08 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <561621C69F17D511A3A20050047340EC01AAF610@VCMD-NT1>, "Ferrell, Willi
am" writes:
>  
> Steve 
> 
> I ask a simple question or two. 
> 1. how detrimental could this be to our MPLS implementation and 
> 2. What should we do to mitigate the risk ?
> Will


Will,

What is "this" in your question?  If it partially filled RRO, we
determined it not occur except for certain conditions that are
entirely a matter of network design (such as interarea).  We also
concluded that even if the RRO was partially filled, the path-tear and
notify (if used) would handle tear down and initiate reroute.

Please be more specific in your question, if I haven't answered it.

Curtis



> -----Original Message-----
> From: Steve Yao
> To: 'curtis@fictitious.org'
> Cc: mpls
> Sent: 3/14/03 12:51 PM
> Subject: RE: Between OSPF RSVP... 
> 
> 
> 
> >Steve,
> >
> >In two messages prior you stated:
> >
> >> The RRO received at the HE only contains the IP addresses 
> >that map to half
> >> of the LSAs or LSPs that the LSP traversed. 
> >
> >You mentioned that only half the LSA/LSPDU were in the RRO, so the
> >question "What cases were you thinking of?" that you just asked should
> >be directed to you.
> 
> I asked the question since you mentioned earlier:
> 
> >It wasn't intended to cover all cases and does not depricate use of
> >path-tear.  You still didn't answer my question.
> 
> But it is ok if you don't want to answer the question.
> 
> >
> >Since you brought up the issue "where RRO may be too large" why don't
> >you do the math and tell us 1) how big the RRO would have to be to be
> >too large and 2) how likely you think that is of occurring.  RSVPd
> >objects can be 64KB each.  The IPv4 address subobject is 8 bytes long,
> >including type and length.  Add a label subobject (8 bytes) and fit it
> >into a reasonable MTU and you're still at hundreds of hops.  I get
> >200+ into a 4KB MTU and most networks seem to be going for 8K MTU so I
> >get "not very likely" for question 2).
> >
> >Curtis
> >
> 
> I agree that this is not very likely.
> 
> Steve
>  <<ATT77972.txt>> 
> 



From owner-mpls@UU.NET  Mon Mar 17 12:02:20 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20480
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 12:02:20 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogky28915
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 17:04:32 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogky28122;
	Mon, 17 Mar 2003 17:04:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogkw11518
	for mpls-outgoing; Mon, 17 Mar 2003 16:30:04 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQogkv11485
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 16:29:56 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQogkv08020
	for <mpls@UU.NET>; Mon, 17 Mar 2003 16:29:47 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogkv07597
	for <mpls@UU.NET>; Mon, 17 Mar 2003 16:29:47 GMT
Received: from atlntex01.movaz.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: exchange.movaz.com [65.205.166.141])
	id QQogkv07584
	for <mpls@UU.NET>; Mon, 17 Mar 2003 16:29:46 GMT
Received: from BLIULAPTOP ([172.16.8.184]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 17 Mar 2003 11:29:46 -0500
Message-ID: <000501c2eca2$7161ff20$b5828182@movaz.com>
From: "Adrian Farrel" <afarrel@movaz.com>
To: "'Jean Philippe Vasseur'" <jvasseur@cisco.com>,
        <raymond_zhang@infonet.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: draft-zhang-mpls-interas-te-req-02.txt
Date: Mon, 17 Mar 2003 03:10:29 -0500
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-OriginalArrivalTime: 17 Mar 2003 16:29:46.0315 (UTC) FILETIME=[6C2709B0:01C2ECA2]
Sender: owner-mpls@UU.NET
Precedence: bulk

JP, Raymond,

I appreciate this draft. Thanks.

Sections 5.5 and 5.10  Control of route diversity.
This is what we are trying to assist with
draft-lee-ccamp-rsvp-te-exclude-route-02.txt
Would welcome your opinions on whether our draft would help to meet your
requirements.

Section 5.7 Signaling and Path Computation
Should you mention crankback at this point?

Thanks,
Adrian





From owner-mpls@UU.NET  Mon Mar 17 12:02:56 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20497
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 12:02:55 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogky00026
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 17:05:08 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogky29145;
	Mon, 17 Mar 2003 17:04:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogkw11541
	for mpls-outgoing; Mon, 17 Mar 2003 16:30:36 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQogkw11528
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 16:30:31 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQogkv21401
	for <mpls@UU.NET>; Mon, 17 Mar 2003 16:29:48 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogkv00068
	for <mpls@UU.NET>; Mon, 17 Mar 2003 16:29:48 GMT
Received: from atlntex01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: exchange.movaz.com [65.205.166.141])
	id QQogkv00057
	for <mpls@UU.NET>; Mon, 17 Mar 2003 16:29:47 GMT
Received: from BLIULAPTOP ([172.16.8.184]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 17 Mar 2003 11:29:47 -0500
Message-ID: <000701c2eca2$721aeee0$b5828182@movaz.com>
From: "Adrian Farrel" <afarrel@movaz.com>
To: <mrn@gblx.net>, <denver@gblx.net>, <jpv@cisco.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: draft-meyer-soft-preemption-00.txt
Date: Mon, 17 Mar 2003 03:38:02 -0500
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-OriginalArrivalTime: 17 Mar 2003 16:29:47.0518 (UTC) FILETIME=[6CDE99E0:01C2ECA2]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

I support this concept, but I wonder why you do not use PathErr instead of Resv.
Why not just define a new Errcode/value for the PathErr to indicate preempted
but still in place?
Transit nodes (including backwards compatibility) will forward the PathErr but
not act on the LSP
The headend can treat the PathErr as you describe by performing
make-before-break.

Cheers,
Adrian





From owner-mpls@UU.NET  Mon Mar 17 12:17:58 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21075
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 12:17:58 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogkz10493
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 17:20:10 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogkz09894;
	Mon, 17 Mar 2003 17:19:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogkx13261
	for mpls-outgoing; Mon, 17 Mar 2003 16:50:45 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQogkx13240
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 16:50:28 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQogkx12605
	for <mpls@UU.NET>; Mon, 17 Mar 2003 16:50:09 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogkx08770
	for <mpls@UU.NET>; Mon, 17 Mar 2003 16:50:09 GMT
Received: from thurn.corp.titan.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: thurn.corp.titan.com [159.62.51.20])
	id QQogkx08747
	for <mpls@UU.NET>; Mon, 17 Mar 2003 16:50:08 GMT
Received: from vcmd-nt1.validity.com (val114-005.validity.titan.com [159.62.114.5])
	by thurn.corp.titan.com (8.12.8/8.12.8) with ESMTP id h2HGo1rF030281;
	Mon, 17 Mar 2003 08:50:03 -0800
Received: by VCMD-NT1 with Internet Mail Service (5.5.2655.55)
	id <HCMW775Q>; Mon, 17 Mar 2003 11:49:19 -0500
Message-ID: <561621C69F17D511A3A20050047340EC01AAF614@VCMD-NT1>
From: "Ferrell, William" <William.Ferrell@titan.com>
To: "'Curtis Villamizar '" <curtis@fictitious.org>,
        "Ferrell, William"
	 <William.Ferrell@titan.com>
Cc: "''Steve Yao ' '" <syao@chiaro.com>, "''mpls ' '" <mpls@UU.NET>
Subject: RE: Between OSPF RSVP... 
Date: Mon, 17 Mar 2003 11:49:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

 
Steve
Yes , you hit the nail on the head .. That was the "this"
In essence we're saying that risk is mititaged through effective design and
numeric improbability, right.
Will

-----Original Message-----
From: Curtis Villamizar
To: Ferrell, William
Cc: 'Steve Yao '; ''curtis@fictitious.org' '; 'mpls '
Sent: 3/17/03 10:37 AM
Subject: Re: Between OSPF RSVP... 


In message <561621C69F17D511A3A20050047340EC01AAF610@VCMD-NT1>,
"Ferrell, Willi
am" writes:
>  
> Steve 
> 
> I ask a simple question or two. 
> 1. how detrimental could this be to our MPLS implementation and 
> 2. What should we do to mitigate the risk ?
> Will


Will,

What is "this" in your question?  If it partially filled RRO, we
determined it not occur except for certain conditions that are
entirely a matter of network design (such as interarea).  We also
concluded that even if the RRO was partially filled, the path-tear and
notify (if used) would handle tear down and initiate reroute.

Please be more specific in your question, if I haven't answered it.

Curtis



> -----Original Message-----
> From: Steve Yao
> To: 'curtis@fictitious.org'
> Cc: mpls
> Sent: 3/14/03 12:51 PM
> Subject: RE: Between OSPF RSVP... 
> 
> 
> 
> >Steve,
> >
> >In two messages prior you stated:
> >
> >> The RRO received at the HE only contains the IP addresses 
> >that map to half
> >> of the LSAs or LSPs that the LSP traversed. 
> >
> >You mentioned that only half the LSA/LSPDU were in the RRO, so the
> >question "What cases were you thinking of?" that you just asked
should
> >be directed to you.
> 
> I asked the question since you mentioned earlier:
> 
> >It wasn't intended to cover all cases and does not depricate use of
> >path-tear.  You still didn't answer my question.
> 
> But it is ok if you don't want to answer the question.
> 
> >
> >Since you brought up the issue "where RRO may be too large" why don't
> >you do the math and tell us 1) how big the RRO would have to be to be
> >too large and 2) how likely you think that is of occurring.  RSVPd
> >objects can be 64KB each.  The IPv4 address subobject is 8 bytes
long,
> >including type and length.  Add a label subobject (8 bytes) and fit
it
> >into a reasonable MTU and you're still at hundreds of hops.  I get
> >200+ into a 4KB MTU and most networks seem to be going for 8K MTU so
I
> >get "not very likely" for question 2).
> >
> >Curtis
> >
> 
> I agree that this is not very likely.
> 
> Steve
>  <<ATT77972.txt>> 
> 


From owner-mpls@UU.NET  Mon Mar 17 12:42:43 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22087
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 12:42:43 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogla26259
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 17:44:56 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogla25889;
	Mon, 17 Mar 2003 17:44:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogkz04176
	for mpls-outgoing; Mon, 17 Mar 2003 17:19:09 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQogkz04165
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 17:19:02 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQogkz12982
	for <mpls@UU.NET>; Mon, 17 Mar 2003 17:18:24 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogkz08714
	for <mpls@UU.NET>; Mon, 17 Mar 2003 17:18:23 GMT
Received: from rchss002.chiaro.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: rchss002.chiaro.com [63.88.196.82])
	id QQogkz08684
	for <mpls@UU.NET>; Mon, 17 Mar 2003 17:18:22 GMT
Received: (qmail 10312 invoked from network); 17 Mar 2003 17:10:30 -0000
Received: from rchss002.chiaro.com (HELO mail.chiaro.com) (63.88.196.82)
  by rchss002.chiaro.com with SMTP; 17 Mar 2003 17:10:30 -0000
Received: by MAIL with Internet Mail Service (5.5.2653.19)
	id <GT079TJ8>; Mon, 17 Mar 2003 11:17:38 -0600
Message-ID: <F69EB380D594D611BBEA00065B3F14B4A35269@MAIL>
From: Steve Yao <syao@chiaro.com>
To: "'Ferrell, William'" <William.Ferrell@titan.com>,
        "'Curtis Villamizar '"
	 <curtis@fictitious.org>
Cc: Steve Yao <syao@chiaro.com>, "''mpls ' '" <mpls@UU.NET>
Subject: RE: Between OSPF RSVP... 
Date: Mon, 17 Mar 2003 11:17:37 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/mixed; boundary="=_IS_MIME_Boundary"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=_IS_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Will,

Whether an RRO can fit into a Path/Resv message is dependent on a
combination of various factors including, for example, large private
objects. However, at this point, it appears that the likelihood of such a
scenario is low.

Steve


>-----Original Message-----
>From: Ferrell, William [mailto:William.Ferrell@titan.com]
>Sent: Monday, March 17, 2003 10:49 AM
>To: 'Curtis Villamizar '; Ferrell, William
>Cc: ''Steve Yao ' '; ''mpls ' '
>Subject: RE: Between OSPF RSVP... 
>
>
> 
>Steve
>Yes , you hit the nail on the head .. That was the "this"
>In essence we're saying that risk is mititaged through 
>effective design and
>numeric improbability, right.
>Will
>
>-----Original Message-----
>From: Curtis Villamizar
>To: Ferrell, William
>Cc: 'Steve Yao '; ''curtis@fictitious.org' '; 'mpls '
>Sent: 3/17/03 10:37 AM
>Subject: Re: Between OSPF RSVP... 
>
>
>In message <561621C69F17D511A3A20050047340EC01AAF610@VCMD-NT1>,
>"Ferrell, Willi
>am" writes:
>>  
>> Steve 
>> 
>> I ask a simple question or two. 
>> 1. how detrimental could this be to our MPLS implementation and 
>> 2. What should we do to mitigate the risk ?
>> Will
>
>
>Will,
>
>What is "this" in your question?  If it partially filled RRO, we
>determined it not occur except for certain conditions that are
>entirely a matter of network design (such as interarea).  We also
>concluded that even if the RRO was partially filled, the path-tear and
>notify (if used) would handle tear down and initiate reroute.
>
>Please be more specific in your question, if I haven't answered it.
>
>Curtis
>
>
>
>> -----Original Message-----
>> From: Steve Yao
>> To: 'curtis@fictitious.org'
>> Cc: mpls
>> Sent: 3/14/03 12:51 PM
>> Subject: RE: Between OSPF RSVP... 
>> 
>> 
>> 
>> >Steve,
>> >
>> >In two messages prior you stated:
>> >
>> >> The RRO received at the HE only contains the IP addresses 
>> >that map to half
>> >> of the LSAs or LSPs that the LSP traversed. 
>> >
>> >You mentioned that only half the LSA/LSPDU were in the RRO, so the
>> >question "What cases were you thinking of?" that you just asked
>should
>> >be directed to you.
>> 
>> I asked the question since you mentioned earlier:
>> 
>> >It wasn't intended to cover all cases and does not depricate use of
>> >path-tear.  You still didn't answer my question.
>> 
>> But it is ok if you don't want to answer the question.
>> 
>> >
>> >Since you brought up the issue "where RRO may be too large" 
>why don't
>> >you do the math and tell us 1) how big the RRO would have 
>to be to be
>> >too large and 2) how likely you think that is of occurring.  RSVPd
>> >objects can be 64KB each.  The IPv4 address subobject is 8 bytes
>long,
>> >including type and length.  Add a label subobject (8 bytes) and fit
>it
>> >into a reasonable MTU and you're still at hundreds of hops.  I get
>> >200+ into a 4KB MTU and most networks seem to be going for 8K MTU so
>I
>> >get "not very likely" for question 2).
>> >
>> >Curtis
>> >
>> 
>> I agree that this is not very likely.
>> 
>> Steve
>>  <<ATT77972.txt>> 
>> 
>
--=_IS_MIME_Boundary
Content-Type: text/plain;charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

----------------------------------------- (on Chiaro SMTP Relay)

This e-mail and any files transmitted with it are the property
of Chiaro Networks, Ltd., and may contain confidential and 
privileged material for the sole use of the intended recipient(s)
to whom this e-mail is addressed. If you are not one of the named
recipient(s), or otherwise have reason to believe that you have 
received this message in error, please notify the sender and 
delete all copies from your system.  Any other use, retention, 
dissemination, forwarding, printing or copying of this e-mail is 
strictly prohibited.


---------------------------------------------------------

--=_IS_MIME_Boundary--


From owner-mpls@UU.NET  Mon Mar 17 13:16:02 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23293
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 13:16:02 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogld29619
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 18:18:15 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogld29088;
	Mon, 17 Mar 2003 18:18:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoglb06386
	for mpls-outgoing; Mon, 17 Mar 2003 17:50:40 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoglb06381
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 17:50:39 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoglb18377
	for <mpls@uu.net>; Mon, 17 Mar 2003 17:50:06 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoglb02737
	for <mpls@uu.net>; Mon, 17 Mar 2003 17:50:06 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoglb02728
	for <mpls@uu.net>; Mon, 17 Mar 2003 17:50:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2HHo3vD029944
	for <mpls@uu.net>; Mon, 17 Mar 2003 12:50:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA09369 for <mpls@uu.net>; Mon, 17 Mar 2003 12:50:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2HHo2p11563 for mpls@uu.net; Mon, 17 Mar 2003 12:50:02 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoglb06327
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 17:48:45 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoglb09370
	for <mpls@UU.NET>; Mon, 17 Mar 2003 17:48:15 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoglb03558
	for <mpls@UU.NET>; Mon, 17 Mar 2003 17:48:14 GMT
Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoglb03519
	for <mpls@UU.NET>; Mon, 17 Mar 2003 17:48:13 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA31250;
	Mon, 17 Mar 2003 12:46:22 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303171746.MAA31250@workhorse.fictitious.org>
To: "Ferrell, William" <William.Ferrell@titan.com>
cc: "'Curtis Villamizar '" <curtis@fictitious.org>,
        "''Steve Yao ' '" <syao@chiaro.com>, "''mpls ' '" <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: Between OSPF RSVP... 
In-reply-to: Your message of "Mon, 17 Mar 2003 11:49:18 EST."
             <561621C69F17D511A3A20050047340EC01AAF614@VCMD-NT1> 
Date: Mon, 17 Mar 2003 12:46:22 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <561621C69F17D511A3A20050047340EC01AAF614@VCMD-NT1>, "Ferrell, Willi
am" writes:
>  
> Steve
> Yes , you hit the nail on the head .. That was the "this"
> In essence we're saying that risk is mititaged through effective design and
> numeric improbability, right.
> Will


More accurately, if the risk an incomplete RRO the is complete
eliminated by using implementations that are not broken and avoiding
certain network designs.  If the risk is not having the tear down
occur in one of those network designs (ie: inter-area LSPs without
hierarchical LSPs, or where an ABR goes down or is isolated from one
area), then path-tear and directed notify provide an alternate means
to notify the ingress that a reroute is needed.  Path-tear and
directed notify suffer performance degredation if a single path-tear
or notify packet is lost but preferred treatment of control traffic
should solve this.

All problems that have been discussed so far are solved problems.

Curtis


> -----Original Message-----
> From: Curtis Villamizar
> To: Ferrell, William
> Cc: 'Steve Yao '; ''curtis@fictitious.org' '; 'mpls '
> Sent: 3/17/03 10:37 AM
> Subject: Re: Between OSPF RSVP... 
> 
> 
> In message <561621C69F17D511A3A20050047340EC01AAF610@VCMD-NT1>,
> "Ferrell, Willi
> am" writes:
> >  
> > Steve 
> > 
> > I ask a simple question or two. 
> > 1. how detrimental could this be to our MPLS implementation and 
> > 2. What should we do to mitigate the risk ?
> > Will
> 
> 
> Will,
> 
> What is "this" in your question?  If it partially filled RRO, we
> determined it not occur except for certain conditions that are
> entirely a matter of network design (such as interarea).  We also
> concluded that even if the RRO was partially filled, the path-tear and
> notify (if used) would handle tear down and initiate reroute.
> 
> Please be more specific in your question, if I haven't answered it.
> 
> Curtis
> 
> 
> 
> > -----Original Message-----
> > From: Steve Yao
> > To: 'curtis@fictitious.org'
> > Cc: mpls
> > Sent: 3/14/03 12:51 PM
> > Subject: RE: Between OSPF RSVP... 
> > 
> > 
> > 
> > >Steve,
> > >
> > >In two messages prior you stated:
> > >
> > >> The RRO received at the HE only contains the IP addresses 
> > >that map to half
> > >> of the LSAs or LSPs that the LSP traversed. 
> > >
> > >You mentioned that only half the LSA/LSPDU were in the RRO, so the
> > >question "What cases were you thinking of?" that you just asked
> should
> > >be directed to you.
> > 
> > I asked the question since you mentioned earlier:
> > 
> > >It wasn't intended to cover all cases and does not depricate use of
> > >path-tear.  You still didn't answer my question.
> > 
> > But it is ok if you don't want to answer the question.
> > 
> > >
> > >Since you brought up the issue "where RRO may be too large" why don't
> > >you do the math and tell us 1) how big the RRO would have to be to be
> > >too large and 2) how likely you think that is of occurring.  RSVPd
> > >objects can be 64KB each.  The IPv4 address subobject is 8 bytes
> long,
> > >including type and length.  Add a label subobject (8 bytes) and fit
> it
> > >into a reasonable MTU and you're still at hundreds of hops.  I get
> > >200+ into a 4KB MTU and most networks seem to be going for 8K MTU so
> I
> > >get "not very likely" for question 2).
> > >
> > >Curtis
> > >
> > 
> > I agree that this is not very likely.
> > 
> > Steve
> >  <<ATT77972.txt>> 
> > 
> 



From owner-mpls@UU.NET  Mon Mar 17 13:42:30 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24419
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 13:42:30 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogle07003
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 18:44:43 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogle06355;
	Mon, 17 Mar 2003 18:44:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoglc25931
	for mpls-outgoing; Mon, 17 Mar 2003 18:09:00 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoglc25911
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 18:08:58 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoglc12511
	for <mpls@uu.net>; Mon, 17 Mar 2003 18:08:43 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoglc28129
	for <mpls@uu.net>; Mon, 17 Mar 2003 18:08:42 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoglc28109
	for <mpls@uu.net>; Mon, 17 Mar 2003 18:08:41 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2HI8dvD001639
	for <mpls@uu.net>; Mon, 17 Mar 2003 13:08:39 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA10880 for <mpls@uu.net>; Mon, 17 Mar 2003 13:08:38 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2HI8ca13786 for mpls@uu.net; Mon, 17 Mar 2003 13:08:38 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoglc24837
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 18:05:36 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoglc22986
	for <mpls@UU.NET>; Mon, 17 Mar 2003 18:04:10 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoglc29904
	for <mpls@UU.NET>; Mon, 17 Mar 2003 18:04:09 GMT
Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoglc29871
	for <mpls@UU.NET>; Mon, 17 Mar 2003 18:04:09 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id NAA31309;
	Mon, 17 Mar 2003 13:01:16 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303171801.NAA31309@workhorse.fictitious.org>
To: "Adrian Farrel" <afarrel@movaz.com>
cc: mrn@gblx.net, denver@gblx.net, jpv@cisco.com,
        "'mpls@uu.net'" <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: draft-meyer-soft-preemption-00.txt 
In-reply-to: Your message of "Mon, 17 Mar 2003 03:38:02 EST."
             <000701c2eca2$721aeee0$b5828182@movaz.com> 
Date: Mon, 17 Mar 2003 13:01:16 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <000701c2eca2$721aeee0$b5828182@movaz.com>, "Adrian Farrel" writes:
>  
> Hi,
>  
> I support this concept, but I wonder why you do not use PathErr
> instead of Resv .  Why not just define a new Errcode/value for the
> PathErr to indicate preempted but still in place?  Transit nodes
> (including backwards compatibility) will forward the PathErr but not
> act on the LSP The headend can treat the PathErr as you describe by
> performing make-before-break.
>  
> Cheers,
> Adrian


The current semantics of path-err or path-tear is to indicate an error
in setup or to tear down.  Any intermediate node that didn' understand
this would release resources and cause traffic to black hole, exactly
what the soft preempt is trying to avoid.

The soft preempt is an advisory from a midpoint to the ingress that
while an LSP is up, its resource reservation cannot be maintained and
it must be voluntarily rerouted or face tear down.  A bit in the
normal resv is a better way to express this than one of the error or
explicit tear down mechanisms.

Also, any midpoint that recieves this and then has to do a preempt can
prefer to soft preempt an already soft preempted LSP over one that has
not yet been preempted.  This would be quite common during the
reaction to a link failure, if the rerouting of preferred LSPs caused
less preferred LSPs to be preempted.

Curtis



From owner-mpls@UU.NET  Mon Mar 17 13:56:58 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24927
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 13:56:57 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoglf14976
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 18:59:10 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoglf14276;
	Mon, 17 Mar 2003 18:58:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogld27794
	for mpls-outgoing; Mon, 17 Mar 2003 18:23:50 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQogld27785
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 18:23:34 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQogld11543
	for <mpls@UU.NET>; Mon, 17 Mar 2003 18:23:20 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogld07733
	for <mpls@UU.NET>; Mon, 17 Mar 2003 18:23:17 GMT
Received: from atlntex01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: exchange.movaz.com [65.205.166.141])
	id QQogld07718
	for <mpls@UU.NET>; Mon, 17 Mar 2003 18:23:17 GMT
Received: from BLIULAPTOP ([172.16.8.184]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 17 Mar 2003 13:23:16 -0500
Message-ID: <007901c2ecb2$4c9b3890$b5828182@movaz.com>
From: "Adrian Farrel" <afarrel@movaz.com>
To: <curtis@fictitious.org>
Cc: <mrn@gblx.net>, <denver@gblx.net>, <jpv@cisco.com>,
        "'mpls@uu.net'" <mpls@UU.NET>
References: <200303171801.NAA31309@workhorse.fictitious.org>
Subject: Re: draft-meyer-soft-preemption-00.txt 
Date: Mon, 17 Mar 2003 13:23:24 -0500
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-OriginalArrivalTime: 17 Mar 2003 18:23:16.0817 (UTC) FILETIME=[47872C10:01C2ECB2]
Sender: owner-mpls@UU.NET
Precedence: bulk

Curtis,

> The current semantics of path-err or path-tear is to indicate an error
> in setup or to tear down.  Any intermediate node that didn' understand
> this would release resources and cause traffic to black hole, exactly
> what the soft preempt is trying to avoid.

Interesting, but I don't believe this is the semantics of a PathErr. In fact,
quite to the contrary. This is why RFC3473 introduces the Path_state_removed
flag.

To quote from RFC3473 section 4.4
   The PathErr message as defined in [RFC2205] is sent hop-by-hop to the
   source of the associated Path message.  Intermediate nodes may
   inspect this message, but take no [sic] action upon it.

That is: the existing PathErr preemption scheme is *already* soft with two
exceptions...
- the preempting node currently releases the resources of the LSP
   (this is local behavior and can be modified by implementations)
- the ingress node currently sends PathTear
   (this is local behavior and can be modified by implementations)

We might want to add further local behavior to "allow" a transit node to inspect
and act on a preemption PathErr.

None of these changes speak to the need for a signaling change, but it might be
useful to indicate how the preempting node has behaved.

> The soft preempt is an advisory from a midpoint to the ingress that
> while an LSP is up, its resource reservation cannot be maintained and
> it must be voluntarily rerouted or face tear down.  A bit in the
> normal resv is a better way to express this than one of the error or
> explicit tear down mechanisms.

I disagree as above because PathErr is not an explicit tear down mechanism.

> Also, any midpoint that recieves this and then has to do a preempt can
> prefer to soft preempt an already soft preempted LSP over one that has
> not yet been preempted.  This would be quite common during the
> reaction to a link failure, if the rerouting of preferred LSPs caused
> less preferred LSPs to be preempted.

I believe this is facilitated equally by a PathErr.

Thanks,
Adrian




From owner-mpls@UU.NET  Mon Mar 17 13:57:21 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24952
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 13:57:20 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoglf15654
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 18:59:33 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoglf15160;
	Mon, 17 Mar 2003 18:59:15 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogld27864
	for mpls-outgoing; Mon, 17 Mar 2003 18:24:40 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQogld27851
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 18:24:30 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQogld06141
	for <mpls@uu.net>; Mon, 17 Mar 2003 18:24:16 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogld25056
	for <mpls@uu.net>; Mon, 17 Mar 2003 18:24:15 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQogld25041
	for <mpls@uu.net>; Mon, 17 Mar 2003 18:24:15 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2HIOCvD002955
	for <mpls@uu.net>; Mon, 17 Mar 2003 13:24:13 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA12090 for <mpls@uu.net>; Mon, 17 Mar 2003 13:24:11 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2HIOBq16390 for mpls@uu.net; Mon, 17 Mar 2003 13:24:11 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQogld27706
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 18:22:34 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQogld27577
	for <mpls@UU.NET>; Mon, 17 Mar 2003 18:22:05 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogld21724
	for <mpls@UU.NET>; Mon, 17 Mar 2003 18:22:04 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQogld21678
	for <mpls@UU.NET>; Mon, 17 Mar 2003 18:22:03 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2HILtvD002761;
	Mon, 17 Mar 2003 13:21:55 -0500 (EST)
Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA11941; Mon, 17 Mar 2003 13:21:54 -0500 (EST)
Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id NAA22711; Mon, 17 Mar 2003 13:21:54 -0500 (EST)
Message-Id: <200303171821.NAA22711@bifocal.cisco.com>
X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs
To: "Adrian Farrel" <afarrel@movaz.com>
cc: mrn@gblx.net, denver@gblx.net, jpv@cisco.com,
        "'mpls@uu.net'" <mpls@UU.NET>, swallow@cisco.com
Subject: Re: draft-meyer-soft-preemption-00.txt 
In-reply-to: Your message of "Mon, 17 Mar 2003 03:38:02 EST."
             <000701c2eca2$721aeee0$b5828182@movaz.com> 
Date: Mon, 17 Mar 2003 13:21:54 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

> I support this concept, but I wonder why you do not use PathErr instead of Resv.
> Why not just define a new Errcode/value for the PathErr to indicate preempted
> but still in place?
> Transit nodes (including backwards compatibility) will forward the PathErr but
> not act on the LSP
> The headend can treat the PathErr as you describe by performing
> make-before-break.

There is one difference.  In 2205 the RESV is sent reliably
(periodically refreshed) and the PathErr is one shot.  However if
you're using 2961, this argument goes away.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824



From owner-mpls@UU.NET  Mon Mar 17 14:53:03 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27359
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 14:53:02 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoglj26768
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 19:55:15 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoglj25951;
	Mon, 17 Mar 2003 19:54:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoglh21937
	for mpls-outgoing; Mon, 17 Mar 2003 19:29:30 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoglh21930
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 19:29:18 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoglh04388
	for <mpls@uu.net>; Mon, 17 Mar 2003 19:29:06 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoglh06722
	for <mpls@uu.net>; Mon, 17 Mar 2003 19:29:05 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoglh06695
	for <mpls@uu.net>; Mon, 17 Mar 2003 19:29:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2HJT2vD009021
	for <mpls@uu.net>; Mon, 17 Mar 2003 14:29:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA17891 for <mpls@uu.net>; Mon, 17 Mar 2003 14:29:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2HJT1524417 for mpls@uu.net; Mon, 17 Mar 2003 14:29:01 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoglh21611
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 19:23:30 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoglh09758
	for <mpls@UU.NET>; Mon, 17 Mar 2003 19:22:05 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoglh25328
	for <mpls@UU.NET>; Mon, 17 Mar 2003 19:22:04 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoglh25228
	for <mpls@UU.NET>; Mon, 17 Mar 2003 19:22:02 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2HJLkvD008387;
	Mon, 17 Mar 2003 14:21:47 -0500 (EST)
Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA17293; Mon, 17 Mar 2003 14:21:46 -0500 (EST)
Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA23501; Mon, 17 Mar 2003 14:21:46 -0500 (EST)
Message-Id: <200303171921.OAA23501@bifocal.cisco.com>
X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs
To: curtis@fictitious.org
cc: "Adrian Farrel" <afarrel@movaz.com>, mrn@gblx.net, denver@gblx.net,
        jpv@cisco.com, "'mpls@uu.net'" <mpls@UU.NET>, swallow@cisco.com
Subject: Re: draft-meyer-soft-preemption-00.txt 
In-reply-to: Your message of "Mon, 17 Mar 2003 13:01:16 EST."
             <200303171801.NAA31309@workhorse.fictitious.org> 
Date: Mon, 17 Mar 2003 14:21:46 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Curtis -

> The current semantics of path-err or path-tear is to indicate an error
> in setup or to tear down.  Any intermediate node that didn' understand
> this would release resources and cause traffic to black hole, exactly
> what the soft preempt is trying to avoid.

If that were true for path-err, why does path-err have an in-place bit
to express that the reservation is still there?

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824



From owner-mpls@UU.NET  Mon Mar 17 15:32:07 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00186
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 15:32:07 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoglm20623
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 20:34:21 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoglm20322;
	Mon, 17 Mar 2003 20:34:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoglk05008
	for mpls-outgoing; Mon, 17 Mar 2003 20:02:10 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoglk04937
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 20:02:03 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoglk17737
	for <mpls@UU.NET>; Mon, 17 Mar 2003 20:01:41 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoglk15001
	for <mpls@UU.NET>; Mon, 17 Mar 2003 20:01:41 GMT
Received: from rchss002.chiaro.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: rchss002.chiaro.com [63.88.196.82])
	id QQoglk14987
	for <mpls@UU.NET>; Mon, 17 Mar 2003 20:01:40 GMT
Received: (qmail 794 invoked from network); 17 Mar 2003 19:53:48 -0000
Received: from rchss002.chiaro.com (HELO mail.chiaro.com) (63.88.196.82)
  by rchss002.chiaro.com with SMTP; 17 Mar 2003 19:53:48 -0000
Received: by MAIL with Internet Mail Service (5.5.2653.19)
	id <GT079TX0>; Mon, 17 Mar 2003 14:00:52 -0600
Message-ID: <F69EB380D594D611BBEA00065B3F14B4A3526A@MAIL>
From: Steve Yao <syao@chiaro.com>
To: "'George Swallow'" <swallow@cisco.com>, curtis@fictitious.org
Cc: Adrian Farrel <afarrel@movaz.com>, mrn@gblx.net, denver@gblx.net,
        jpv@cisco.com, "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: draft-meyer-soft-preemption-00.txt 
Date: Mon, 17 Mar 2003 14:00:52 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/mixed; boundary="=_IS_MIME_Boundary"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=_IS_MIME_Boundary
Content-Type: text/plain;
	charset="iso-8859-1"


>If that were true for path-err, why does path-err have an in-place bit
>to express that the reservation is still there?
>
>...George
>

George,

It's said in 2205 A.5 that this flag value is only used in a ResvErr
message. Has that been changed?

Steve
--=_IS_MIME_Boundary
Content-Type: text/plain;charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

----------------------------------------- (on Chiaro SMTP Relay)

This e-mail and any files transmitted with it are the property
of Chiaro Networks, Ltd., and may contain confidential and 
privileged material for the sole use of the intended recipient(s)
to whom this e-mail is addressed. If you are not one of the named
recipient(s), or otherwise have reason to believe that you have 
received this message in error, please notify the sender and 
delete all copies from your system.  Any other use, retention, 
dissemination, forwarding, printing or copying of this e-mail is 
strictly prohibited.


---------------------------------------------------------

--=_IS_MIME_Boundary--


From owner-mpls@UU.NET  Mon Mar 17 15:52:41 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00775
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 15:52:40 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogln29410
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 20:54:54 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogln29086;
	Mon, 17 Mar 2003 20:54:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogll14599
	for mpls-outgoing; Mon, 17 Mar 2003 20:17:19 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQogll14594
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 20:17:15 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQogll28880
	for <mpls@uu.net>; Mon, 17 Mar 2003 20:15:22 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogll25371
	for <mpls@uu.net>; Mon, 17 Mar 2003 20:15:19 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQogll24878
	for <mpls@uu.net>; Mon, 17 Mar 2003 20:15:07 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2HKF4Sc029484
	for <mpls@uu.net>; Mon, 17 Mar 2003 15:15:04 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA21981 for <mpls@uu.net>; Mon, 17 Mar 2003 15:15:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2HKF3V29315 for mpls@uu.net; Mon, 17 Mar 2003 15:15:03 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoglk14061
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 20:13:44 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoglk21364
	for <mpls@UU.NET>; Mon, 17 Mar 2003 20:12:58 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoglk00492
	for <mpls@UU.NET>; Mon, 17 Mar 2003 20:12:57 GMT
Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoglk00460
	for <mpls@UU.NET>; Mon, 17 Mar 2003 20:12:56 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA32522;
	Mon, 17 Mar 2003 15:10:05 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303172010.PAA32522@workhorse.fictitious.org>
To: George Swallow <swallow@cisco.com>
cc: curtis@fictitious.org, "Adrian Farrel" <afarrel@movaz.com>, mrn@gblx.net,
        denver@gblx.net, jpv@cisco.com, "'mpls@uu.net'" <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: draft-meyer-soft-preemption-00.txt 
In-reply-to: Your message of "Mon, 17 Mar 2003 14:21:46 EST."
             <200303171921.OAA23501@bifocal.cisco.com> 
Date: Mon, 17 Mar 2003 15:10:05 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <200303171921.OAA23501@bifocal.cisco.com>, George Swallow writes:
> Curtis -
> 
> > The current semantics of path-err or path-tear is to indicate an error
> > in setup or to tear down.  Any intermediate node that didn' understand
> > this would release resources and cause traffic to black hole, exactly
> > what the soft preempt is trying to avoid.
> 
> If that were true for path-err, why does path-err have an in-place bit
> to express that the reservation is still there?
> 
> ...George


Expect that a certain implementation that we need to take into
consideration tears down if it doesn't understand the error code.

It also gets upset if it doesn't understand bits in the 'RRO IPv4/IPv6
Sub-Object Flags' or 'SESSION-ATTRIBUTES Flag' so that doesn't help
with either RRO flags or path-err.  At least the SESSION-ATTRIBUTES
flag will yield a path-err on the initial setup and the ingress can
fall back to a setup with no soft-preempt requested.

If the ingress doesn't understand soft-preempt, no sense sending it,
since it just delays the inevitable preempt.  If the midpoints will
tear down immediately due to an unknown error code or an unknown RRO
flag bit, its good to know that too.

The preference for the RRO flag is that like the protect-inuse, the
ingress knows which hops it does not have resources on.  Consider the
path A-B-C-...Z.  If hops D-E and G-H have preempted, but all of the
hops are near 100% utilized, the ingress knows it can share bandwidth
with its prior LSP on all hops for which the RRO flag bit is not set.
Its harder to do that with a collection of path-err messages.

Also, I haven't mentioned to the list, but if you put the preempted
bit back in the PATH ERO, others downstream of the initial
soft-preempt can soft-preempt the same LSP during the time that it
reroutes.  If we are looking for sub-second convergence plus
soft-preempt, this could be a very valuable feature.  The bit change
in the ERO is purely advisory and requires no change in resource
allocation so it can be propogated very quickly, much more quickly
than CSPF plus path setup.

Another reason to put this in the RRO is if FRR is used, the LSP is
both soft-preempted and protect-inuse must be set.  It is better to
set two bits in the RRO rather than send two separate messages.  If
the backup got preempted, then soft-preempt set and local-protect
available cleared would have a higher sense of urgency than
soft-preempt set and local-protect inuse being set.

I've given a few advantages of putting this in RRO.  What are the
technical advantages of putting this in path-err?

Curtis



From owner-mpls@UU.NET  Mon Mar 17 15:56:29 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00900
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 15:56:29 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogln01290
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 20:58:43 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogln00127;
	Mon, 17 Mar 2003 20:58:15 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogll14822
	for mpls-outgoing; Mon, 17 Mar 2003 20:21:35 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQogll14809
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 20:21:27 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQogll18000
	for <mpls@uu.net>; Mon, 17 Mar 2003 20:20:10 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogll13863
	for <mpls@uu.net>; Mon, 17 Mar 2003 20:20:08 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQogll13807
	for <mpls@uu.net>; Mon, 17 Mar 2003 20:20:07 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2HKK4vD013494
	for <mpls@uu.net>; Mon, 17 Mar 2003 15:20:04 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA22357 for <mpls@uu.net>; Mon, 17 Mar 2003 15:20:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2HKK3929741 for mpls@uu.net; Mon, 17 Mar 2003 15:20:03 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQogll14680
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 20:18:43 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQogll16873
	for <mpls@UU.NET>; Mon, 17 Mar 2003 20:18:37 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogll11210
	for <mpls@UU.NET>; Mon, 17 Mar 2003 20:18:36 GMT
Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQogll11184
	for <mpls@UU.NET>; Mon, 17 Mar 2003 20:18:35 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA32555;
	Mon, 17 Mar 2003 15:16:32 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303172016.PAA32555@workhorse.fictitious.org>
To: George Swallow <swallow@cisco.com>
cc: "Adrian Farrel" <afarrel@movaz.com>, mrn@gblx.net, denver@gblx.net,
        jpv@cisco.com, "'mpls@uu.net'" <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: draft-meyer-soft-preemption-00.txt 
In-reply-to: Your message of "Mon, 17 Mar 2003 13:21:54 EST."
             <200303171821.NAA22711@bifocal.cisco.com> 
Date: Mon, 17 Mar 2003 15:16:32 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <200303171821.NAA22711@bifocal.cisco.com>, George Swallow writes:
> > I support this concept, but I wonder why you do not use PathErr instead of 
> Resv.
> > Why not just define a new Errcode/value for the PathErr to indicate preempt
> ed
> > but still in place?
> > Transit nodes (including backwards compatibility) will forward the PathErr 
> but
> > not act on the LSP
> > The headend can treat the PathErr as you describe by performing
> > make-before-break.
> 
> There is one difference.  In 2205 the RESV is sent reliably
> (periodically refreshed) and the PathErr is one shot.  However if
> you're using 2961, this argument goes away.
> 
> ...George


In 2961, all it says about path-err is "PathErr and ResvErr messages
SHOULD be treated as implicit acknowledgments".  They are still one
shots.

If anything, if drops do occur, fast RESV propogation is more likely
with RFC2961 but path-err reliability is not improved.

Curtis



From owner-mpls@UU.NET  Mon Mar 17 16:11:36 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01418
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 16:11:36 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoglo28920
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 21:13:50 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoglo28668;
	Mon, 17 Mar 2003 21:13:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoglm16409
	for mpls-outgoing; Mon, 17 Mar 2003 20:39:56 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoglm16395
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 20:39:51 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoglm19843
	for <mpls@UU.NET>; Mon, 17 Mar 2003 20:39:01 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoglm27527
	for <mpls@UU.NET>; Mon, 17 Mar 2003 20:39:00 GMT
Received: from thurn.corp.titan.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: thurn.corp.titan.com [159.62.51.20])
	id QQoglm27499
	for <mpls@UU.NET>; Mon, 17 Mar 2003 20:39:00 GMT
Received: from vcmd-nt1.validity.com (val114-005.validity.titan.com [159.62.114.5])
	by thurn.corp.titan.com (8.12.8/8.12.8) with ESMTP id h2HKcorF015763;
	Mon, 17 Mar 2003 12:38:51 -0800
Received: by VCMD-NT1 with Internet Mail Service (5.5.2655.55)
	id <HCMW783H>; Mon, 17 Mar 2003 15:38:08 -0500
Message-ID: <561621C69F17D511A3A20050047340EC01AAF61B@VCMD-NT1>
From: "Ferrell, William" <William.Ferrell@titan.com>
To: "'Steve Yao '" <syao@chiaro.com>,
        "Ferrell, William"
	 <William.Ferrell@titan.com>,
        "''Curtis Villamizar ' '"
	 <curtis@fictitious.org>
Cc: "'''mpls ' ' '" <mpls@UU.NET>
Subject: RE: Between OSPF RSVP... 
Date: Mon, 17 Mar 2003 15:38:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

 
Steve 
Thanx, I tend to look at matters from a pesimistic perspective at times. My
questions are rarely about the operational likelihood and randomly
accidental factors(unless mis-configuration comes into view) but often I
focus on the malicious and intentional. Then the questions turn to loss
factor and mitigation.
Sorry for bugging you guys . 

Will


-----Original Message-----
From: Steve Yao
To: 'Ferrell, William'; 'Curtis Villamizar '
Cc: Steve Yao; ''mpls ' '
Sent: 3/17/03 12:17 PM
Subject: RE: Between OSPF RSVP... 

Hi Will,

Whether an RRO can fit into a Path/Resv message is dependent on a
combination of various factors including, for example, large private
objects. However, at this point, it appears that the likelihood of such
a
scenario is low.

Steve


>-----Original Message-----
>From: Ferrell, William [mailto:William.Ferrell@titan.com]
>Sent: Monday, March 17, 2003 10:49 AM
>To: 'Curtis Villamizar '; Ferrell, William
>Cc: ''Steve Yao ' '; ''mpls ' '
>Subject: RE: Between OSPF RSVP... 
>
>
> 
>Steve
>Yes , you hit the nail on the head .. That was the "this"
>In essence we're saying that risk is mititaged through 
>effective design and
>numeric improbability, right.
>Will
>
>-----Original Message-----
>From: Curtis Villamizar
>To: Ferrell, William
>Cc: 'Steve Yao '; ''curtis@fictitious.org' '; 'mpls '
>Sent: 3/17/03 10:37 AM
>Subject: Re: Between OSPF RSVP... 
>
>
>In message <561621C69F17D511A3A20050047340EC01AAF610@VCMD-NT1>,
>"Ferrell, Willi
>am" writes:
>>  
>> Steve 
>> 
>> I ask a simple question or two. 
>> 1. how detrimental could this be to our MPLS implementation and 
>> 2. What should we do to mitigate the risk ?
>> Will
>
>
>Will,
>
>What is "this" in your question?  If it partially filled RRO, we
>determined it not occur except for certain conditions that are
>entirely a matter of network design (such as interarea).  We also
>concluded that even if the RRO was partially filled, the path-tear and
>notify (if used) would handle tear down and initiate reroute.
>
>Please be more specific in your question, if I haven't answered it.
>
>Curtis
>
>
>
>> -----Original Message-----
>> From: Steve Yao
>> To: 'curtis@fictitious.org'
>> Cc: mpls
>> Sent: 3/14/03 12:51 PM
>> Subject: RE: Between OSPF RSVP... 
>> 
>> 
>> 
>> >Steve,
>> >
>> >In two messages prior you stated:
>> >
>> >> The RRO received at the HE only contains the IP addresses 
>> >that map to half
>> >> of the LSAs or LSPs that the LSP traversed. 
>> >
>> >You mentioned that only half the LSA/LSPDU were in the RRO, so the
>> >question "What cases were you thinking of?" that you just asked
>should
>> >be directed to you.
>> 
>> I asked the question since you mentioned earlier:
>> 
>> >It wasn't intended to cover all cases and does not depricate use of
>> >path-tear.  You still didn't answer my question.
>> 
>> But it is ok if you don't want to answer the question.
>> 
>> >
>> >Since you brought up the issue "where RRO may be too large" 
>why don't
>> >you do the math and tell us 1) how big the RRO would have 
>to be to be
>> >too large and 2) how likely you think that is of occurring.  RSVPd
>> >objects can be 64KB each.  The IPv4 address subobject is 8 bytes
>long,
>> >including type and length.  Add a label subobject (8 bytes) and fit
>it
>> >into a reasonable MTU and you're still at hundreds of hops.  I get
>> >200+ into a 4KB MTU and most networks seem to be going for 8K MTU so
>I
>> >get "not very likely" for question 2).
>> >
>> >Curtis
>> >
>> 
>> I agree that this is not very likely.
>> 
>> Steve
>>  <<ATT77972.txt>> 
>> 
>
 <<ATT01329.txt>> 


From owner-mpls@UU.NET  Mon Mar 17 16:28:08 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02175
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 16:28:08 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoglq15917
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 21:30:21 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoglq15060;
	Mon, 17 Mar 2003 21:30:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoglo24138
	for mpls-outgoing; Mon, 17 Mar 2003 21:01:37 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoglo23883
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 21:01:22 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoglo22124
	for <mpls@UU.NET>; Mon, 17 Mar 2003 21:01:08 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoglo07009
	for <mpls@UU.NET>; Mon, 17 Mar 2003 21:01:06 GMT
Received: from hermes.fm.intel.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fmr01.intel.com [192.55.52.18])
	id QQoglo06961
	for <mpls@UU.NET>; Mon, 17 Mar 2003 21:01:04 GMT
Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37])
	by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h2HKvFp00561
	for <mpls@UU.NET>; Mon, 17 Mar 2003 20:57:15 GMT
Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126])
	by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h2HKsul05469
	for <mpls@UU.NET>; Mon, 17 Mar 2003 20:54:59 GMT
Received: from fmsmsx28.fm.intel.com ([132.233.42.28])
 by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003031712581614318
 for <mpls@UU.NET>; Mon, 17 Mar 2003 12:58:16 -0800
Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <GY4BDY8A>; Mon, 17 Mar 2003 13:00:35 -0800
Message-ID: <0DCC27458EB5D51181840002A507069E0B291E20@orsmsx117.jf.intel.com>
From: "Parmar, Pankaj N" <pankaj.n.parmar@intel.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: Dissubscribe
Date: Mon, 17 Mar 2003 13:00:33 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk




From owner-mpls@UU.NET  Mon Mar 17 17:21:08 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04706
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 17:21:08 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoglt00119
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 22:23:20 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoglt29343;
	Mon, 17 Mar 2003 22:22:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoglr10761
	for mpls-outgoing; Mon, 17 Mar 2003 21:45:59 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoglr10756
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 21:45:53 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoglr24875
	for <mpls@uu.net>; Mon, 17 Mar 2003 21:45:08 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoglr17223
	for <mpls@uu.net>; Mon, 17 Mar 2003 21:45:06 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoglr17209
	for <mpls@uu.net>; Mon, 17 Mar 2003 21:45:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2HLj2vD020867
	for <mpls@uu.net>; Mon, 17 Mar 2003 16:45:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA29403 for <mpls@uu.net>; Mon, 17 Mar 2003 16:45:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2HLj1810496 for mpls@uu.net; Mon, 17 Mar 2003 16:45:01 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoglq10465
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 21:44:16 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoglq20429
	for <mpls@UU.NET>; Mon, 17 Mar 2003 21:43:58 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoglq15277
	for <mpls@UU.NET>; Mon, 17 Mar 2003 21:43:57 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoglq15262
	for <mpls@UU.NET>; Mon, 17 Mar 2003 21:43:56 GMT
Received: from pilgrim.cisco.com (pilgrim.cisco.com [161.44.168.94])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2HLhjvD020776;
	Mon, 17 Mar 2003 16:43:45 -0500 (EST)
Received: from SWALLOW-W2K.cisco.com ([10.82.244.28])
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA00004;
	Mon, 17 Mar 2003 16:43:41 -0500 (EST)
Message-Id: <4.3.2.7.2.20030317163939.00b82e10@pilgrim.cisco.com>
X-Sender: swallow@pilgrim.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 17 Mar 2003 16:43:37 -0500
To: curtis@fictitious.org
From: George Swallow <swallow@cisco.com>
Subject: Re: draft-meyer-soft-preemption-00.txt 
Cc: "Adrian Farrel" <afarrel@movaz.com>, mrn@gblx.net, denver@gblx.net,
        jpv@cisco.com, "'mpls@uu.net'" <mpls@UU.NET>
In-Reply-To: <200303172016.PAA32555@workhorse.fictitious.org>
References: <Your message of "Mon, 17 Mar 2003 13:21:54 EST." <200303171821.NAA22711@bifocal.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 03:16 PM 3/17/2003 -0500, Curtis Villamizar wrote:

>In 2961, all it says about path-err is "PathErr and ResvErr messages
>SHOULD be treated as implicit acknowledgments".  They are still one
>shots.
>
>If anything, if drops do occur, fast RESV propogation is more likely
>with RFC2961 but path-err reliability is not improved.

Curtis -

 From RFC2961:

4.5. MESSAGE_ID Object Usage

    The MESSAGE_ID object may be included in any RSVP message other than
    the Ack and Bundle messages.  The MESSAGE_ID object is always
    generated and processed over a single hop between RSVP neighbors.

So you can use 2961 for reliable delivery of a Path_Err.

...George



From owner-mpls@UU.NET  Mon Mar 17 17:37:48 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05141
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 17:37:48 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoglu00062
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 22:40:00 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoglu29607;
	Mon, 17 Mar 2003 22:39:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoglr11846
	for mpls-outgoing; Mon, 17 Mar 2003 21:58:33 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoglr11833
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 21:58:22 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoglr24672
	for <mpls@uu.net>; Mon, 17 Mar 2003 21:58:09 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoglr09036
	for <mpls@uu.net>; Mon, 17 Mar 2003 21:58:08 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoglr09015
	for <mpls@uu.net>; Mon, 17 Mar 2003 21:58:04 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2HLw2vD021980
	for <mpls@uu.net>; Mon, 17 Mar 2003 16:58:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA00376 for <mpls@uu.net>; Mon, 17 Mar 2003 16:58:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2HLw1G11800 for mpls@uu.net; Mon, 17 Mar 2003 16:58:01 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoglr11742
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 21:56:34 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoglr08927
	for <mpls@UU.NET>; Mon, 17 Mar 2003 21:56:00 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoglr13855
	for <mpls@UU.NET>; Mon, 17 Mar 2003 21:55:58 GMT
Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQoglr13815
	for <mpls@UU.NET>; Mon, 17 Mar 2003 21:55:57 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA33840;
	Mon, 17 Mar 2003 16:54:04 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303172154.QAA33840@workhorse.fictitious.org>
To: curtis@fictitious.org
cc: George Swallow <swallow@cisco.com>, "Adrian Farrel" <afarrel@movaz.com>,
        mrn@gblx.net, denver@gblx.net, jpv@cisco.com,
        "'mpls@uu.net'" <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: draft-meyer-soft-preemption-00.txt 
In-reply-to: Your message of "Mon, 17 Mar 2003 15:10:05 EST."
             <200303172010.PAA32522@workhorse.fictitious.org> 
Date: Mon, 17 Mar 2003 16:54:04 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <200303172010.PAA32522@workhorse.fictitious.org>, Curtis Villamizar 
writes:
> 
> Also, I haven't mentioned to the list, but if you put the preempted
> bit back in the PATH ERO, others downstream of the initial
> soft-preempt can soft-preempt the same LSP during the time that it
> reroutes.  If we are looking for sub-second convergence plus
> soft-preempt, this could be a very valuable feature.  The bit change
> in the ERO is purely advisory and requires no change in resource
> allocation so it can be propogated very quickly, much more quickly
> than CSPF plus path setup.


Pavan Beeram pointed out that this could go in the PATH RRO and be
sent directly by the midpoint at the time of failure to indicate to
the downstreams that an soft-preempt was pending and increasing the
chance of preempting the same LSP rather than a different one.

Curtis



From owner-mpls@UU.NET  Mon Mar 17 17:48:29 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05517
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 17:48:29 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoglv21219
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 22:50:42 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoglv21096;
	Mon, 17 Mar 2003 22:50:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogls01726
	for mpls-outgoing; Mon, 17 Mar 2003 22:14:01 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQogls01711
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 22:13:51 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQogls21251
	for <mpls@UU.NET>; Mon, 17 Mar 2003 22:13:32 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogls09841
	for <mpls@UU.NET>; Mon, 17 Mar 2003 22:13:32 GMT
Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQogls09817
	for <mpls@UU.NET>; Mon, 17 Mar 2003 22:13:31 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2HMDUS66496
	for <mpls@UU.NET>; Mon, 17 Mar 2003 14:13:30 -0800 (PST)
	(envelope-from kireeti@juniper.net)
Received: from localhost (kireeti@localhost)
	by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h2HMDUF21600
	for <mpls@UU.NET>; Mon, 17 Mar 2003 14:13:30 -0800 (PST)
	(envelope-from kireeti@juniper.net)
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
Date: Mon, 17 Mar 2003 14:13:30 -0800 (PST)
From: Kireeti Kompella <kireeti@juniper.net>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: Re: Dissubscribe
In-Reply-To: <0DCC27458EB5D51181840002A507069E0B291E20@orsmsx117.jf.intel.com>
Message-ID: <20030317140756.E21526@kummer.juniper.net>
References: <0DCC27458EB5D51181840002A507069E0B291E20@orsmsx117.jf.intel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

There seem to be a lot of people "dissubscribing" from this list,
whatever that is.

If the intent is to un-subs-cribe (hyphens introduced to circumvent
overzealous remailers), please read the MPLS list instructions at
http://www.ietf.org/html.charters/mpls-charter.html .

Kireeti.


From owner-mpls@UU.NET  Mon Mar 17 18:21:12 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07507
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 18:21:12 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoglx03432
	for <mpls-archive@lists.ietf.org>; Mon, 17 Mar 2003 23:23:25 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoglx03321;
	Mon, 17 Mar 2003 23:23:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoglv05457
	for mpls-outgoing; Mon, 17 Mar 2003 22:52:59 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoglv05394
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Mar 2003 22:52:45 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoglv23181
	for <mpls@UU.NET>; Mon, 17 Mar 2003 22:52:26 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoglv28109
	for <mpls@UU.NET>; Mon, 17 Mar 2003 22:52:25 GMT
Received: from caduceus.fm.intel.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fmr02.intel.com [192.55.52.25])
	id QQoglv28091
	for <mpls@UU.NET>; Mon, 17 Mar 2003 22:52:25 GMT
Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37])
	by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h2HLuA409108
	for <mpls@UU.NET>; Mon, 17 Mar 2003 21:56:11 GMT
Received: from fmsmsxv040-1.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124])
	by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h2HLv3l19501
	for <mpls@UU.NET>; Mon, 17 Mar 2003 21:57:03 GMT
Received: from fmsmsx26.fm.intel.com ([132.233.42.26])
 by fmsmsxv040-1.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003031714025715979
 for <mpls@UU.NET>; Mon, 17 Mar 2003 14:02:57 -0800
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <G8Z8L2YR>; Mon, 17 Mar 2003 14:02:42 -0800
Message-ID: <65D5A07B5098D511BDDA0002A508E64F057A34F6@orsmsx110.jf.intel.com>
From: "Mishra, Manav" <manav.mishra@intel.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Subject:  Dissubscribe
Date: Mon, 17 Mar 2003 14:02:38 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk




From owner-mpls@UU.NET  Tue Mar 18 03:13:38 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03948
	for <mpls-archive@lists.ietf.org>; Tue, 18 Mar 2003 03:13:37 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQognh21400
	for <mpls-archive@lists.ietf.org>; Tue, 18 Mar 2003 08:15:52 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQognh21280;
	Tue, 18 Mar 2003 08:15:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQognf29671
	for mpls-outgoing; Tue, 18 Mar 2003 07:49:42 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQognf29663
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Mar 2003 07:49:23 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQognf11264
	for <mpls@uu.net>; Tue, 18 Mar 2003 07:48:07 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQognf10388
	for <mpls@uu.net>; Tue, 18 Mar 2003 07:48:06 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQognf10335
	for <mpls@uu.net>; Tue, 18 Mar 2003 07:48:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2I7m2vD021392
	for <mpls@uu.net>; Tue, 18 Mar 2003 02:48:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id CAA02457 for <mpls@uu.net>; Tue, 18 Mar 2003 02:48:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2I7m2N13427 for mpls@uu.net; Tue, 18 Mar 2003 02:48:02 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQognf29582
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Mar 2003 07:47:00 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQognf08661
	for <mpls@UU.NET>; Tue, 18 Mar 2003 07:46:28 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQognf14113
	for <mpls@UU.NET>; Tue, 18 Mar 2003 07:46:28 GMT
Received: from ams-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ams-msg-core-1.cisco.com [144.254.74.60])
	id QQognf14102
	for <mpls@UU.NET>; Tue, 18 Mar 2003 07:46:27 GMT
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2I7iUbK019275;
	Tue, 18 Mar 2003 08:44:30 +0100 (MET)
Received: from JVASSEUR-W2K.cisco.com (sjck-dial-gw5-149.cisco.com [10.19.238.150])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA01551;
	Tue, 18 Mar 2003 08:46:05 +0100 (MET)
Message-Id: <4.3.2.7.2.20030317233654.05434398@paris.cisco.com>
X-Sender: jvasseur@paris.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 17 Mar 2003 23:46:04 -0800
To: curtis@fictitious.org
From: Jean Philippe Vasseur <jvasseur@cisco.com>
Subject: Re: draft-meyer-soft-preemption-00.txt 
Cc: George Swallow <swallow@cisco.com>, curtis@fictitious.org,
        "Adrian Farrel" <afarrel@movaz.com>, mrn@gblx.net, denver@gblx.net,
        jpv@cisco.com, "'mpls@uu.net'" <mpls@UU.NET>
In-Reply-To: <200303172010.PAA32522@workhorse.fictitious.org>
References: <Your message of "Mon, 17 Mar 2003 14:21:46 EST." <200303171921.OAA23501@bifocal.cisco.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_95316858==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=====================_95316858==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi Curtis,

At 15:10 17/03/2003 -0500, Curtis Villamizar wrote:

>In message <200303171921.OAA23501@bifocal.cisco.com>, George Swallow writes:
> > Curtis -
> >
> > > The current semantics of path-err or path-tear is to indicate an error
> > > in setup or to tear down.  Any intermediate node that didn' understand
> > > this would release resources and cause traffic to black hole, exactly
> > > what the soft preempt is trying to avoid.
> >
> > If that were true for path-err, why does path-err have an in-place bit
> > to express that the reservation is still there?
> >
> > ...George
>
>
>Expect that a certain implementation that we need to take into
>consideration tears down if it doesn't understand the error code.
>
>It also gets upset if it doesn't understand bits in the 'RRO IPv4/IPv6
>Sub-Object Flags' or 'SESSION-ATTRIBUTES Flag' so that doesn't help
>with either RRO flags or path-err.  At least the SESSION-ATTRIBUTES
>flag will yield a path-err on the initial setup and the ingress can
>fall back to a setup with no soft-preempt requested.
>
>If the ingress doesn't understand soft-preempt, no sense sending it,
>since it just delays the inevitable preempt.  If the midpoints will
>tear down immediately due to an unknown error code or an unknown RRO
>flag bit, its good to know that too.
>
>The preference for the RRO flag is that like the protect-inuse, the
>ingress knows which hops it does not have resources on.  Consider the
>path A-B-C-...Z.  If hops D-E and G-H have preempted, but all of the
>hops are near 100% utilized, the ingress knows it can share bandwidth
>with its prior LSP on all hops for which the RRO flag bit is not set.
>Its harder to do that with a collection of path-err messages.

That's perfectly correct and one of the reasons why we ended up with this 
scheme. Otherwise, the HE would have had to wait for some unknown period of 
time (to make sure it has received all the PERR from the set of preempting 
nodes) before triggering a new CSPF on the modified topology

>Also, I haven't mentioned to the list, but if you put the preempted
>bit back in the PATH ERO, others downstream of the initial
>soft-preempt can soft-preempt the same LSP during the time that it
>reroutes.  If we are looking for sub-second convergence plus
>soft-preempt, this could be a very valuable feature.  The bit change
>in the ERO is purely advisory and requires no change in resource
>allocation so it can be propogated very quickly, much more quickly
>than CSPF plus path setup.
>
>Another reason to put this in the RRO is if FRR is used, the LSP is
>both soft-preempted and protect-inuse must be set.  It is better to
>set two bits in the RRO rather than send two separate messages.  If
>the backup got preempted, then soft-preempt set and local-protect
>available cleared would have a higher sense of urgency than
>soft-preempt set and local-protect inuse being set.

Fully agree.

Will add another one: the number of signalling messages when the preempted 
TE LSP is soft preempted at multiple hops ...

This only drawback with the Resv RRO message would be the existence of mid 
point LSRs non supporting the soft preemption draft as they might no detect 
the Resv message change (RRO preemption pending bit set) and as such would 
not trigger an immediate refresh. This would introduce some delay in the HE 
notification.

JP.

>I've given a few advantages of putting this in RRO.  What are the
>technical advantages of putting this in path-err?
>
>Curtis

--=====================_95316858==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Hi Curtis,<br>
<br>
At 15:10 17/03/2003 -0500, Curtis Villamizar wrote:<br>
<br>
<blockquote type=cite cite>In message
&lt;200303171921.OAA23501@bifocal.cisco.com&gt;, George Swallow
writes:<br>
&gt; Curtis -<br>
&gt; <br>
&gt; &gt; The current semantics of path-err or path-tear is to indicate
an error<br>
&gt; &gt; in setup or to tear down.&nbsp; Any intermediate node that
didn' understand<br>
&gt; &gt; this would release resources and cause traffic to black hole,
exactly<br>
&gt; &gt; what the soft preempt is trying to avoid.<br>
&gt; <br>
&gt; If that were true for path-err, why does path-err have an in-place
bit<br>
&gt; to express that the reservation is still there?<br>
&gt; <br>
&gt; ...George<br>
<br>
<br>
Expect that a certain implementation that we need to take into<br>
consideration tears down if it doesn't understand the error code.<br>
<br>
It also gets upset if it doesn't understand bits in the 'RRO
IPv4/IPv6<br>
Sub-Object Flags' or 'SESSION-ATTRIBUTES Flag' so that doesn't help<br>
with either RRO flags or path-err.&nbsp; At least the
SESSION-ATTRIBUTES<br>
flag will yield a path-err on the initial setup and the ingress can<br>
fall back to a setup with no soft-preempt requested.<br>
<br>
If the ingress doesn't understand soft-preempt, no sense sending 
it,<br>
since it just delays the inevitable preempt.&nbsp; If the midpoints
will<br>
tear down immediately due to an unknown error code or an unknown 
RRO<br>
flag bit, its good to know that too.<br>
<br>
The preference for the RRO flag is that like the protect-inuse, the<br>
ingress knows which hops it does not have resources on.&nbsp; Consider
the<br>
path A-B-C-...Z.&nbsp; If hops D-E and G-H have preempted, but all of
the<br>
hops are near 100% utilized, the ingress knows it can share
bandwidth<br>
with its prior LSP on all hops for which the RRO flag bit is not
set.<br>
Its harder to do that with a collection of path-err messages.<br>
</blockquote><br>
That's perfectly correct and one of the reasons why we ended up with this
scheme. Otherwise, the HE would have had to wait for some unknown period
of time (to make sure it has received all the PERR from the set of
preempting nodes) before triggering a new CSPF on the modified topology
<br>
<br>
<blockquote type=cite cite>Also, I haven't mentioned to the list, but if
you put the preempted<br>
bit back in the PATH ERO, others downstream of the initial<br>
soft-preempt can soft-preempt the same LSP during the time that it<br>
reroutes.&nbsp; If we are looking for sub-second convergence plus<br>
soft-preempt, this could be a very valuable feature.&nbsp; The bit
change<br>
in the ERO is purely advisory and requires no change in resource<br>
allocation so it can be propogated very quickly, much more quickly<br>
than CSPF plus path setup.<br>
<br>
Another reason to put this in the RRO is if FRR is used, the LSP is<br>
both soft-preempted and protect-inuse must be set.&nbsp; It is better
to<br>
set two bits in the RRO rather than send two separate messages.&nbsp;
If<br>
the backup got preempted, then soft-preempt set and local-protect<br>
available cleared would have a higher sense of urgency than<br>
soft-preempt set and local-protect inuse being set.<br>
</blockquote><br>
Fully agree.<br>
<br>
Will add another one: the number of signalling messages when the
preempted TE LSP is soft preempted at multiple hops ...<br>
<br>
This <u>only </u>drawback with the Resv RRO message would be the
existence of mid point LSRs non supporting the soft preemption draft as
they might no detect the Resv message change (RRO preemption pending bit
set) and as such would not trigger an immediate refresh. This would
introduce some delay in the HE notification.<br>
<br>
JP.<br>
<br>
<blockquote type=cite cite>I've given a few advantages of putting this in
RRO.&nbsp; What are the<br>
technical advantages of putting this in path-err?<br>
<br>
Curtis </blockquote></html>

--=====================_95316858==_.ALT--



From owner-mpls@UU.NET  Tue Mar 18 10:59:51 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14994
	for <mpls-archive@lists.ietf.org>; Tue, 18 Mar 2003 10:59:51 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogom06106
	for <mpls-archive@lists.ietf.org>; Tue, 18 Mar 2003 16:02:04 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogom05709;
	Tue, 18 Mar 2003 16:01:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogok00875
	for mpls-outgoing; Tue, 18 Mar 2003 15:34:45 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQogok00868
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Mar 2003 15:34:28 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQogok03692
	for <mpls@uu.net>; Tue, 18 Mar 2003 15:34:07 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogok11141
	for <mpls@uu.net>; Tue, 18 Mar 2003 15:34:06 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQogok11100
	for <mpls@uu.net>; Tue, 18 Mar 2003 15:34:04 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2IFY2vD001277
	for <mpls@uu.net>; Tue, 18 Mar 2003 10:34:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA22469 for <mpls@uu.net>; Tue, 18 Mar 2003 10:34:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2IFY2p06092 for mpls@uu.net; Tue, 18 Mar 2003 10:34:02 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQogok00827
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Mar 2003 15:33:06 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQogok20107
	for <mpls@UU.NET>; Tue, 18 Mar 2003 15:32:06 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogok21951
	for <mpls@UU.NET>; Tue, 18 Mar 2003 15:32:06 GMT
Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQogok21939
	for <mpls@UU.NET>; Tue, 18 Mar 2003 15:32:04 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id KAA48823;
	Tue, 18 Mar 2003 10:29:58 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303181529.KAA48823@workhorse.fictitious.org>
To: Jean Philippe Vasseur <jvasseur@cisco.com>
cc: curtis@fictitious.org, George Swallow <swallow@cisco.com>,
        "Adrian Farrel" <afarrel@movaz.com>, mrn@gblx.net, denver@gblx.net,
        jpv@cisco.com, "'mpls@uu.net'" <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: draft-meyer-soft-preemption-00.txt 
In-reply-to: Your message of "Mon, 17 Mar 2003 23:46:04 PST."
             <4.3.2.7.2.20030317233654.05434398@paris.cisco.com> 
Date: Tue, 18 Mar 2003 10:29:58 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <4.3.2.7.2.20030317233654.05434398@paris.cisco.com>, Jean Philippe V
asseur writes:
> 
> 
> This only drawback with the Resv RRO message would be the existence of mid 
> point LSRs non supporting the soft preemption draft as they might no detect 
> the Resv message change (RRO preemption pending bit set) and as such would 
> not trigger an immediate refresh. This would introduce some delay in the HE 
> notification.
> 
> JP.


Our RSVP guys tell me the same LSR we are both concerned about that is
blind to RRO changes such as local-protect-inuse also barfs on unknown
bits in the session object so if one of them was in the path the
initial PATH message would have to remove the request for
soft-preemption to get the LSP to come up in the first place.  So this
would work for LSR software in the field and just work better when
that software is upgraded.

This brings to mind two useful changes to RFC3209 or another document
could be written and later merged in.  Either the semantics of the
SESSION-ATTRIBUTES Flags should have a note that unknown bits should
be ignored.  In the description of the RRO, a note should be made that
an LSR must pass on changes to the IPv4/IPv6 flags immediately and
must ignore flags that are not understood.  A small section could be
added giving guidelines for well written extensions.  These would have
a request bit in the SESSION-ATTRIBUTES Flags, a capabilities bit in
the RRO IPv4 or IPv6 flags, and if needed one or more status bit (such as
available and inuse for local-protect, or pending for soft-preempt).

I would hope that extensions would be rare and if proved useful would
be folded into an update to RFC3209.  Extensions have to be rare
because we only have 8 bits available so we should be choosey.  I
think soft preempt is a valuable extension.  Its need has been stated
by ISPs and its need has been proven in practice. (more than one has brought this up, but not on the list, the
author of this document is from GX though, so this is from an SP)

Curtis



From owner-mpls@UU.NET  Tue Mar 18 11:07:26 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15206
	for <mpls-archive@lists.ietf.org>; Tue, 18 Mar 2003 11:07:26 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogom13868
	for <mpls-archive@lists.ietf.org>; Tue, 18 Mar 2003 16:09:40 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogom13534;
	Tue, 18 Mar 2003 16:09:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogok01467
	for mpls-outgoing; Tue, 18 Mar 2003 15:42:05 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQogok01451
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Mar 2003 15:41:46 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQogok15196
	for <mpls@uu.net>; Tue, 18 Mar 2003 15:41:20 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogok25126
	for <mpls@uu.net>; Tue, 18 Mar 2003 15:41:16 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQogok25013
	for <mpls@uu.net>; Tue, 18 Mar 2003 15:41:13 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2IFf8Sc023573
	for <mpls@uu.net>; Tue, 18 Mar 2003 10:41:09 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA23048 for <mpls@uu.net>; Tue, 18 Mar 2003 10:41:08 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2IFf8906730 for mpls@uu.net; Tue, 18 Mar 2003 10:41:08 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQogok01229
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Mar 2003 15:40:24 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQogok05515
	for <mpls@UU.NET>; Tue, 18 Mar 2003 15:38:59 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogok20907
	for <mpls@UU.NET>; Tue, 18 Mar 2003 15:38:58 GMT
Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQogok20849
	for <mpls@UU.NET>; Tue, 18 Mar 2003 15:38:57 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id KAA48850;
	Tue, 18 Mar 2003 10:36:55 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303181536.KAA48850@workhorse.fictitious.org>
To: Jean Philippe Vasseur <jvasseur@cisco.com>
cc: curtis@fictitious.org, George Swallow <swallow@cisco.com>,
        "Adrian Farrel" <afarrel@movaz.com>, mrn@gblx.net, denver@gblx.net,
        jpv@cisco.com, "'mpls@uu.net'" <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: draft-meyer-soft-preemption-00.txt 
In-reply-to: Your message of "Mon, 17 Mar 2003 23:46:04 PST."
             <4.3.2.7.2.20030317233654.05434398@paris.cisco.com> 
Date: Tue, 18 Mar 2003 10:36:55 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <4.3.2.7.2.20030317233654.05434398@paris.cisco.com>, Jean Philippe V
asseur writes:
> 
> 
> This only drawback with the Resv RRO message would be the existence of mid 
> point LSRs non supporting the soft preemption draft as they might no detect 
> the Resv message change (RRO preemption pending bit set) and as such would 
> not trigger an immediate refresh. This would introduce some delay in the HE 
> notification.
> 
> JP.


Our RSVP guys tell me the same LSR we are both concerned about that is
blind to RRO changes such as local-protect-inuse also barfs on unknown
bits in the session object so if one of them was in the path the
initial PATH message would have to remove the request for
soft-preemption to get the LSP to come up in the first place.  So this
would work for LSR software in the field and just work better when
that software is upgraded.

This brings to mind two useful changes to RFC3209 or another document
could be written and later merged in.  Either the semantics of the
SESSION-ATTRIBUTES Flags should have a note that unknown bits should
be ignored.  In the description of the RRO, a note should be made that
an LSR must pass on changes to the IPv4/IPv6 flags immediately and
must ignore flags that are not understood.  A small section could be
added giving guidelines for well written extensions.  These would have
a request bit in the SESSION-ATTRIBUTES Flags, a capabilities bit in
the RRO IPv4 or IPv6 flags, and if needed one or more status bit (such as
available and inuse for local-protect, or pending for soft-preempt).

It would be easiest to write an extensions mechanism draft and then
fold it into RFC3209 later.  If we were worried about too few bits
(and I'd prefer we didn't go this route) we could add an extension
request object with a 32 bit flag, and a 32 bit extension capabilities
and flags subobject to RRO.  I'd prefer keeping the number of
extension to mimimum and only doing things with very clear benefits.

I would hope that extensions would be rare and if proved useful would
be folded into an update to RFC3209.  Extensions have to be rare
because we only have 8 bits available so we should be choosey.  I
think soft preempt is a valuable extension.  Its need has been stated
by ISPs and its need has been proven in practice.  More than one has
brought this up, but not on the list, the author of this document is
from GX though, so this is from an SP.

Curtis



From owner-mpls@UU.NET  Tue Mar 18 12:01:58 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18491
	for <mpls-archive@lists.ietf.org>; Tue, 18 Mar 2003 12:01:57 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogoq09185
	for <mpls-archive@lists.ietf.org>; Tue, 18 Mar 2003 17:04:09 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogoq08370;
	Tue, 18 Mar 2003 17:03:47 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogoo24842
	for mpls-outgoing; Tue, 18 Mar 2003 16:38:31 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQogoo24836
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Mar 2003 16:38:27 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQogoo02856
	for <mpls@UU.NET>; Tue, 18 Mar 2003 16:37:25 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogoo19825
	for <mpls@UU.NET>; Tue, 18 Mar 2003 16:37:24 GMT
Received: from atlntex01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: exchange.movaz.com [65.205.166.141])
	id QQogoo19813
	for <mpls@UU.NET>; Tue, 18 Mar 2003 16:37:24 GMT
Received: from BLIULAPTOP ([172.16.8.184]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 18 Mar 2003 11:37:23 -0500
Message-ID: <002701c2ed6c$ae76d730$d68a8182@movaz.com>
From: "Adrian Farrel" <afarrel@movaz.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Fw: draft-nadeau-ietf-oam-requirements-01.txt
Date: Tue, 18 Mar 2003 11:37:34 -0500
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-OriginalArrivalTime: 18 Mar 2003 16:37:23.0991 (UTC) FILETIME=[A75C9A70:01C2ED6C]
Sender: owner-mpls@UU.NET
Precedence: bulk

Forwarding to WG mailing list.
----- Original Message -----
From: "Adrian Farrel" <afarrel@movaz.com>
To: "Thomas D. Nadeau" <tnadeau@cisco.com>
Cc: <mmorrow@cisco.com>; "George Swallow" <swallow@cisco.com>;
<dallan@nortelnetworks.com>
Sent: Monday, March 17, 2003 7:13 PM
Subject: draft-nadeau-ietf-oam-requirements-01.txt


> Hi Tom,
>
> Can you add a requirement in 3.1 that detection mechanisms must not have an
> "undue" impact on traffic (that is traffic when there is no error and traffic
on
> other LSPs)
>
> Typos...
> section 3
> "relationships between providers has" read "have"
>
> section 3.1
> "specified both w.r.t. with regard to" strike "w.r.t."
>
> section 3.2
> "specify recovery actions in an" add "for" to read "specify recovery actions
for
> in an"
>
> section 3.5
> "the generation of superfluous generation of"
> Self-defining text :-)
>
> sections 3.8 and 3.9 are not sections
>
> Cheers,
> Adrian
>
>




From owner-mpls@UU.NET  Tue Mar 18 12:20:50 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19094
	for <mpls-archive@lists.ietf.org>; Tue, 18 Mar 2003 12:20:50 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogor16544
	for <mpls-archive@lists.ietf.org>; Tue, 18 Mar 2003 17:23:03 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogor15947;
	Tue, 18 Mar 2003 17:22:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogop26553
	for mpls-outgoing; Tue, 18 Mar 2003 16:56:06 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQogop26442
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Mar 2003 16:56:01 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQogop09419
	for <mpls@UU.NET>; Tue, 18 Mar 2003 16:55:42 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogop24115
	for <mpls@UU.NET>; Tue, 18 Mar 2003 16:55:41 GMT
Received: from atlntex01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: exchange.movaz.com [65.205.166.141])
	id QQogop24094
	for <mpls@UU.NET>; Tue, 18 Mar 2003 16:55:41 GMT
Received: from BLIULAPTOP ([172.16.8.184]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 18 Mar 2003 11:55:39 -0500
Message-ID: <003501c2ed6f$3b708da0$d68a8182@movaz.com>
From: "Adrian Farrel" <afarrel@movaz.com>
To: <curtis@fictitious.org>, "Jean Philippe Vasseur" <jvasseur@cisco.com>
Cc: "George Swallow" <swallow@cisco.com>, <curtis@fictitious.org>,
        <mrn@gblx.net>, <denver@gblx.net>, <jpv@cisco.com>,
        "'mpls@uu.net'" <mpls@UU.NET>
References: <Your message of "Mon, 17 Mar 2003 14:21:46 EST." <200303171921.OAA23501@bifocal.cisco.com> <4.3.2.7.2.20030317233654.05434398@paris.cisco.com>
Subject: Re: draft-meyer-soft-preemption-00.txt 
Date: Tue, 18 Mar 2003 11:55:28 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0030_01C2ED45.44ABC7B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-OriginalArrivalTime: 18 Mar 2003 16:55:40.0660 (UTC) FILETIME=[35070340:01C2ED6F]
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0030_01C2ED45.44ABC7B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

    The preference for the RRO flag is that like the protect-inuse, the
    ingress knows which hops it does not have resources on.  Consider =
the path A-B-C-...Z.  If hops D-E and G-H have preempted, but all of the =
hops are near 100% utilized, the ingress knows it can share bandwidth =
with its prior LSP on all hops for which the RRO flag bit is not set. =
Its harder to do that with a collection of path-err messages.


  That's perfectly correct and one of the reasons why we ended up with =
this scheme. Otherwise, the HE would have had to wait for some unknown =
period of time (to make sure it has received all the PERR from the set =
of preempting nodes) before triggering a new CSPF on the modified =
topology=20

OK. But I don't see how using Resv lets you know when all of the =
premption is complete. Since in your example preemption of D-E is likely =
to happen first it will  trigger a Resv reporting just one hop as =
preempted. Later there will be another Resv that indicates D-E and G-H =
as preempted. Sometime later there might be another Resv indicating =
further preemption down near Z.=20
The only advantage seems to be that the Resv gives you a list of =
preemptions that have happened (saving the HE from having to maintain =
that list itself). It does not remove the "unknown period of time" =
issue.

    Also, I haven't mentioned to the list, but if you put the preempted
    bit back in the PATH ERO, others downstream of the initial
    soft-preempt can soft-preempt the same LSP during the time that it
    reroutes.  If we are looking for sub-second convergence plus
    soft-preempt, this could be a very valuable feature.  The bit change
    in the ERO is purely advisory and requires no change in resource
    allocation so it can be propogated very quickly, much more quickly
    than CSPF plus path setup.

This is a good reason for a flag in the ERO. It doesn't speak to the use =
of Resv at all.
    Another reason to put this in the RRO is if FRR is used, the LSP is
    both soft-preempted and protect-inuse must be set.  It is better to
    set two bits in the RRO rather than send two separate messages.  If
    the backup got preempted, then soft-preempt set and local-protect
    available cleared would have a higher sense of urgency than
    soft-preempt set and local-protect inuse being set.
  Fully agree.

  Will add another one: the number of signalling messages when the =
preempted TE LSP is soft preempted at multiple hops ...
As in the example above, you still get multiple messages (don't you?).
  This only drawback with the Resv RRO message would be the existence of =
mid point LSRs non supporting the soft preemption draft as they might no =
detect the Resv message change (RRO preemption pending bit set) and as =
such would not trigger an immediate refresh. This would introduce some =
delay in the HE notification.
Are you sure there are no implementations out there that will tear down =
the LSP because of an unrecognized flag in the RRO? :-)

Adrian

------=_NextPart_000_0030_01C2ED45.44ABC7B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3019.2500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <BLOCKQUOTE cite type=3D"cite">The preference for the RRO flag is that =
like=20
    the protect-inuse, the<BR>ingress knows which hops it does not have=20
    resources on.&nbsp; Consider the path A-B-C-...Z.&nbsp; If hops D-E =
and G-H=20
    have preempted, but all of the hops are near 100% utilized, the =
ingress=20
    knows it can share bandwidth with its prior LSP on all hops for =
which the=20
    RRO flag bit is not set. Its harder to do that with a collection of =
path-err=20
    messages.<BR></BLOCKQUOTE>
  <DIV><BR>That's perfectly correct and one of the reasons why we ended =
up with=20
  this scheme. Otherwise, the HE would have had to wait for some unknown =
period=20
  of time (to make sure it has received all the PERR from the set of =
preempting=20
  nodes) before triggering a new CSPF on the modified topology </DIV>
  <DIV>&nbsp;</DIV></BLOCKQUOTE>
<DIV>OK. But I don't see how using Resv lets you know when all of the =
premption=20
is complete. Since in your example preemption of D-E is likely to happen =
first=20
it will  trigger a Resv reporting just one hop as preempted. Later there =
will be=20
another Resv that indicates D-E and G-H as preempted. Sometime later =
there might=20
be another Resv indicating further preemption down near Z. </DIV>
<DIV>The only advantage seems to be that the Resv gives you a list of=20
preemptions that have happened (saving the HE from having to maintain =
that list=20
itself). It does not remove the "unknown period of time" =
issue.<BR></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <BLOCKQUOTE cite type=3D"cite">
    <DIV>Also, I haven't mentioned to the list, but if you put the=20
    preempted<BR>bit back in the PATH ERO, others downstream of the=20
    initial<BR>soft-preempt can soft-preempt the same LSP during the =
time that=20
    it<BR>reroutes.&nbsp; If we are looking for sub-second convergence=20
    plus<BR>soft-preempt, this could be a very valuable feature.&nbsp; =
The bit=20
    change<BR>in the ERO is purely advisory and requires no change in=20
    resource<BR>allocation so it can be propogated very quickly, much =
more=20
    quickly<BR>than CSPF plus path setup.</DIV>
    <DIV>&nbsp;</DIV></BLOCKQUOTE></BLOCKQUOTE>
<DIV><FONT face=3DCourier size=3D2>This is a good reason for a flag in =
the ERO. It=20
doesn't speak to the use of Resv at all.</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <BLOCKQUOTE cite type=3D"cite">
    <DIV>Another reason to put this in the RRO is if FRR is used, the =
LSP=20
    is<BR>both soft-preempted and protect-inuse must be set.&nbsp; It is =
better=20
    to<BR>set two bits in the RRO rather than send two separate =
messages.&nbsp;=20
    If<BR>the backup got preempted, then soft-preempt set and=20
    local-protect<BR>available cleared would have a higher sense of =
urgency=20
    than<BR>soft-preempt set and local-protect inuse being =
set.</DIV></BLOCKQUOTE>
  <DIV>Fully agree.<BR><BR>Will add another one: the number of =
signalling=20
  messages when the preempted TE LSP is soft preempted at multiple hops=20
...</DIV></BLOCKQUOTE>
<DIV><FONT face=3DCourier size=3D2>As in the example above, you still =
get multiple=20
messages (don't you?).</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV>This <U>only </U>drawback with the Resv RRO message would be the=20
  existence of mid point LSRs non supporting the soft preemption draft =
as they=20
  might no detect the Resv message change (RRO preemption pending bit =
set) and=20
  as such would not trigger an immediate refresh. This would introduce =
some=20
  delay in the HE notification.</DIV></BLOCKQUOTE>
<DIV>Are you sure there are no implementations out there that will tear =
down the=20
LSP because of an unrecognized flag in the RRO? :-)</DIV>
<DIV>&nbsp;</DIV>
<DIV>Adrian</DIV></BODY></HTML>

------=_NextPart_000_0030_01C2ED45.44ABC7B0--



From owner-mpls@UU.NET  Tue Mar 18 12:38:53 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19706
	for <mpls-archive@lists.ietf.org>; Tue, 18 Mar 2003 12:38:52 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogos21374
	for <mpls-archive@lists.ietf.org>; Tue, 18 Mar 2003 17:41:05 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogos20640;
	Tue, 18 Mar 2003 17:40:47 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogoq16483
	for mpls-outgoing; Tue, 18 Mar 2003 17:14:25 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQogoq16476
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Mar 2003 17:14:11 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQogoq13216
	for <mpls@uu.net>; Tue, 18 Mar 2003 17:14:07 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogoq05591
	for <mpls@uu.net>; Tue, 18 Mar 2003 17:14:06 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQogoq05579
	for <mpls@uu.net>; Tue, 18 Mar 2003 17:14:06 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2IHE3vD009670
	for <mpls@uu.net>; Tue, 18 Mar 2003 12:14:04 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA00327 for <mpls@uu.net>; Tue, 18 Mar 2003 12:14:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2IHE2s16124 for mpls@uu.net; Tue, 18 Mar 2003 12:14:02 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQogoq16407
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Mar 2003 17:13:16 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQogoq13220
	for <mpls@UU.NET>; Tue, 18 Mar 2003 17:12:38 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogoq24099
	for <mpls@UU.NET>; Tue, 18 Mar 2003 17:12:37 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQogoq24081
	for <mpls@UU.NET>; Tue, 18 Mar 2003 17:12:37 GMT
Received: from bucket.cisco.com (IDENT:mirapoint@bucket.cisco.com [161.44.167.72])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2IHCYSc013319;
	Tue, 18 Mar 2003 12:12:35 -0500 (EST)
Received: from tnadeau-w2k.cisco.com (rtp-vpn2-889.cisco.com [10.82.243.121])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ACT90709;
	Tue, 18 Mar 2003 12:12:30 -0500 (EST)
Message-Id: <5.2.0.9.2.20030318121028.02c396c8@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 18 Mar 2003 12:12:04 -0500
To: "Adrian Farrel" <afarrel@movaz.com>, "'mpls@uu.net'" <mpls@UU.NET>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: Fw: draft-nadeau-ietf-oam-requirements-01.txt
In-Reply-To: <002701c2ed6c$ae76d730$d68a8182@movaz.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 11:37 AM 3/18/2003 -0500, Adrian Farrel wrote:
>Forwarding to WG mailing list.
>----- Original Message -----
>From: "Adrian Farrel" <afarrel@movaz.com>
>To: "Thomas D. Nadeau" <tnadeau@cisco.com>
>Cc: <mmorrow@cisco.com>; "George Swallow" <swallow@cisco.com>;
><dallan@nortelnetworks.com>
>Sent: Monday, March 17, 2003 7:13 PM
>Subject: draft-nadeau-ietf-oam-requirements-01.txt
>
>
> > Hi Tom,
> >
> > Can you add a requirement in 3.1 that detection mechanisms must not have an
> > "undue" impact on traffic (that is traffic when there is no error and 
> traffic
>on > other LSPs)

         This clarification is fine with me as long as we change
the "must" to a "should" and further clarify that it is okay to
impact performance in some cases, as some operators have
indicated that some performance impact is acceptable to them.

> >
> > Typos...
> > section 3
> > "relationships between providers has" read "have"
> >
> > section 3.1
> > "specified both w.r.t. with regard to" strike "w.r.t."
> >
> > section 3.2
> > "specify recovery actions in an" add "for" to read "specify recovery 
> actions
>for
> > in an"
> >
> > section 3.5
> > "the generation of superfluous generation of"
> > Self-defining text :-)
> >
> > sections 3.8 and 3.9 are not sections

         Cool. Thanks for the edits.  I will fix in the next
version.

         --Tom


> >
> > Cheers,
> > Adrian
> >
> >




From owner-mpls@UU.NET  Tue Mar 18 13:11:34 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21428
	for <mpls-archive@lists.ietf.org>; Tue, 18 Mar 2003 13:11:34 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogou21253
	for <mpls-archive@lists.ietf.org>; Tue, 18 Mar 2003 18:13:47 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogou20640;
	Tue, 18 Mar 2003 18:13:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogot19527
	for mpls-outgoing; Tue, 18 Mar 2003 17:48:05 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQogot19522
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Mar 2003 17:48:04 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQogot11758
	for <mpls@uu.net>; Tue, 18 Mar 2003 17:46:53 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogot04599
	for <mpls@uu.net>; Tue, 18 Mar 2003 17:46:52 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQogot04585
	for <mpls@uu.net>; Tue, 18 Mar 2003 17:46:52 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2IHc4Sc017295
	for <mpls@uu.net>; Tue, 18 Mar 2003 12:38:05 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA02294 for <mpls@uu.net>; Tue, 18 Mar 2003 12:38:04 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2IHc4P19553 for mpls@uu.net; Tue, 18 Mar 2003 12:38:04 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQogos18535
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Mar 2003 17:37:22 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQogos25161
	for <mpls@UU.NET>; Tue, 18 Mar 2003 17:36:47 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogos26174
	for <mpls@UU.NET>; Tue, 18 Mar 2003 17:36:47 GMT
Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQogos26150
	for <mpls@UU.NET>; Tue, 18 Mar 2003 17:36:46 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA49583;
	Tue, 18 Mar 2003 12:34:42 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303181734.MAA49583@workhorse.fictitious.org>
To: "Adrian Farrel" <afarrel@movaz.com>
cc: curtis@fictitious.org, "Jean Philippe Vasseur" <jvasseur@cisco.com>,
        "George Swallow" <swallow@cisco.com>, mrn@gblx.net, denver@gblx.net,
        jpv@cisco.com, "'mpls@uu.net'" <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: draft-meyer-soft-preemption-00.txt 
In-reply-to: Your message of "Tue, 18 Mar 2003 11:55:28 EST."
             <003501c2ed6f$3b708da0$d68a8182@movaz.com> 
Date: Tue, 18 Mar 2003 12:34:42 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <003501c2ed6f$3b708da0$d68a8182@movaz.com>, "Adrian Farrel" writes:
> 
> Are you sure there are no implementations out there that will tear down =
> the LSP because of an unrecognized flag in the RRO? :-)
> 
> Adrian


Based on our experience with the local-protect bits, there is an
implementation out there that we know will tear down the LSP because
of an unrecognized flag in the RRO but that same implementation will
send a path-err when it doesn't recongnize the capability request bits
in the session attributes flags so soft-preempt will be disabled.

Curtis



From owner-mpls@UU.NET  Tue Mar 18 16:07:30 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00251
	for <mpls-archive@lists.ietf.org>; Tue, 18 Mar 2003 16:07:30 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogpg16549
	for <mpls-archive@lists.ietf.org>; Tue, 18 Mar 2003 21:09:34 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogpg16126;
	Tue, 18 Mar 2003 21:09:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogpe27701
	for mpls-outgoing; Tue, 18 Mar 2003 20:42:53 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQogpe27696
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Mar 2003 20:42:42 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQogpe28178
	for <mpls@UU.NET>; Tue, 18 Mar 2003 20:42:40 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogpe14285
	for <mpls@UU.NET>; Tue, 18 Mar 2003 20:42:39 GMT
Received: from thurn.corp.titan.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: thurn.corp.titan.com [159.62.51.20])
	id QQogpe14274
	for <mpls@UU.NET>; Tue, 18 Mar 2003 20:42:39 GMT
Received: from vcmd-nt1.validity.com (val114-005.validity.titan.com [159.62.114.5])
	by thurn.corp.titan.com (8.12.8/8.12.8) with ESMTP id h2IKg1rF029792;
	Tue, 18 Mar 2003 12:42:03 -0800
Received: by VCMD-NT1 with Internet Mail Service (5.5.2655.55)
	id <HCMW70SV>; Tue, 18 Mar 2003 15:41:19 -0500
Message-ID: <561621C69F17D511A3A20050047340EC01AAF627@VCMD-NT1>
From: "Ferrell, William" <William.Ferrell@titan.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        Adrian Farrel
	 <afarrel@movaz.com>
Cc: Jean Philippe Vasseur <jvasseur@cisco.com>,
        George Swallow
	 <swallow@cisco.com>, mrn@gblx.net, denver@gblx.net,
        jpv@cisco.com, "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: draft-meyer-soft-preemption-00.txt 
Date: Tue, 18 Mar 2003 15:41:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Hmmm.. 
This sounds like a real vulnerabilty. Just how exploitable it is may be
worth further investigation.
Will

-----Original Message-----
From: Curtis Villamizar [mailto:curtis@fictitious.org]
Sent: Tuesday, March 18, 2003 12:35 PM
To: Adrian Farrel
Cc: curtis@fictitious.org; Jean Philippe Vasseur; George Swallow;
mrn@gblx.net; denver@gblx.net; jpv@cisco.com; 'mpls@uu.net'
Subject: Re: draft-meyer-soft-preemption-00.txt 



In message <003501c2ed6f$3b708da0$d68a8182@movaz.com>, "Adrian Farrel"
writes:
> 
> Are you sure there are no implementations out there that will tear down =
> the LSP because of an unrecognized flag in the RRO? :-)
> 
> Adrian


Based on our experience with the local-protect bits, there is an
implementation out there that we know will tear down the LSP because
of an unrecognized flag in the RRO but that same implementation will
send a path-err when it doesn't recongnize the capability request bits
in the session attributes flags so soft-preempt will be disabled.

Curtis


From owner-mpls@UU.NET  Tue Mar 18 16:21:59 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00557
	for <mpls-archive@lists.ietf.org>; Tue, 18 Mar 2003 16:21:58 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogph02214
	for <mpls-archive@lists.ietf.org>; Tue, 18 Mar 2003 21:24:13 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogph01870;
	Tue, 18 Mar 2003 21:23:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogpf29194
	for mpls-outgoing; Tue, 18 Mar 2003 20:57:52 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQogpf29174
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Mar 2003 20:57:47 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQogpf04996
	for <mpls@uu.net>; Tue, 18 Mar 2003 20:57:06 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogpf01384
	for <mpls@uu.net>; Tue, 18 Mar 2003 20:57:06 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQogpf01371
	for <mpls@uu.net>; Tue, 18 Mar 2003 20:57:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2IKv2Sc024041
	for <mpls@uu.net>; Tue, 18 Mar 2003 15:57:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA19791 for <mpls@uu.net>; Tue, 18 Mar 2003 15:57:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2IKv2w01401 for mpls@uu.net; Tue, 18 Mar 2003 15:57:02 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQogpf28949
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Mar 2003 20:55:41 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQogpf16757
	for <mpls@UU.NET>; Tue, 18 Mar 2003 20:54:04 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogpf27809
	for <mpls@UU.NET>; Tue, 18 Mar 2003 20:54:03 GMT
Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQogpf27802
	for <mpls@UU.NET>; Tue, 18 Mar 2003 20:54:03 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA52980;
	Tue, 18 Mar 2003 15:51:54 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303182051.PAA52980@workhorse.fictitious.org>
To: "Ferrell, William" <William.Ferrell@titan.com>
cc: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        Adrian Farrel <afarrel@movaz.com>,
        Jean Philippe Vasseur <jvasseur@cisco.com>,
        George Swallow <swallow@cisco.com>, mrn@gblx.net, denver@gblx.net,
        jpv@cisco.com, "'mpls@uu.net'" <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: draft-meyer-soft-preemption-00.txt 
In-reply-to: Your message of "Tue, 18 Mar 2003 15:41:17 EST."
             <561621C69F17D511A3A20050047340EC01AAF627@VCMD-NT1> 
Date: Tue, 18 Mar 2003 15:51:54 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <561621C69F17D511A3A20050047340EC01AAF627@VCMD-NT1>, "Ferrell, Willi
am" writes:
> Hmmm.. 
> This sounds like a real vulnerabilty. Just how exploitable it is may be
> worth further investigation.
> Will


This is just a matter of disabling a feature.  In the case of
local-protect, interoperability is acheived by not setting the
local-protect bits.  It is also an implementation that pre-dates the
current fast-reroute draft and this behaviour wrt at least the
local-protect bits is going away.

At worst with the current situation and lacking a work around fast
reroute protection would be defeated.  Considering that this is
pre-standards (deployed though) for FRR, some incompatibilities
between vendors can bw expected as implementations converge on a
common specification.

With soft-preempt, at worst an LSP which is being preempted gets torn
down so in effect soft preempt doesn't work with a particular midpoint
LSR that doesn't support it.

Not much of an exploit in either case.

Curtis


> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@fictitious.org]
> Sent: Tuesday, March 18, 2003 12:35 PM
> To: Adrian Farrel
> Cc: curtis@fictitious.org; Jean Philippe Vasseur; George Swallow;
> mrn@gblx.net; denver@gblx.net; jpv@cisco.com; 'mpls@uu.net'
> Subject: Re: draft-meyer-soft-preemption-00.txt 
> 
> 
> 
> In message <003501c2ed6f$3b708da0$d68a8182@movaz.com>, "Adrian Farrel"
> writes:
> > 
> > Are you sure there are no implementations out there that will tear down =
> > the LSP because of an unrecognized flag in the RRO? :-)
> > 
> > Adrian
> 
> 
> Based on our experience with the local-protect bits, there is an
> implementation out there that we know will tear down the LSP because
> of an unrecognized flag in the RRO but that same implementation will
> send a path-err when it doesn't recongnize the capability request bits
> in the session attributes flags so soft-preempt will be disabled.
> 
> Curtis
> 



From owner-mpls@UU.NET  Tue Mar 18 17:34:22 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03206
	for <mpls-archive@lists.ietf.org>; Tue, 18 Mar 2003 17:34:22 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogpm12347
	for <mpls-archive@lists.ietf.org>; Tue, 18 Mar 2003 22:36:37 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogpm11818;
	Tue, 18 Mar 2003 22:36:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogpk11067
	for mpls-outgoing; Tue, 18 Mar 2003 22:09:58 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQogpk11062
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Mar 2003 22:09:55 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQogpk15869
	for <mpls@UU.NET>; Tue, 18 Mar 2003 22:09:34 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogpk23166
	for <mpls@UU.NET>; Tue, 18 Mar 2003 22:09:34 GMT
Received: from zcars0m9.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157])
	id QQogpk23154
	for <mpls@UU.NET>; Tue, 18 Mar 2003 22:09:33 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2IM9Rx02400
	for <mpls@UU.NET>; Tue, 18 Mar 2003 17:09:27 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <GDF4Y7CB>; Tue, 18 Mar 2003 17:09:27 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D016D2B70@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: mpls@UU.NET
Subject: Presentation URLs
Date: Tue, 18 Mar 2003 17:09:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2ED9B.0A2E4AF8"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2ED9B.0A2E4AF8
Content-Type: text/plain;
	charset="iso-8859-1"

At the end of my presentation on Y.1711 and LSP-PING today I posted some
URLs for tutorial information on the FEC-CV extensions for Y.1711.

Unfortunately the pdf isn't working properly, and will be corrected shortly.
The powerpoint works fine.

http://standards.nortelnetworks.com/y.1711_fec_cv_public.ppt

cheers
Dave

------_=_NextPart_001_01C2ED9B.0A2E4AF8
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>Presentation URLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>At the end of my presentation on Y.1711 and LSP-PING =
today I posted some URLs for tutorial information on the FEC-CV =
extensions for Y.1711.</FONT></P>

<P><FONT SIZE=3D2>Unfortunately the pdf isn't working properly, and =
will be corrected shortly. The powerpoint works fine.</FONT>
</P>

<P><FONT SIZE=3D2><A =
HREF=3D"http://standards.nortelnetworks.com/y.1711_fec_cv_public.ppt" =
TARGET=3D"_blank">http://standards.nortelnetworks.com/y.1711_fec_cv_publ=
ic.ppt</A></FONT>
</P>

<P><FONT SIZE=3D2>cheers</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2ED9B.0A2E4AF8--


From owner-mpls@UU.NET  Tue Mar 18 21:33:44 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12588
	for <mpls-archive@lists.ietf.org>; Tue, 18 Mar 2003 21:33:44 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogqc21006
	for <mpls-archive@lists.ietf.org>; Wed, 19 Mar 2003 02:35:48 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogqc20121;
	Wed, 19 Mar 2003 02:35:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogqa12195
	for mpls-outgoing; Wed, 19 Mar 2003 02:10:05 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQogqa12172
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Mar 2003 02:10:03 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQogqa00729
	for <mpls@uu.net>; Wed, 19 Mar 2003 02:08:21 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogqa03586
	for <mpls@uu.net>; Wed, 19 Mar 2003 02:08:21 GMT
Received: from kanmx1.ca.alcatel.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: m115-138.on.tac.net [209.202.115.138] (may be forged))
	id QQogqa03553
	for <mpls@uu.net>; Wed, 19 Mar 2003 02:08:20 GMT
Received: (qmail 4513 invoked from network); 19 Mar 2003 02:16:14 -0000
Received: from unknown (HELO camail03.ca.alcatel.com) (138.120.105.217)
  by kanmx1.ca.alcatel.com with SMTP; 19 Mar 2003 02:16:14 -0000
Received: from alcatel.com ([138.120.250.4]) by
          camail03.ca.alcatel.com (Netscape Messaging Server 4.15) with
          ESMTP id HBZ4LV00.D6D; Tue, 18 Mar 2003 21:08:19 -0500 
Message-ID: <3E77D0EB.D11CBFCB@alcatel.com>
Date: Tue, 18 Mar 2003 21:07:39 -0500
From: "Cheng-Yin Lee" <Cheng-Yin.Lee@alcatel.com>
Reply-To: Cheng-Yin.Lee@alcatel.com
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bhaskara Peela <bhaskarap@mail.com>
CC: mpls@UU.NET, ccamp@ops.ietf.org
Subject: Re: Inter-area cspf
References: <20030318200600.28070.qmail@mail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Bhaskara,
Regarding (2) & (3), my understanding is a more distributed approach
described in draft-lee-ccamp-exclude-route more preferable than the
"Path Computation Entity" approach in (3).
You may want to take a look at this draft which will be presented by
Adrian Farrel in CCAMP WG meeting on Wednesday. It is not limited to
inter-area only (and does not address IGP-TE LSA flooding).

Regards,
Cheng-Yin

Bhaskara Peela wrote:
> 
> [ post by non-subscriber.  with the massive amount of spam, it is easy to miss
>   and therefore delete posts by non-subscribers.  if you wish to regularly
>   post from an address that is not subscribed to this mailing list, send a
>   message to <listname>-owner@ops.ietf.org and ask to have the alternate
>   address added to the list of addresses from which submissions are
>   automatically accepted. ]
> 
> Hi,
> 
> Can any one update me about the status of following drafts
> 
> 1)draft-ash-ccamp-multi-area-te-reqmts-00.txt
> 2)draft-lee-mpls-te-exchange-00.txt
> 3)draft-lee-mpls-path-request-00.txt
> 4)draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt
> 
> I would like to know what is the latest ongoing standadization process for inter-area OSPF-TE LSA flooding
> for CSPF calculation for GMPLS or MPLS.
> 
> thank you
> bhaskara
> --
> __________________________________________________________
> Sign-up for your own FREE Personalized E-mail at Mail.com
> http://www.mail.com/?sr=signup


From owner-mpls@UU.NET  Wed Mar 19 03:37:02 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16087
	for <mpls-archive@lists.ietf.org>; Wed, 19 Mar 2003 03:37:02 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogra07469
	for <mpls-archive@lists.ietf.org>; Wed, 19 Mar 2003 08:39:16 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogra07233;
	Wed, 19 Mar 2003 08:39:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogqy29676
	for mpls-outgoing; Wed, 19 Mar 2003 08:13:44 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQogqy29671
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Mar 2003 08:13:29 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQogqy13169
	for <mpls@uu.net>; Wed, 19 Mar 2003 08:13:06 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogqy07228
	for <mpls@uu.net>; Wed, 19 Mar 2003 08:13:06 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQogqy07209
	for <mpls@uu.net>; Wed, 19 Mar 2003 08:13:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2J8D2vD010709
	for <mpls@uu.net>; Wed, 19 Mar 2003 03:13:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id DAA28526 for <mpls@uu.net>; Wed, 19 Mar 2003 03:13:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2J8D1u05755 for mpls@uu.net; Wed, 19 Mar 2003 03:13:01 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQogqy29644
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Mar 2003 08:12:04 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQogqy15013
	for <mpls@uu.net>; Wed, 19 Mar 2003 08:12:03 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogqy06284
	for <mpls@uu.net>; Wed, 19 Mar 2003 08:12:03 GMT
Received: from ams-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ams-msg-core-1.cisco.com [144.254.74.60])
	id QQogqy06272
	for <mpls@uu.net>; Wed, 19 Mar 2003 08:12:02 GMT
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2J89a5u021765;
	Wed, 19 Mar 2003 09:09:36 +0100 (MET)
Received: from JVASSEUR-W2K.cisco.com (sjck-dial-gw5-47.cisco.com [10.19.238.48])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA05179;
	Wed, 19 Mar 2003 09:11:15 +0100 (MET)
Message-Id: <4.3.2.7.2.20030319000719.03c79948@paris.cisco.com>
X-Sender: jvasseur@paris.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 19 Mar 2003 00:11:12 -0800
To: "Bhaskara Peela" <bhaskarap@mail.com>
From: Jean Philippe Vasseur <jvasseur@cisco.com>
Subject: Re: Inter-area cspf
Cc: mpls@UU.NET, ccamp@ops.ietf.org
In-Reply-To: <20030318200600.28070.qmail@mail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

FYI, if you're interested by multi-area TE, you might want to consider:
- http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.txt
For PCS-PCC signalling (scenarios 2,4 and 5 on of the previous draft) see:
http://www.ietf.org/internet-drafts/draft-vasseur-mpls-computation-rsvp-03.txt

JP.

At 15:06 18/03/2003 -0500, Bhaskara Peela wrote:
>[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
>   and therefore delete posts by non-subscribers.  if you wish to regularly
>   post from an address that is not subscribed to this mailing list, send a
>   message to <listname>-owner@ops.ietf.org and ask to have the alternate
>   address added to the list of addresses from which submissions are
>   automatically accepted. ]
>
>Hi,
>
>Can any one update me about the status of following drafts
>
>1)draft-ash-ccamp-multi-area-te-reqmts-00.txt
>2)draft-lee-mpls-te-exchange-00.txt
>3)draft-lee-mpls-path-request-00.txt
>4)draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt
>
>I would like to know what is the latest ongoing standadization process for 
>inter-area OSPF-TE LSA flooding
>for CSPF calculation for GMPLS or MPLS.
>
>thank you
>bhaskara
>--
>__________________________________________________________
>Sign-up for your own FREE Personalized E-mail at Mail.com
>http://www.mail.com/?sr=signup



From owner-mpls@UU.NET  Wed Mar 19 14:00:00 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00879
	for <mpls-archive@lists.ietf.org>; Wed, 19 Mar 2003 14:00:00 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogsq13281
	for <mpls-archive@lists.ietf.org>; Wed, 19 Mar 2003 19:02:14 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogsq12850;
	Wed, 19 Mar 2003 19:01:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogso17942
	for mpls-outgoing; Wed, 19 Mar 2003 18:36:49 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQogso17935
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Mar 2003 18:36:33 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQogso12750
	for <mpls@uu.net>; Wed, 19 Mar 2003 18:35:31 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogso16499
	for <mpls@uu.net>; Wed, 19 Mar 2003 18:35:31 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQogso16494
	for <mpls@uu.net>; Wed, 19 Mar 2003 18:35:30 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2JIZOvD020886
	for <mpls@uu.net>; Wed, 19 Mar 2003 13:35:28 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA06830 for <mpls@uu.net>; Wed, 19 Mar 2003 13:35:24 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2JIZOU05027 for mpls@uu.net; Wed, 19 Mar 2003 13:35:24 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQogso17692
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Mar 2003 18:34:06 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQogso00611
	for <mpls@uu.net>; Wed, 19 Mar 2003 18:33:48 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogso08029
	for <mpls@uu.net>; Wed, 19 Mar 2003 18:33:47 GMT
Received: from ams-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ams-msg-core-1.cisco.com [144.254.74.60])
	id QQogso08010
	for <mpls@uu.net>; Wed, 19 Mar 2003 18:33:47 GMT
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2JIRi7u011320;
	Wed, 19 Mar 2003 19:27:44 +0100 (MET)
Received: from JVASSEUR-W2K.cisco.com (sjc-vpn3-214.cisco.com [10.21.64.214])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id TAA06734;
	Wed, 19 Mar 2003 19:29:25 +0100 (MET)
Message-Id: <4.3.2.7.2.20030319102706.0427dd80@paris.cisco.com>
X-Sender: jvasseur@paris.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 19 Mar 2003 10:29:22 -0800
To: "Bhaskara Peela" <bhaskarap@mail.com>
From: Jean Philippe Vasseur <jvasseur@cisco.com>
Subject: RE: Inter-area cspf
Cc: mpls@UU.NET, ccamp@ops.ietf.org
In-Reply-To: <20030319021320.36869.qmail@mail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Fully on Yakov's side on this comment. I personally do not see any 
requirement for additional routing protocols extension for multi-area TE.

JP.

At 21:13 18/03/2003 -0500, Bhaskara Peela wrote:
>[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
>   and therefore delete posts by non-subscribers.  if you wish to regularly
>   post from an address that is not subscribed to this mailing list, send a
>   message to <listname>-owner@ops.ietf.org and ask to have the alternate
>   address added to the list of addresses from which submissions are
>   automatically accepted. ]
>
>Hi,
>
>Mailing list archive points me to the following message regarding 
>inter/multi area CSPF by Yokov.
>
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:yakov@juniper.net]
> > Sent: Sunday, December 22, 2002 6:29 AM
> > To: srisuresh@yahoo.com
> > Cc: ietf@ietf.org; iesg@ietf.org
> > Subject: Re: Last Call: Traffic Engineering Extensions to OSPF Version 2
> > to Proposed Standard
> >
> >
> > Suresh,
> >
> > > > > My recommendation against using this draft as the basis for
> > > > > building further TE-extensions to inter-area and mixed networks
> > > > > was in the context of OSPF Autonomous System (AS). I also
> > > > > mentioned the draft has scalability limitations in extending this
> > > > > to inter-area and mixed networks -  also in the context of OSPF AS.
> > > > >
> > > > > Without going into the details of the "Multi-area MPLS Traffic
> > > > > Enginering" draft - The work cited in this draft as going on to
> > > > > address multi-area TE is in the MPLS signalling context, not in
> > > > > the OSPF.
> > > >
> > > > As I said in my previous e-mail quite a few scenarios described in
> > > > draft-kompella-mpls-multiarea-te-03.txt are supported with the TE
> > > > extensions that are subject to this Last Call. That is precisely
> > > > while quite a few scenarios in the "Multi-area MPLS Traffic
> > Engineering"
> > > > draft do not require any additions to what is already defined
> > > > in the katz-yeung draft.
> > > >
> > > > Yakov.
> > >
>
>Does this mean to suggest inter-area constraint based path computation 
>should follow ideas presented in draft-kompella-mpls-multiarea-te-03.txt 
>and draft-katz-yeung-ospf-traffic-09.txt ?  Or is there any active 
>alternate process going on.  Can any one update this issue.
>
>thank you
>bhaskara
>
>-----Original Message-----
>From: Bhaskara Peela [mailto:bhaskarap@mail.com]
>Sent: Tuesday, March 18, 2003 12:06 PM
>To: mpls@uu.net
>Cc: ccamp@ops.ietf.org
>Subject: Inter-area cspf
>
>
>[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
>   and therefore delete posts by non-subscribers.  if you wish to regularly
>   post from an address that is not subscribed to this mailing list, send a
>   message to <listname>-owner@ops.ietf.org and ask to have the alternate
>   address added to the list of addresses from which submissions are
>   automatically accepted. ]
>
>Hi,
>
>Can any one update me about the status of following drafts
>
>1)draft-ash-ccamp-multi-area-te-reqmts-00.txt
>2)draft-lee-mpls-te-exchange-00.txt
>3)draft-lee-mpls-path-request-00.txt
>4)draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt
>
>I would like to know what is the latest ongoing standadization process for 
>inter-area OSPF-TE LSA flooding
>for CSPF calculation for GMPLS or MPLS.
>
>thank you
>bhaskara
>--
>__________________________________________________________
>Sign-up for your own FREE Personalized E-mail at Mail.com
>http://www.mail.com/?sr=signup



From owner-mpls@UU.NET  Wed Mar 19 14:57:27 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03792
	for <mpls-archive@lists.ietf.org>; Wed, 19 Mar 2003 14:57:27 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogst24187
	for <mpls-archive@lists.ietf.org>; Wed, 19 Mar 2003 19:59:40 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogst23555;
	Wed, 19 Mar 2003 19:59:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogsq09702
	for mpls-outgoing; Wed, 19 Mar 2003 19:12:51 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQogsq09674
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Mar 2003 19:12:45 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQogsq29391
	for <mpls@uu.net>; Wed, 19 Mar 2003 19:12:41 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogsq24549
	for <mpls@uu.net>; Wed, 19 Mar 2003 19:12:40 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQogsq24522
	for <mpls@uu.net>; Wed, 19 Mar 2003 19:12:40 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2JJCaSc009173
	for <mpls@uu.net>; Wed, 19 Mar 2003 14:12:36 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA11216 for <mpls@uu.net>; Wed, 19 Mar 2003 14:12:36 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2JJCa509262 for mpls@uu.net; Wed, 19 Mar 2003 14:12:36 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQogqe06386
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Mar 2003 03:11:33 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQogqe15630
	for <mpls@uu.net>; Wed, 19 Mar 2003 03:11:00 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogqe25759
	for <mpls@uu.net>; Wed, 19 Mar 2003 03:10:59 GMT
Received: from spf1.us.outblaze.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: 205-158-62-158.outblaze.com [205.158.62.158])
	id QQogqe25733
	for <mpls@uu.net>; Wed, 19 Mar 2003 03:10:58 GMT
Received: (qmail 30228 invoked from network); 19 Mar 2003 03:10:16 -0000
Received: from unknown (205.158.62.68)
  by spf1.us.outblaze.com with QMQP; 19 Mar 2003 03:10:16 -0000
Received: (qmail 82328 invoked from network); 19 Mar 2003 03:09:54 -0000
Received: from unknown (HELO ws1-2.us4.outblaze.com) (205.158.62.54)
  by 205-158-62-153.outblaze.com with SMTP; 19 Mar 2003 03:09:54 -0000
Received: (qmail 49062 invoked by uid 1001); 19 Mar 2003 03:09:53 -0000
Message-ID: <20030319030953.49061.qmail@mail.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-Mailer: MIME-tools 5.41 (Entity 5.404)
Received: from [63.197.247.13] by ws1-2.us4.outblaze.com with http for
    bhaskarap@mail.com; Tue, 18 Mar 2003 22:09:53 -0500
From: "Bhaskara Peela" <bhaskarap@mail.com>
To: Cheng-Yin.Lee@alcatel.com, bhaskarap@mail.com
Cc: mpls@UU.NET, ccamp@ops.ietf.org
Date: Tue, 18 Mar 2003 22:09:53 -0500
Subject: Re: Inter-area cspf
X-Originating-Ip: 63.197.247.13
X-Originating-Server: ws1-2.us4.outblaze.com
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Cheng-Yin Lee" <Cheng-Yin.Lee@alcatel.com>
Date: Tue, 18 Mar 2003 21:07:39 -0500
To: Bhaskara Peela <bhaskarap@mail.com>
Subject: Re: Inter-area cspf

> Bhaskara,
> Regarding (2) & (3), my understanding is a more distributed approach
> described in draft-lee-ccamp-exclude-route more preferable than the
> "Path Computation Entity" approach in (3).
> You may want to take a look at this draft which will be presented by
> Adrian Farrel in CCAMP WG meeting on Wednesday. It is not limited to
> inter-area only (and does not address IGP-TE LSA flooding).
> 
> Regards,
> Cheng-Yin
> 
> Bhaskara Peela wrote:
> > 
> > [ post by non-subscriber.  with the massive amount of spam, it is easy to miss
> >   and therefore delete posts by non-subscribers.  if you wish to regularly
> >   post from an address that is not subscribed to this mailing list, send a
> >   message to <listname>-owner@ops.ietf.org and ask to have the alternate
> >   address added to the list of addresses from which submissions are
> >   automatically accepted. ]
> > 
> > Hi,
> > 
> > Can any one update me about the status of following drafts
> > 
> > 1)draft-ash-ccamp-multi-area-te-reqmts-00.txt
> > 2)draft-lee-mpls-te-exchange-00.txt
> > 3)draft-lee-mpls-path-request-00.txt
> > 4)draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt
> > 
> > I would like to know what is the latest ongoing standadization process for inter-area OSPF-TE LSA flooding
> > for CSPF calculation for GMPLS or MPLS.
> > 
> > thank you
> > bhaskara
> > --
> > __________________________________________________________
> > Sign-up for your own FREE Personalized E-mail at Mail.com
> > http://www.mail.com/?sr=signup

-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup



From owner-mpls@UU.NET  Wed Mar 19 14:58:10 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03819
	for <mpls-archive@lists.ietf.org>; Wed, 19 Mar 2003 14:58:10 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogsu23361
	for <mpls-archive@lists.ietf.org>; Wed, 19 Mar 2003 20:00:24 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogst22372;
	Wed, 19 Mar 2003 19:59:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogsq09751
	for mpls-outgoing; Wed, 19 Mar 2003 19:13:12 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQogsq09742
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Mar 2003 19:13:01 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQogsq06344
	for <mpls@uu.net>; Wed, 19 Mar 2003 19:11:45 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogsq23432
	for <mpls@uu.net>; Wed, 19 Mar 2003 19:11:44 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQogsq23423
	for <mpls@uu.net>; Wed, 19 Mar 2003 19:11:44 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2JJBevD024487
	for <mpls@uu.net>; Wed, 19 Mar 2003 14:11:41 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA11127 for <mpls@uu.net>; Wed, 19 Mar 2003 14:11:40 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2JJBeh09205 for mpls@uu.net; Wed, 19 Mar 2003 14:11:40 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQogpc24567
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Mar 2003 20:07:32 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQogpc11857
	for <mpls@uu.net>; Tue, 18 Mar 2003 20:06:23 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogpc13400
	for <mpls@uu.net>; Tue, 18 Mar 2003 20:06:22 GMT
Received: from spf1.us.outblaze.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: 205-158-62-158.outblaze.com [205.158.62.158])
	id QQogpc13382
	for <mpls@uu.net>; Tue, 18 Mar 2003 20:06:21 GMT
Received: (qmail 17175 invoked from network); 18 Mar 2003 20:05:36 -0000
Received: from unknown (205.158.62.68)
  by spf1.us.outblaze.com with QMQP; 18 Mar 2003 20:05:36 -0000
Received: (qmail 82368 invoked from network); 18 Mar 2003 20:06:04 -0000
Received: from unknown (HELO ws1-10.us4.outblaze.com) (205.158.62.111)
  by 205-158-62-153.outblaze.com with SMTP; 18 Mar 2003 20:06:04 -0000
Received: (qmail 28071 invoked by uid 1001); 18 Mar 2003 20:06:00 -0000
Message-ID: <20030318200600.28070.qmail@mail.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-Mailer: MIME-tools 5.41 (Entity 5.404)
Received: from [63.197.247.13] by ws1-10.us4.outblaze.com with http for
    bhaskarap@mail.com; Tue, 18 Mar 2003 15:06:00 -0500
From: "Bhaskara Peela" <bhaskarap@mail.com>
To: mpls@UU.NET
Cc: ccamp@ops.ietf.org
Date: Tue, 18 Mar 2003 15:06:00 -0500
Subject: Inter-area cspf
X-Originating-Ip: 63.197.247.13
X-Originating-Server: ws1-10.us4.outblaze.com
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

Can any one update me about the status of following drafts

1)draft-ash-ccamp-multi-area-te-reqmts-00.txt
2)draft-lee-mpls-te-exchange-00.txt
3)draft-lee-mpls-path-request-00.txt
4)draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt

I would like to know what is the latest ongoing standadization process for inter-area OSPF-TE LSA flooding
for CSPF calculation for GMPLS or MPLS.

thank you
bhaskara
-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup



From owner-mpls@UU.NET  Wed Mar 19 14:58:13 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03837
	for <mpls-archive@lists.ietf.org>; Wed, 19 Mar 2003 14:58:13 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogsu23465
	for <mpls-archive@lists.ietf.org>; Wed, 19 Mar 2003 20:00:27 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogst22464;
	Wed, 19 Mar 2003 19:59:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogsq09772
	for mpls-outgoing; Wed, 19 Mar 2003 19:13:31 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQogsq09765
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Mar 2003 19:13:27 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQogsq26690
	for <mpls@uu.net>; Wed, 19 Mar 2003 19:12:25 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogsq24188
	for <mpls@uu.net>; Wed, 19 Mar 2003 19:12:25 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQogsq24182
	for <mpls@uu.net>; Wed, 19 Mar 2003 19:12:24 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2JJCLvD024538
	for <mpls@uu.net>; Wed, 19 Mar 2003 14:12:21 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA11197 for <mpls@uu.net>; Wed, 19 Mar 2003 14:12:21 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2JJCLQ09258 for mpls@uu.net; Wed, 19 Mar 2003 14:12:21 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQogqa12940
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Mar 2003 02:14:01 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQogqa07494
	for <mpls@uu.net>; Wed, 19 Mar 2003 02:13:39 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogqa13217
	for <mpls@uu.net>; Wed, 19 Mar 2003 02:13:38 GMT
Received: from spf1.us.outblaze.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: 205-158-62-158.outblaze.com [205.158.62.158])
	id QQogqa13184
	for <mpls@uu.net>; Wed, 19 Mar 2003 02:13:37 GMT
Received: (qmail 32653 invoked from network); 19 Mar 2003 02:12:46 -0000
Received: from unknown (205.158.62.68)
  by spf1.us.outblaze.com with QMQP; 19 Mar 2003 02:12:46 -0000
Received: (qmail 30603 invoked from network); 19 Mar 2003 02:13:21 -0000
Received: from unknown (HELO ws1-4.us4.outblaze.com) (205.158.62.50)
  by 205-158-62-153.outblaze.com with SMTP; 19 Mar 2003 02:13:20 -0000
Received: (qmail 36870 invoked by uid 1001); 19 Mar 2003 02:13:20 -0000
Message-ID: <20030319021320.36869.qmail@mail.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-Mailer: MIME-tools 5.41 (Entity 5.404)
Received: from [63.197.247.13] by ws1-4.us4.outblaze.com with http for
    bhaskarap@mail.com; Tue, 18 Mar 2003 21:13:19 -0500
From: "Bhaskara Peela" <bhaskarap@mail.com>
To: mpls@UU.NET
Cc: ccamp@ops.ietf.org
Date: Tue, 18 Mar 2003 21:13:19 -0500
Subject: RE: Inter-area cspf
X-Originating-Ip: 63.197.247.13
X-Originating-Server: ws1-4.us4.outblaze.com
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

Mailing list archive points me to the following message regarding inter/multi area CSPF by Yokov.  

> -----Original Message-----
> From: Yakov Rekhter [mailto:yakov@juniper.net]
> Sent: Sunday, December 22, 2002 6:29 AM
> To: srisuresh@yahoo.com
> Cc: ietf@ietf.org; iesg@ietf.org
> Subject: Re: Last Call: Traffic Engineering Extensions to OSPF Version 2
> to Proposed Standard
>
>
> Suresh,
>
> > > > My recommendation against using this draft as the basis for
> > > > building further TE-extensions to inter-area and mixed networks
> > > > was in the context of OSPF Autonomous System (AS). I also
> > > > mentioned the draft has scalability limitations in extending this
> > > > to inter-area and mixed networks -  also in the context of OSPF AS.
> > > >
> > > > Without going into the details of the "Multi-area MPLS Traffic
> > > > Enginering" draft - The work cited in this draft as going on to
> > > > address multi-area TE is in the MPLS signalling context, not in
> > > > the OSPF.
> > >
> > > As I said in my previous e-mail quite a few scenarios described in
> > > draft-kompella-mpls-multiarea-te-03.txt are supported with the TE
> > > extensions that are subject to this Last Call. That is precisely
> > > while quite a few scenarios in the "Multi-area MPLS Traffic
> Engineering"
> > > draft do not require any additions to what is already defined
> > > in the katz-yeung draft.
> > >
> > > Yakov.
> >

Does this mean to suggest inter-area constraint based path computation should follow ideas presented in draft-kompella-mpls-multiarea-te-03.txt and draft-katz-yeung-ospf-traffic-09.txt ?  Or is there any active alternate process going on.  Can any one update this issue.

thank you
bhaskara

-----Original Message-----
From: Bhaskara Peela [mailto:bhaskarap@mail.com]
Sent: Tuesday, March 18, 2003 12:06 PM
To: mpls@uu.net
Cc: ccamp@ops.ietf.org
Subject: Inter-area cspf


[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner@ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Hi,

Can any one update me about the status of following drafts

1)draft-ash-ccamp-multi-area-te-reqmts-00.txt
2)draft-lee-mpls-te-exchange-00.txt
3)draft-lee-mpls-path-request-00.txt
4)draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt

I would like to know what is the latest ongoing standadization process for inter-area OSPF-TE LSA flooding
for CSPF calculation for GMPLS or MPLS.

thank you
bhaskara
-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup



From owner-mpls@UU.NET  Wed Mar 19 14:59:00 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03877
	for <mpls-archive@lists.ietf.org>; Wed, 19 Mar 2003 14:58:59 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogsu08181
	for <mpls-archive@lists.ietf.org>; Wed, 19 Mar 2003 20:01:12 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogsu06418;
	Wed, 19 Mar 2003 20:00:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogsq09852
	for mpls-outgoing; Wed, 19 Mar 2003 19:14:56 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQogsq09841
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Mar 2003 19:14:49 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQogsq28727
	for <mpls@uu.net>; Wed, 19 Mar 2003 19:13:00 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogsq24880
	for <mpls@uu.net>; Wed, 19 Mar 2003 19:12:59 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQogsq24870
	for <mpls@uu.net>; Wed, 19 Mar 2003 19:12:59 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2JJCtvD024584
	for <mpls@uu.net>; Wed, 19 Mar 2003 14:12:56 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA11264 for <mpls@uu.net>; Wed, 19 Mar 2003 14:12:55 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2JJCsa09268 for mpls@uu.net; Wed, 19 Mar 2003 14:12:54 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQogqe06401
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Mar 2003 03:12:19 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQogqe14935
	for <mpls@uu.net>; Wed, 19 Mar 2003 03:10:01 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogqe23950
	for <mpls@uu.net>; Wed, 19 Mar 2003 03:10:00 GMT
Received: from spf1.us.outblaze.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: 205-158-62-158.outblaze.com [205.158.62.158])
	id QQogqe23912
	for <mpls@uu.net>; Wed, 19 Mar 2003 03:09:59 GMT
Received: (qmail 28437 invoked from network); 19 Mar 2003 03:09:12 -0000
Received: from unknown (205.158.62.68)
  by spf1.us.outblaze.com with QMQP; 19 Mar 2003 03:09:12 -0000
Received: (qmail 77124 invoked from network); 19 Mar 2003 03:09:14 -0000
Received: from unknown (HELO ws1-2.us4.outblaze.com) (205.158.62.54)
  by 205-158-62-153.outblaze.com with SMTP; 19 Mar 2003 03:09:14 -0000
Received: (qmail 48540 invoked by uid 1001); 19 Mar 2003 03:09:14 -0000
Message-ID: <20030319030914.48539.qmail@mail.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-Mailer: MIME-tools 5.41 (Entity 5.404)
Received: from [63.197.247.13] by ws1-2.us4.outblaze.com with http for
    bhaskarap@mail.com; Tue, 18 Mar 2003 22:09:14 -0500
From: "Bhaskara Peela" <bhaskarap@mail.com>
To: Cheng-Yin.Lee@alcatel.com, bhaskarap@mail.com
Cc: mpls@UU.NET, ccamp@ops.ietf.org
Date: Tue, 18 Mar 2003 22:09:14 -0500
Subject: Re: Inter-area cspf
X-Originating-Ip: 63.197.247.13
X-Originating-Server: ws1-2.us4.outblaze.com
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Cheng-Yin,

Thank you for mail.

The draft-lee-ccamp-rsvp-te-exclude-route-02.txt does only
address issues for establishing LSPs based on SRLG for different protection/divergent mechanisms.  But, to specify a SRLG/XRO/EXRS, we need to first know  or populate the TE database  across OSPF areas and AS domains.  It does not address how this SRLG can be specified or how the divergence of LSPs for protection is achived in case of inter-area or inter-domain.  Are u suggesting this information can be drawn from draft-lee-mpls-path-request-04.txt.

Please clarify.

thank you
bhaskara
----- Original Message -----
From: "Cheng-Yin Lee" <Cheng-Yin.Lee@alcatel.com>
Date: Tue, 18 Mar 2003 21:07:39 -0500
To: Bhaskara Peela <bhaskarap@mail.com>
Subject: Re: Inter-area cspf

> Bhaskara,
> Regarding (2) & (3), my understanding is a more distributed approach
> described in draft-lee-ccamp-exclude-route more preferable than the
> "Path Computation Entity" approach in (3).
> You may want to take a look at this draft which will be presented by
> Adrian Farrel in CCAMP WG meeting on Wednesday. It is not limited to
> inter-area only (and does not address IGP-TE LSA flooding).
> 
> Regards,
> Cheng-Yin
> 
> Bhaskara Peela wrote:
> > 
> > [ post by non-subscriber.  with the massive amount of spam, it is easy to miss
> >   and therefore delete posts by non-subscribers.  if you wish to regularly
> >   post from an address that is not subscribed to this mailing list, send a
> >   message to <listname>-owner@ops.ietf.org and ask to have the alternate
> >   address added to the list of addresses from which submissions are
> >   automatically accepted. ]
> > 
> > Hi,
> > 
> > Can any one update me about the status of following drafts
> > 
> > 1)draft-ash-ccamp-multi-area-te-reqmts-00.txt
> > 2)draft-lee-mpls-te-exchange-00.txt
> > 3)draft-lee-mpls-path-request-00.txt
> > 4)draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt
> > 
> > I would like to know what is the latest ongoing standadization process for inter-area OSPF-TE LSA flooding
> > for CSPF calculation for GMPLS or MPLS.
> > 
> > thank you
> > bhaskara
> > --
> > __________________________________________________________
> > Sign-up for your own FREE Personalized E-mail at Mail.com
> > http://www.mail.com/?sr=signup

-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup



From owner-mpls@UU.NET  Thu Mar 20 12:28:20 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26069
	for <mpls-archive@lists.ietf.org>; Thu, 20 Mar 2003 12:28:19 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoguy10478
	for <mpls-archive@lists.ietf.org>; Thu, 20 Mar 2003 10:09:20 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoguy10112;
	Thu, 20 Mar 2003 10:09:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoguw00593
	for mpls-outgoing; Thu, 20 Mar 2003 09:43:40 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoguw00579
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 20 Mar 2003 09:43:26 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoguw20858
	for <mpls@UU.NET>; Thu, 20 Mar 2003 09:42:42 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoguw23753
	for <mpls@UU.NET>; Thu, 20 Mar 2003 09:42:41 GMT
Received: from tiger.seabridge.co.il by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: bzq-25-127-226.cust.bezeqint.net [212.25.127.226])
	id QQoguw23737
	for <mpls@UU.NET>; Thu, 20 Mar 2003 09:42:39 GMT
Received: by tiger.seabridge.co.il with Internet Mail Service (5.5.2653.19)
	id <19R8MY2Y>; Thu, 20 Mar 2003 11:42:47 +0200
Message-ID: <C87E5A01714C7840B92CDED9E79329CA51F956@leopard.seabridge.co.il>
From: Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>
To: mpls@UU.NET
Subject: Distributing Labels for PWs within an LSP TE Tunnel 
Date: Thu, 20 Mar 2003 11:42:45 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi all, 

I am looking for a method for distributing PWs' labels of PWs within a TE
LSP tunnel. 
The TE tunnel is signaled using the RSVP-TE signaling protocol. Is there a
method for distributing labels for PWs that should run within TE LSP tunnel?
I am aware of the IETF draft for signaling the PWs' labels using the LDP
protocol, but I would like to attach a certain PW with a certain TE LSP
tunnel. How can I gain it? Maybe I should activate the LDP for a certain PW
within the required tunnel (inband)? Is there another way to do it but not a
static one (by configuration)?

I wonder also if there is a way to signal a TE PW?

I'll appreciate your response.
Thanks in advance, Nurit.


From owner-mpls@UU.NET  Thu Mar 20 14:32:02 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01167
	for <mpls-archive@lists.ietf.org>; Thu, 20 Mar 2003 14:32:01 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogwk22732
	for <mpls-archive@lists.ietf.org>; Thu, 20 Mar 2003 19:34:16 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogwk22494;
	Thu, 20 Mar 2003 19:34:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogwi10784
	for mpls-outgoing; Thu, 20 Mar 2003 19:08:21 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQogwi10777
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 20 Mar 2003 19:08:07 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQogwi27107
	for <mpls@UU.NET>; Thu, 20 Mar 2003 19:08:04 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogwi23317
	for <mpls@UU.NET>; Thu, 20 Mar 2003 19:08:03 GMT
Received: from mailhost.avici.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [12.38.212.174])
	id QQogwi23307
	for <mpls@UU.NET>; Thu, 20 Mar 2003 19:08:03 GMT
Received: from aatlas-lt.avici.com (b2vpnpc11.avici.com [10.2.101.11])
	by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id h2KJ7hC05227;
	Thu, 20 Mar 2003 14:07:44 -0500 (EST)
Message-Id: <5.1.0.14.2.20030320140523.02076ba8@mailhost.avici.com>
X-Sender: aatlas@mailhost.avici.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 20 Mar 2003 14:08:10 -0500
To: Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>
From: Alia Atlas <aatlas@avici.com>
Subject: Re: Distributing Labels for PWs within an LSP TE Tunnel 
Cc: mpls@UU.NET
In-Reply-To: <C87E5A01714C7840B92CDED9E79329CA51F956@leopard.seabridge.c
 o.il>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 11:42 AM 3/20/2003 +0200, Nurit Sprecher wrote:

>Hi all,
>
>I am looking for a method for distributing PWs' labels of PWs within a TE
>LSP tunnel.
>The TE tunnel is signaled using the RSVP-TE signaling protocol. Is there a
>method for distributing labels for PWs that should run within TE LSP tunnel?
>I am aware of the IETF draft for signaling the PWs' labels using the LDP
>protocol, but I would like to attach a certain PW with a certain TE LSP
>tunnel. How can I gain it? Maybe I should activate the LDP for a certain PW
>within the required tunnel (inband)? Is there another way to do it but not a
>static one (by configuration)?

Hi,

You can use a targeted LDP session to distribute the labels for a PW 
between the two PEs.  How that PW travels across the PSN is independent of 
how the labels for the PW were distributed.  Thus, the PW could use either 
an LDP LSP or a RSVP-TE LSP to reach the egress PE.  Which one to use and 
how the PW is mapped to it is an internal issue on the ingress PE.

Alia


>I wonder also if there is a way to signal a TE PW?
>
>I'll appreciate your response.
>Thanks in advance, Nurit.




From owner-mpls@UU.NET  Thu Mar 20 22:11:14 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19753
	for <mpls-archive@lists.ietf.org>; Thu, 20 Mar 2003 22:11:13 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogxo05221
	for <mpls-archive@lists.ietf.org>; Fri, 21 Mar 2003 03:13:29 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogxo05061;
	Fri, 21 Mar 2003 03:13:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogxn23010
	for mpls-outgoing; Fri, 21 Mar 2003 02:47:02 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQogxn23001
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 21 Mar 2003 02:46:50 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQogxn20650
	for <mpls@uu.net>; Fri, 21 Mar 2003 02:46:07 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogxn28376
	for <mpls@uu.net>; Fri, 21 Mar 2003 02:46:06 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQogxn28349
	for <mpls@uu.net>; Fri, 21 Mar 2003 02:46:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2L2k2MR011137
	for <mpls@uu.net>; Thu, 20 Mar 2003 21:46:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA15659 for <mpls@uu.net>; Thu, 20 Mar 2003 21:46:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2L2k1W14909 for mpls@uu.net; Thu, 20 Mar 2003 21:46:01 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQogxn22727
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 21 Mar 2003 02:45:15 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQogxm29353
	for <mpls@uu.net>; Fri, 21 Mar 2003 02:44:14 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogxm16926
	for <mpls@uu.net>; Fri, 21 Mar 2003 02:44:13 GMT
Received: from ams-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ams-msg-core-1.cisco.com [144.254.74.60])
	id QQogxm16913
	for <mpls@uu.net>; Fri, 21 Mar 2003 02:44:12 GMT
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2L2gO7e000895;
	Fri, 21 Mar 2003 03:42:24 +0100 (MET)
Received: from JVASSEUR-W2K.cisco.com (sjc-vpn1-240.cisco.com [10.21.96.240])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id DAA00276;
	Fri, 21 Mar 2003 03:44:06 +0100 (MET)
Message-Id: <4.3.2.7.2.20030320122900.03c953a0@paris.cisco.com>
X-Sender: jvasseur@paris.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 20 Mar 2003 15:41:27 -0800
To: bhaskarap@mail.com
From: Jean Philippe Vasseur <jvasseur@cisco.com>
Subject: Re: Inter-area cspf
Cc: "Bhaskara Peela" <bhaskarap@mail.com>, mpls@UU.NET, ccamp@ops.ietf.org
In-Reply-To: <20030319192138.77980.qmail@mail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Bhaskara,

At 14:21 19/03/2003 -0500, bhaskarap@mail.com wrote:
>Hi Jean,
>
>The draft-vasseur-mpls-computation-rsvp-03.txt suggests overload RSVP 
>message to query path request/response between
>path server and client.  Why RSVP should be overloaded when
>it does not involve RSVP signalling.  Why can't we use some plain 
>client-server model instead of overloading RSVP in a scenario which is not 
>related to RSVP.  I came across one
>more draft-lee-mpls-path-request-04.txt which is just a plain 
>client-server model.
>
>Can you please clarify issues involving these two methods.

One comment first: this PCC-PCS draft tries to address multiple problems 
applicable to very different scenarios (inter-area, inter-AS, GMPLS, 
intra-area with off-line computation, ...). As a result, this might give 
the impression that quite a substantial number of objects are required for 
each scenario which is definitely not the case. I guess this is where your 
feeling that we "overload" RSVP might come from. So the plan is to post a 
completely new version of this draft. I'm just waiting for the CCAMP 
charter update and I'm hopping that the motivation for the choice of RSVP 
for PCC-PCS will more clearly appear.

Then, your comments on this new version will be very welcome.

>I do see draft-kompella-mpls-multiarea-te-03.txt expired.  What is the 
>status of this draft? Does any one have idea regarding the implementions 
>for multi-area TE/CSPF among vendors?

Related to draft-kompella-mpls-multiarea-te, we will resurrect it. Let's 
wait for the update on the CCAMP charter.

I won't comment on those lists on vendor implementations but yes there are 
some implementations.

JP.

>Can any one clarify?
>
>thank you
>bhaskara
>----- Original Message -----
>From: Jean Philippe Vasseur <jvasseur@cisco.com>
>Date: Wed, 19 Mar 2003 00:11:12 -0800
>To: "Bhaskara Peela" <bhaskarap@mail.com>
>Subject: Re: Inter-area cspf
>
> > Hi,
> >
> > FYI, if you're interested by multi-area TE, you might want to consider:
> > - 
> http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.txt
> > For PCS-PCC signalling (scenarios 2,4 and 5 on of the previous draft) see:
> > 
> http://www.ietf.org/internet-drafts/draft-vasseur-mpls-computation-rsvp-03.txt
> >
> > JP.
> >
> > At 15:06 18/03/2003 -0500, Bhaskara Peela wrote:
> > >[ post by non-subscriber.  with the massive amount of spam, it is easy 
> to miss
> > >   and therefore delete posts by non-subscribers.  if you wish to 
> regularly
> > >   post from an address that is not subscribed to this mailing list, 
> send a
> > >   message to <listname>-owner@ops.ietf.org and ask to have the alternate
> > >   address added to the list of addresses from which submissions are
> > >   automatically accepted. ]
> > >
> > >Hi,
> > >
> > >Can any one update me about the status of following drafts
> > >
> > >1)draft-ash-ccamp-multi-area-te-reqmts-00.txt
> > >2)draft-lee-mpls-te-exchange-00.txt
> > >3)draft-lee-mpls-path-request-00.txt
> > >4)draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt
> > >
> > >I would like to know what is the latest ongoing standadization process 
> for
> > >inter-area OSPF-TE LSA flooding
> > >for CSPF calculation for GMPLS or MPLS.
> > >
> > >thank you
> > >bhaskara
> > >--
> > >__________________________________________________________
> > >Sign-up for your own FREE Personalized E-mail at Mail.com
> > >http://www.mail.com/?sr=signup
> >
>
>--
>__________________________________________________________
>Sign-up for your own FREE Personalized E-mail at Mail.com
>http://www.mail.com/?sr=signup



From owner-mpls@UU.NET  Fri Mar 21 12:33:12 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19790
	for <mpls-archive@lists.ietf.org>; Fri, 21 Mar 2003 12:33:11 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogzu05736
	for <mpls-archive@lists.ietf.org>; Fri, 21 Mar 2003 17:35:24 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQogzu05553;
	Fri, 21 Mar 2003 17:35:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogzs00508
	for mpls-outgoing; Fri, 21 Mar 2003 17:09:21 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQogzs00503
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 21 Mar 2003 17:09:08 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQogzs10931
	for <mpls@uu.net>; Fri, 21 Mar 2003 17:08:12 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogzs07595
	for <mpls@uu.net>; Fri, 21 Mar 2003 17:08:11 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQogzs07557
	for <mpls@uu.net>; Fri, 21 Mar 2003 17:08:06 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2LH83MR000662
	for <mpls@uu.net>; Fri, 21 Mar 2003 12:08:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA03197 for <mpls@uu.net>; Fri, 21 Mar 2003 12:08:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2LH82R23772 for mpls@uu.net; Fri, 21 Mar 2003 12:08:02 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQogzs00458
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 21 Mar 2003 17:07:05 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQogzs27201
	for <mpls@UU.NET>; Fri, 21 Mar 2003 17:06:54 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogzs07644
	for <mpls@UU.NET>; Fri, 21 Mar 2003 17:06:53 GMT
Received: from father.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: father.pmc-sierra.com [216.241.224.13])
	id QQogzs07634
	for <mpls@UU.NET>; Fri, 21 Mar 2003 17:06:53 GMT
Received: (qmail 8497 invoked by uid 104); 21 Mar 2003 17:06:52 -0000
Received: from Shahram_Davari@pmc-sierra.com by father by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4253.  Clear:. 
 Processed in 0.463256 secs); 21 Mar 2003 17:06:52 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by father.pmc-sierra.com with SMTP; 21 Mar 2003 17:06:51 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h2LH6Xh25381;
	Fri, 21 Mar 2003 09:06:33 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <DCP4RDBM>; Fri, 21 Mar 2003 09:06:33 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03DE2@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Alia Atlas'" <aatlas@avici.com>,
        Nurit Sprecher
	 <nurit.sprecher@SeabridgeNetworks.com>
Cc: mpls@UU.NET,
        "Mustapha Aissaoui (E-mail)"
	 <mustapha.aissaoui@alcatel.com>
Subject: RE: Distributing Labels for PWs within an LSP TE Tunnel 
Date: Fri, 21 Mar 2003 09:06:29 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Alia,

I think Nurit's question was how can we bind a PW to a transport LSP, in a way that both PE's know about it? This would be useful if LDP uses per-interface label space.

An extension to PW signaling may be needed. Or a DoD label request that is pushed inside
the tunnel LSP could be used.

-Shahram



>-----Original Message-----
>From: Alia Atlas [mailto:aatlas@avici.com]
>Sent: Thursday, March 20, 2003 2:08 PM
>To: Nurit Sprecher
>Cc: mpls@UU.NET
>Subject: Re: Distributing Labels for PWs within an LSP TE Tunnel 
>
>
>At 11:42 AM 3/20/2003 +0200, Nurit Sprecher wrote:
>
>>Hi all,
>>
>>I am looking for a method for distributing PWs' labels of PWs 
>within a TE
>>LSP tunnel.
>>The TE tunnel is signaled using the RSVP-TE signaling 
>protocol. Is there a
>>method for distributing labels for PWs that should run within 
>TE LSP tunnel?
>>I am aware of the IETF draft for signaling the PWs' labels 
>using the LDP
>>protocol, but I would like to attach a certain PW with a 
>certain TE LSP
>>tunnel. How can I gain it? Maybe I should activate the LDP 
>for a certain PW
>>within the required tunnel (inband)? Is there another way to 
>do it but not a
>>static one (by configuration)?
>
>Hi,
>
>You can use a targeted LDP session to distribute the labels for a PW 
>between the two PEs.  How that PW travels across the PSN is 
>independent of 
>how the labels for the PW were distributed.  Thus, the PW 
>could use either 
>an LDP LSP or a RSVP-TE LSP to reach the egress PE.  Which one 
>to use and 
>how the PW is mapped to it is an internal issue on the ingress PE.
>
>Alia
>
>
>>I wonder also if there is a way to signal a TE PW?
>>
>>I'll appreciate your response.
>>Thanks in advance, Nurit.
>
>



From owner-mpls@UU.NET  Fri Mar 21 14:09:36 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22904
	for <mpls-archive@lists.ietf.org>; Fri, 21 Mar 2003 14:09:36 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohaa04362
	for <mpls-archive@lists.ietf.org>; Fri, 21 Mar 2003 19:11:53 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohaa04179;
	Fri, 21 Mar 2003 19:11:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQogzz27073
	for mpls-outgoing; Fri, 21 Mar 2003 18:45:30 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQogzz27065
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 21 Mar 2003 18:45:23 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQogzy04951
	for <mpls@uu.net>; Fri, 21 Mar 2003 18:44:22 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogzy00919
	for <mpls@uu.net>; Fri, 21 Mar 2003 18:44:21 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQogzy00915
	for <mpls@uu.net>; Fri, 21 Mar 2003 18:44:21 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2LIiHMR008403
	for <mpls@uu.net>; Fri, 21 Mar 2003 13:44:17 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA11257 for <mpls@uu.net>; Fri, 21 Mar 2003 13:44:16 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2LIiGA01590 for mpls@uu.net; Fri, 21 Mar 2003 13:44:16 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQogsr10636
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Mar 2003 19:22:01 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQogsr01355
	for <mpls@uu.net>; Wed, 19 Mar 2003 19:21:50 GMT
From: bhaskarap@mail.com
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQogsr23947
	for <mpls@uu.net>; Wed, 19 Mar 2003 19:21:49 GMT
Received: from spf1.us.outblaze.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: 205-158-62-158.outblaze.com [205.158.62.158])
	id QQogsr23926
	for <mpls@uu.net>; Wed, 19 Mar 2003 19:21:48 GMT
Received: (qmail 31623 invoked from network); 19 Mar 2003 19:20:57 -0000
Received: from unknown (205.158.62.68)
  by spf1.us.outblaze.com with QMQP; 19 Mar 2003 19:20:57 -0000
Received: (qmail 54800 invoked from network); 19 Mar 2003 19:21:38 -0000
Received: from unknown (HELO ws1-5.us4.outblaze.com) (205.158.62.51)
  by 205-158-62-153.outblaze.com with SMTP; 19 Mar 2003 19:21:38 -0000
Received: (qmail 77981 invoked by uid 1001); 19 Mar 2003 19:21:38 -0000
Message-ID: <20030319192138.77980.qmail@mail.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-Mailer: MIME-tools 5.41 (Entity 5.404)
Received: from [63.197.247.13] by ws1-5.us4.outblaze.com with http for
    bhaskarap@mail.com; Wed, 19 Mar 2003 14:21:38 -0500
To: jvasseur@cisco.com, "Bhaskara Peela" <bhaskarap@mail.com>
Cc: mpls@UU.NET, ccamp@ops.ietf.org
Date: Wed, 19 Mar 2003 14:21:38 -0500
Subject: Re: Inter-area cspf
X-Originating-Ip: 63.197.247.13
X-Originating-Server: ws1-5.us4.outblaze.com
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Jean,

The draft-vasseur-mpls-computation-rsvp-03.txt suggests overload RSVP message to query path request/response between
path server and client.  Why RSVP should be overloaded when
it does not involve RSVP signalling.  Why can't we use some plain client-server model instead of overloading RSVP in a scenario which is not related to RSVP.  I came across one
more draft-lee-mpls-path-request-04.txt which is just a plain client-server model. 

Can you please clarify issues involving these two methods.

I do see draft-kompella-mpls-multiarea-te-03.txt expired.  What is the status of this draft? Does any one have idea regarding the implementions for multi-area TE/CSPF among vendors?

Can any one clarify?

thank you
bhaskara
----- Original Message -----
From: Jean Philippe Vasseur <jvasseur@cisco.com>
Date: Wed, 19 Mar 2003 00:11:12 -0800
To: "Bhaskara Peela" <bhaskarap@mail.com>
Subject: Re: Inter-area cspf

> Hi,
> 
> FYI, if you're interested by multi-area TE, you might want to consider:
> - http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.txt
> For PCS-PCC signalling (scenarios 2,4 and 5 on of the previous draft) see:
> http://www.ietf.org/internet-drafts/draft-vasseur-mpls-computation-rsvp-03.txt
> 
> JP.
> 
> At 15:06 18/03/2003 -0500, Bhaskara Peela wrote:
> >[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
> >   and therefore delete posts by non-subscribers.  if you wish to regularly
> >   post from an address that is not subscribed to this mailing list, send a
> >   message to <listname>-owner@ops.ietf.org and ask to have the alternate
> >   address added to the list of addresses from which submissions are
> >   automatically accepted. ]
> >
> >Hi,
> >
> >Can any one update me about the status of following drafts
> >
> >1)draft-ash-ccamp-multi-area-te-reqmts-00.txt
> >2)draft-lee-mpls-te-exchange-00.txt
> >3)draft-lee-mpls-path-request-00.txt
> >4)draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt
> >
> >I would like to know what is the latest ongoing standadization process for 
> >inter-area OSPF-TE LSA flooding
> >for CSPF calculation for GMPLS or MPLS.
> >
> >thank you
> >bhaskara
> >--
> >__________________________________________________________
> >Sign-up for your own FREE Personalized E-mail at Mail.com
> >http://www.mail.com/?sr=signup
> 

-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup



From owner-mpls@UU.NET  Mon Mar 24 01:12:09 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23338
	for <mpls-archive@lists.ietf.org>; Mon, 24 Mar 2003 01:12:09 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohjc08399
	for <mpls-archive@lists.ietf.org>; Mon, 24 Mar 2003 06:14:27 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohjc07977;
	Mon, 24 Mar 2003 06:14:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohjb15292
	for mpls-outgoing; Mon, 24 Mar 2003 05:49:02 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohjb15285
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Mar 2003 05:49:00 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohjb08250
	for <mpls@uu.net>; Mon, 24 Mar 2003 05:48:37 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohjb13378
	for <mpls@uu.net>; Mon, 24 Mar 2003 05:48:36 GMT
Received: from auemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: auemail1.lucent.com [192.11.223.161])
	id QQohjb13285
	for <mpls@uu.net>; Mon, 24 Mar 2003 05:48:32 GMT
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by auemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2O5mUt06308
	for <mpls@uu.net>; Mon, 24 Mar 2003 00:48:31 -0500 (EST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19)
	id <DVZ3LHGK>; Mon, 24 Mar 2003 06:48:29 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501272732@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: subip-area@subip.ietf.org
Cc: "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>,
        "Ppvpn (E-mail)"
	 <ppvpn@nortelnetworks.com>,
        "Mpls (E-mail)" <mpls@UU.NET>, "Tewg (E-mail)" <te-wg@ops.ietf.org>,
        "Gsmp (E-mail)" <gsmp@ietf.org>,
        "Ipo (E-mail)" <ip-optical@lists.bell-labs.com>
Subject: Change of primary AD for SUB-IP WGs
Date: Mon, 24 Mar 2003 06:48:27 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

All,

Scott has left the IESG and Alex has volunteered 
to be co-AD for SUB-IP with Bert. IESG has approved this.
See announcement by Harald a week or so ago.

We have divided the WGs between the two of us as follows
(i.e. we act as primary AD as follows):

  For CCAMP, no change, so Bert Wijnen
  For GSMP: change Scott Bradner into Bert Wijnen
  For IPO: change Scott Bradner into Alex Zinin
  For MPLS: change Scott Bradner into Alex Zinin
  For PPVPN: change Scott Bradner into Alex Zinin
  For TEWG: no change, so Bert Wijnen

Thanks,
Bert and Alex


From owner-mpls@UU.NET  Mon Mar 24 04:47:34 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08901
	for <mpls-archive@lists.ietf.org>; Mon, 24 Mar 2003 04:47:33 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohjr25647
	for <mpls-archive@lists.ietf.org>; Mon, 24 Mar 2003 09:49:48 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohjr25462;
	Mon, 24 Mar 2003 09:49:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohjp08985
	for mpls-outgoing; Mon, 24 Mar 2003 09:24:02 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohjp08980
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Mar 2003 09:23:50 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohjp03199
	for <mpls@UU.NET>; Mon, 24 Mar 2003 09:22:29 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohjp13255
	for <mpls@UU.NET>; Mon, 24 Mar 2003 09:22:28 GMT
Received: from tiger.seabridge.co.il by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: bzq-25-127-226.cust.bezeqint.net [212.25.127.226])
	id QQohjp13183
	for <mpls@UU.NET>; Mon, 24 Mar 2003 09:22:25 GMT
Received: by tiger.seabridge.co.il with Internet Mail Service (5.5.2653.19)
	id <19R8M08K>; Mon, 24 Mar 2003 10:25:31 +0200
Message-ID: <C87E5A01714C7840B92CDED9E79329CA51F965@leopard.seabridge.co.il>
From: Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>
To: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        "'Alia Atlas'"
	 <aatlas@avici.com>,
        Nurit Sprecher
	 <nurit.sprecher@SeabridgeNetworks.com>
Cc: mpls@UU.NET,
        "Mustapha Aissaoui (E-mail)"
	 <mustapha.aissaoui@alcatel.com>
Subject: RE: Distributing Labels for PWs within an LSP TE Tunnel 
Date: Mon, 24 Mar 2003 10:25:30 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Thanks for your responses.
I do look for a way to bind the (LDP) signaled PWs to the (RSVP-TE) signaled
transport tunnel LSP, in a way that both PEs know about it. 
As I understand from your response, I should signal that the PWs within the
TE tunnel LSP.
Is there a way to signal 'TE' PWs?

-----Original Message-----
From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
Sent: Friday, March 21, 2003 7:06 PM
To: 'Alia Atlas'; Nurit Sprecher
Cc: mpls@UU.NET; Mustapha Aissaoui (E-mail)
Subject: RE: Distributing Labels for PWs within an LSP TE Tunnel 

Alia,

I think Nurit's question was how can we bind a PW to a transport LSP, in a
way that both PE's know about it? This would be useful if LDP uses
per-interface label space.

An extension to PW signaling may be needed. Or a DoD label request that is
pushed inside
the tunnel LSP could be used.

-Shahram



>-----Original Message-----
>From: Alia Atlas [mailto:aatlas@avici.com]
>Sent: Thursday, March 20, 2003 2:08 PM
>To: Nurit Sprecher
>Cc: mpls@UU.NET
>Subject: Re: Distributing Labels for PWs within an LSP TE Tunnel
>
>
>At 11:42 AM 3/20/2003 +0200, Nurit Sprecher wrote:
>
>>Hi all,
>>
>>I am looking for a method for distributing PWs' labels of PWs
>within a TE
>>LSP tunnel.
>>The TE tunnel is signaled using the RSVP-TE signaling
>protocol. Is there a
>>method for distributing labels for PWs that should run within
>TE LSP tunnel?
>>I am aware of the IETF draft for signaling the PWs' labels
>using the LDP
>>protocol, but I would like to attach a certain PW with a
>certain TE LSP
>>tunnel. How can I gain it? Maybe I should activate the LDP
>for a certain PW
>>within the required tunnel (inband)? Is there another way to
>do it but not a
>>static one (by configuration)?
>
>Hi,
>
>You can use a targeted LDP session to distribute the labels for a PW
>between the two PEs.  How that PW travels across the PSN is
>independent of
>how the labels for the PW were distributed.  Thus, the PW
>could use either
>an LDP LSP or a RSVP-TE LSP to reach the egress PE.  Which one
>to use and
>how the PW is mapped to it is an internal issue on the ingress PE.
>
>Alia
>
>
>>I wonder also if there is a way to signal a TE PW?
>>
>>I'll appreciate your response.
>>Thanks in advance, Nurit.
>
>


From owner-mpls@UU.NET  Mon Mar 24 11:08:27 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24272
	for <mpls-archive@lists.ietf.org>; Mon, 24 Mar 2003 11:08:27 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohkq21563
	for <mpls-archive@lists.ietf.org>; Mon, 24 Mar 2003 16:10:46 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohkq20488;
	Mon, 24 Mar 2003 16:10:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohkp27367
	for mpls-outgoing; Mon, 24 Mar 2003 15:45:00 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohko27354
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Mar 2003 15:44:55 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohko11435
	for <mpls@UU.NET>; Mon, 24 Mar 2003 15:44:11 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohko03778
	for <mpls@UU.NET>; Mon, 24 Mar 2003 15:44:11 GMT
Received: from thurn.corp.titan.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: thurn.corp.titan.com [159.62.51.20])
	id QQohko03760
	for <mpls@UU.NET>; Mon, 24 Mar 2003 15:44:10 GMT
Received: from vcmd-nt1.validity.com (val114-005.validity.titan.com [159.62.114.5])
	by thurn.corp.titan.com (8.12.8/8.12.8) with ESMTP id h2OFhWrF008142;
	Mon, 24 Mar 2003 07:43:34 -0800
Received: by VCMD-NT1 with Internet Mail Service (5.5.2655.55)
	id <HCMW8212>; Mon, 24 Mar 2003 10:42:48 -0500
Message-ID: <561621C69F17D511A3A20050047340EC01AAF638@VCMD-NT1>
From: "Ferrell, William" <William.Ferrell@titan.com>
To: "'Nurit Sprecher'" <nurit.sprecher@SeabridgeNetworks.com>,
        "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        "'Alia Atlas'"
	 <aatlas@avici.com>
Cc: mpls@UU.NET,
        "Mustapha Aissaoui (E-mail)"
	 <mustapha.aissaoui@alcatel.com>
Subject: RE: Distributing Labels for PWs within an LSP TE Tunnel 
Date: Mon, 24 Mar 2003 10:42:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Nurit/ Alia 

I'd like to look at LDP from from a simular perspective but concentrate on
securely binding the signaled PW as well as the entire LDP signaling
protocol. 
In the past LDP has been a notoriously clear-text protocol simular to  Cisco
CDP or any other L3 routing protocols without any authentication scheme.
I've yet to learn of a defined secure LDP protocol. 

Will


-----Original Message-----
From: Nurit Sprecher [mailto:nurit.sprecher@SeabridgeNetworks.com]
Sent: Monday, March 24, 2003 3:26 AM
To: 'Shahram Davari'; 'Alia Atlas'; Nurit Sprecher
Cc: mpls@UU.NET; Mustapha Aissaoui (E-mail)
Subject: RE: Distributing Labels for PWs within an LSP TE Tunnel 


Thanks for your responses.
I do look for a way to bind the (LDP) signaled PWs to the (RSVP-TE) signaled
transport tunnel LSP, in a way that both PEs know about it. 
As I understand from your response, I should signal that the PWs within the
TE tunnel LSP.
Is there a way to signal 'TE' PWs?

-----Original Message-----
From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
Sent: Friday, March 21, 2003 7:06 PM
To: 'Alia Atlas'; Nurit Sprecher
Cc: mpls@UU.NET; Mustapha Aissaoui (E-mail)
Subject: RE: Distributing Labels for PWs within an LSP TE Tunnel 

Alia,

I think Nurit's question was how can we bind a PW to a transport LSP, in a
way that both PE's know about it? This would be useful if LDP uses
per-interface label space.

An extension to PW signaling may be needed. Or a DoD label request that is
pushed inside
the tunnel LSP could be used.

-Shahram



>-----Original Message-----
>From: Alia Atlas [mailto:aatlas@avici.com]
>Sent: Thursday, March 20, 2003 2:08 PM
>To: Nurit Sprecher
>Cc: mpls@UU.NET
>Subject: Re: Distributing Labels for PWs within an LSP TE Tunnel
>
>
>At 11:42 AM 3/20/2003 +0200, Nurit Sprecher wrote:
>
>>Hi all,
>>
>>I am looking for a method for distributing PWs' labels of PWs
>within a TE
>>LSP tunnel.
>>The TE tunnel is signaled using the RSVP-TE signaling
>protocol. Is there a
>>method for distributing labels for PWs that should run within
>TE LSP tunnel?
>>I am aware of the IETF draft for signaling the PWs' labels
>using the LDP
>>protocol, but I would like to attach a certain PW with a
>certain TE LSP
>>tunnel. How can I gain it? Maybe I should activate the LDP
>for a certain PW
>>within the required tunnel (inband)? Is there another way to
>do it but not a
>>static one (by configuration)?
>
>Hi,
>
>You can use a targeted LDP session to distribute the labels for a PW
>between the two PEs.  How that PW travels across the PSN is
>independent of
>how the labels for the PW were distributed.  Thus, the PW
>could use either
>an LDP LSP or a RSVP-TE LSP to reach the egress PE.  Which one
>to use and
>how the PW is mapped to it is an internal issue on the ingress PE.
>
>Alia
>
>
>>I wonder also if there is a way to signal a TE PW?
>>
>>I'll appreciate your response.
>>Thanks in advance, Nurit.
>
>


From owner-mpls@UU.NET  Mon Mar 24 15:16:39 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02442
	for <mpls-archive@lists.ietf.org>; Mon, 24 Mar 2003 15:16:39 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohlh04343
	for <mpls-archive@lists.ietf.org>; Mon, 24 Mar 2003 20:18:57 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohlh03544;
	Mon, 24 Mar 2003 20:18:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohlf28433
	for mpls-outgoing; Mon, 24 Mar 2003 19:51:15 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQohlf28428
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Mar 2003 19:51:05 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohlf00310
	for <mpls@uu.net>; Mon, 24 Mar 2003 19:50:07 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohlf04689
	for <mpls@uu.net>; Mon, 24 Mar 2003 19:50:07 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQohlf04662
	for <mpls@uu.net>; Mon, 24 Mar 2003 19:50:06 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2OJo3MR019134
	for <mpls@uu.net>; Mon, 24 Mar 2003 14:50:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA13454 for <mpls@uu.net>; Mon, 24 Mar 2003 14:50:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2OJo2G13749 for mpls@uu.net; Mon, 24 Mar 2003 14:50:02 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohlf28374
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Mar 2003 19:49:10 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohlf19776
	for <mpls@uu.net>; Mon, 24 Mar 2003 19:47:25 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohlf24924
	for <mpls@uu.net>; Mon, 24 Mar 2003 19:47:24 GMT
Received: from smtp1.phx.gblx.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp1.phx.gblx.net [64.208.25.103])
	id QQohlf24910
	for <mpls@uu.net>; Mon, 24 Mar 2003 19:47:24 GMT
Received: (from daemon@localhost)
	by smtp1.phx.gblx.net (8.11.2/8.11.2) id h2OJlN024206
	for <mpls@uu.net>; Mon, 24 Mar 2003 12:47:23 -0700 (MST)
Received: from shell1.phx.gblx.net(64.208.25.102)
 via SMTP by smtp1.phx.gblx.net, id smtpdAAA1jayoV; Mon Mar 24 12:47:21 2003
Received: (from mmeyer@localhost)
	by shell1.phx.gblx.net (8.9.3+Sun/8.9.3) id MAA06528
	for mpls@uu.net; Mon, 24 Mar 2003 12:47:21 -0700 (MST)
Date: Mon, 24 Mar 2003 12:47:20 -0700
From: Matthew Meyer <mrm@gblx.net>
To: mpls@UU.NET
Subject: Soft Preemption, RRO & PERR
Message-ID: <20030324194720.GB6336@gblx.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
Sender: owner-mpls@UU.NET
Precedence: bulk

Greetings,

I'd like to try to propel the Soft Preemption RESV RRO Flag
vs PERR discussion to a close.  The draft authors are in
agreement and Cisco, Juniper and Avici are all now favoring 
to implement the RESV RRO Flag solution.
    
Clearly they are not the only voices that matter so I would
like present some key points/benefits that in my eyes would
seem to make RESV RRO use more beneficial than PERR.

 1) Nodes upstream of the points of soft preemption can   
    perform preemption selection taking into account LSPs 
    already soft preempted by downstream nodes, resulting 
    in a more efficient scheme.
 2) With RRO the HE can receive an entire list in one message, not
    so with PERR. (up to hop-count minus one messages per LSP)
 3) Kicking the RRO up to the processor to look at the RESV RRO
    protection desired bit may be necessary anyway.
 4) Waiting an arbitrary amount of time to 'collect' a bunch of
    uncoordinated tinigrams is not required. When the RESV RRO
    arrives at the HE, the option of executing immediately is 
    available (with assuredness that all hops have been collected).
    With PERR you must wait.                                       
 5) Removes the need to store which soft preempted hops have already
    arrived for a given soft preemption triggered reroute.

I was asked off-line to expand on the relevance/frequency of
item (2) above. There are a few common network topologies that are
specific catalysts to a chain of preemptions along the length
of a single LSP.  String-of-pearls and ring network configurations 
are common building blocks for sections of provider networks. Being 
that a ring of point to point connected nodes in failure can be 
viewed as string-of-pearls, the two topologies possess the same  
exposure.
 
Imagine, then, a great number of LSPs transiting North America    
whose sources & destinations are inter-continental (Europe,Asia)
or intra-continental but coast to coast.  They all transit an
North American intra-continental shortest path from New York to
San Francisco that is ultimately many intermediate segments
in serial (string-of-pearls).  As the demands are primarily transit
coast to coast, the network would be sized in a similar
denomination all along the series of links according to that
aggregate demand.  Were this not the case and there was one
significant choke point, preemption would be limited to, or
at least disproportionally occurring at, the one choke point. 
Anyway, this set of transiting LSPs would be prone to (soft) 
preemption at multiple points for the same preemption inducing
event.  Using the RESV RRO (rather than the PERR) could reduce
the number of required messages in this common network construct.

Matthew



From owner-mpls@UU.NET  Tue Mar 25 00:04:33 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18355
	for <mpls-archive@lists.ietf.org>; Tue, 25 Mar 2003 00:04:32 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohmq02048
	for <mpls-archive@lists.ietf.org>; Tue, 25 Mar 2003 05:06:52 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohmq01547;
	Tue, 25 Mar 2003 05:06:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohmo23081
	for mpls-outgoing; Tue, 25 Mar 2003 04:39:16 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohmo23070
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Mar 2003 04:39:01 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohmo23542
	for <mpls@uu.net>; Tue, 25 Mar 2003 04:38:07 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohmo00373
	for <mpls@uu.net>; Tue, 25 Mar 2003 04:38:07 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQohmo00342
	for <mpls@uu.net>; Tue, 25 Mar 2003 04:38:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2P4c2MR021707
	for <mpls@uu.net>; Mon, 24 Mar 2003 23:38:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id XAA15780 for <mpls@uu.net>; Mon, 24 Mar 2003 23:38:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2P4c2608141 for mpls@uu.net; Mon, 24 Mar 2003 23:38:02 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohmo23018
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Mar 2003 04:37:01 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohmo18034
	for <mpls@UU.NET>; Tue, 25 Mar 2003 04:36:12 GMT
Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [216.241.224.12])
	id QQohle22169
	for <mpls@UU.NET>; Mon, 24 Mar 2003 19:32:35 GMT
Received: (qmail 3947 invoked by uid 104); 24 Mar 2003 19:32:29 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4253.  Clear:. 
 Processed in 1.605277 secs); 24 Mar 2003 19:32:29 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by mother.pmc-sierra.com with SMTP; 24 Mar 2003 19:32:25 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h2OJWCh24919;
	Mon, 24 Mar 2003 11:32:21 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <DCP4S21C>; Mon, 24 Mar 2003 11:32:12 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03DF0@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Nurit Sprecher'" <nurit.sprecher@SeabridgeNetworks.com>,
        "'Alia Atlas'"
	 <aatlas@avici.com>
Cc: mpls@UU.NET,
        "Mustapha Aissaoui (E-mail)"
	 <mustapha.aissaoui@alcatel.com>
Subject: RE: Distributing Labels for PWs within an LSP TE Tunnel 
Date: Mon, 24 Mar 2003 11:32:00 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

Yes, but currently only DU mode (not DoD) has been defined.
What is TE PW? PW is a pt-t-pt connection, so I don't think
the PW label needs to use RSVP-TE.

-Shahram

>-----Original Message-----
>From: Nurit Sprecher [mailto:nurit.sprecher@SeabridgeNetworks.com]
>Sent: Monday, March 24, 2003 3:26 AM
>To: Shahram Davari; 'Alia Atlas'; Nurit Sprecher
>Cc: mpls@UU.NET; Mustapha Aissaoui (E-mail)
>Subject: RE: Distributing Labels for PWs within an LSP TE Tunnel 
>
>
>Thanks for your responses.
>I do look for a way to bind the (LDP) signaled PWs to the 
>(RSVP-TE) signaled
>transport tunnel LSP, in a way that both PEs know about it. 
>As I understand from your response, I should signal that the 
>PWs within the
>TE tunnel LSP.
>Is there a way to signal 'TE' PWs?
>
>-----Original Message-----
>From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
>Sent: Friday, March 21, 2003 7:06 PM
>To: 'Alia Atlas'; Nurit Sprecher
>Cc: mpls@UU.NET; Mustapha Aissaoui (E-mail)
>Subject: RE: Distributing Labels for PWs within an LSP TE Tunnel 
>
>Alia,
>
>I think Nurit's question was how can we bind a PW to a 
>transport LSP, in a
>way that both PE's know about it? This would be useful if LDP uses
>per-interface label space.
>
>An extension to PW signaling may be needed. Or a DoD label 
>request that is
>pushed inside
>the tunnel LSP could be used.
>
>-Shahram
>
>
>
>>-----Original Message-----
>>From: Alia Atlas [mailto:aatlas@avici.com]
>>Sent: Thursday, March 20, 2003 2:08 PM
>>To: Nurit Sprecher
>>Cc: mpls@UU.NET
>>Subject: Re: Distributing Labels for PWs within an LSP TE Tunnel
>>
>>
>>At 11:42 AM 3/20/2003 +0200, Nurit Sprecher wrote:
>>
>>>Hi all,
>>>
>>>I am looking for a method for distributing PWs' labels of PWs
>>within a TE
>>>LSP tunnel.
>>>The TE tunnel is signaled using the RSVP-TE signaling
>>protocol. Is there a
>>>method for distributing labels for PWs that should run within
>>TE LSP tunnel?
>>>I am aware of the IETF draft for signaling the PWs' labels
>>using the LDP
>>>protocol, but I would like to attach a certain PW with a
>>certain TE LSP
>>>tunnel. How can I gain it? Maybe I should activate the LDP
>>for a certain PW
>>>within the required tunnel (inband)? Is there another way to
>>do it but not a
>>>static one (by configuration)?
>>
>>Hi,
>>
>>You can use a targeted LDP session to distribute the labels for a PW
>>between the two PEs.  How that PW travels across the PSN is
>>independent of
>>how the labels for the PW were distributed.  Thus, the PW
>>could use either
>>an LDP LSP or a RSVP-TE LSP to reach the egress PE.  Which one
>>to use and
>>how the PW is mapped to it is an internal issue on the ingress PE.
>>
>>Alia
>>
>>
>>>I wonder also if there is a way to signal a TE PW?
>>>
>>>I'll appreciate your response.
>>>Thanks in advance, Nurit.
>>
>>
>



From owner-mpls@UU.NET  Tue Mar 25 10:30:24 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18108
	for <mpls-archive@lists.ietf.org>; Tue, 25 Mar 2003 10:30:23 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohog03692
	for <mpls-archive@lists.ietf.org>; Tue, 25 Mar 2003 15:32:42 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohog02996;
	Tue, 25 Mar 2003 15:32:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohoe00022
	for mpls-outgoing; Tue, 25 Mar 2003 15:05:20 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohoe29969
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Mar 2003 15:05:11 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohoe24955
	for <mpls@UU.NET>; Tue, 25 Mar 2003 15:04:31 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohoe12485
	for <mpls@UU.NET>; Tue, 25 Mar 2003 15:04:28 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohoe12437
	for <mpls@UU.NET>; Tue, 25 Mar 2003 15:04:27 GMT
Received: from cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2PF48iH017431;
	Tue, 25 Mar 2003 10:04:09 -0500 (EST)
Message-Id: <200303251504.h2PF48iH017431@rtp-core-1.cisco.com>
To: Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>
cc: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        "'Alia Atlas'" <aatlas@avici.com>, mpls@UU.NET,
        "Mustapha Aissaoui (E-mail)" <mustapha.aissaoui@alcatel.com>
Subject: Re: Distributing Labels for PWs within an LSP TE Tunnel 
In-reply-to: Your message of Mon, 24 Mar 2003 10:25:30 +0200.
             <C87E5A01714C7840B92CDED9E79329CA51F965@leopard.seabridge.co.il> 
Reply-To: erosen@cisco.com
User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3
 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2
 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 25 Mar 2003 10:04:08 -0500
From: Eric Rosen <erosen@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


Nurit> I do look for  a way to bind the (LDP) signaled  PWs to the (RSVP-TE)
Nurit> signaled transport tunnel LSP, in a way that both PEs know about it. 

There is no way to do this using the protocols as currently defined. 


From owner-mpls@UU.NET  Tue Mar 25 16:18:06 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04026
	for <mpls-archive@lists.ietf.org>; Tue, 25 Mar 2003 16:18:06 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohpd01996
	for <mpls-archive@lists.ietf.org>; Tue, 25 Mar 2003 21:20:26 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohpd01704;
	Tue, 25 Mar 2003 21:20:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohpb29212
	for mpls-outgoing; Tue, 25 Mar 2003 20:55:06 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQohpb29199
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Mar 2003 20:54:45 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohpb15126
	for <mpls@uu.net>; Tue, 25 Mar 2003 20:53:59 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohpb01260
	for <mpls@uu.net>; Tue, 25 Mar 2003 20:53:58 GMT
Received: from nomad.tcb.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: division.aa.arbor.net [204.181.64.2])
	id QQohpb01226
	for <mpls@uu.net>; Tue, 25 Mar 2003 20:53:57 GMT
Received: by nomad.tcb.net (Postfix, from userid 500)
	id 83A7855F62; Tue, 25 Mar 2003 13:53:09 -0700 (MST)
Received: from nomad.tcb.net (localhost [127.0.0.1])
	by nomad.tcb.net (Postfix) with ESMTP
	id 82B6B3E83; Tue, 25 Mar 2003 13:53:09 -0700 (MST)
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
To: pwe3@ietf.org, mpls@UU.NET
From: Danny McPherson <danny@tcb.net>
Reply-To: danny@tcb.net
Subject: Re: [PWE3] MPLS PID 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 25 Mar 2003 13:53:04 -0700
Message-Id: <20030325205309.83A7855F62@nomad.tcb.net>
Sender: owner-mpls@UU.NET
Precedence: bulk


[Note the cross-post, let's try to move this to MPLS please]

I tend to agree with Mark & George (and others) that it should 
be addressed in the MPLS WG, with feedback from PWE3.

PWE3 Architecture and perhaps Requirements (ugh!) work should be 
added as appropriate, please send your comments on what needs to 
be done there ASAP, if you haven't already.

-danny


> 
> I agree too that the PID issue is more of an MPLS issue in general. As such, the 
> I think the MPLS WG should be tasked with defining exactly what the PID looks 
> like, and what internode behavior relying on the PID is allowed.
> 
> However, the PWE3 architecture cannot ignore this entirely. It is PWE3's direct 
> use of MPLS as its own PSN more than anything else that is imposing this 
> practical requirement now (though I suppose it has theoretically always been an 
> issue), and any definition coming from the MPLS WG would likely be in the form 
> of a requirement on any header definition that rides directly adjacent to the 
> last MPLS label in a stack. We all know that this would probably look something 
> like simply stating that the first four bits MUST be 4 for IPv4, 6 for IPv6, and 
> up to IANA and the MPLS WG for future additions. Whether that means handing out 
> values form the remaining 14 available under very tight control (at a minimum, 
> via an RFC2434 Standards Action and the MPLS WGs blessing), or some other 
> extended PID method, should be up to MPLS to ultimately decide and PWE3 to 
> adhere to. This would all be done with PWE3's input of course, since there would 
> be a lot of overlap in the folks making the decision.
> 
> Regarding whether the MPLS WG has discussed this before, Eric Rosen suggested at 
> the microphone in SF that it had, but at that time the decision obviously was to 
> not include a PID within MPLS. The bottom line is that perhaps we are seeing 
> that in hindsight this was an error, and if so this should be openly resolved 
> within the MPLS WG.
> 
> - Mark
> 
> Andrew G. Malis wrote:
> > I would just like to second Ron's questions below, and also add that 
> > there's no mention of the need for a protocol identification field in 
> > the PWE3 requirements draft.
> > 
> > Also, I noticed that the architecture draft had no recognition of the 
> > TDM control word format; it only discussed the control word used for L2 
> > encapsulations.
> > 
> > So, I would like to request the following change in 
> > draft-ietf-pwe3-arch-02.txt:
> > 
> > 5.4.3. PW over MPLS Generic Control Word
> > 
> >    The PW set-up protocol determines whether a particular PW uses a
> >    control word.  When a control word is used, it MUST have the
> >    following form for non-TDM encapsulations:
> > 
> >        0                   1                   2                   3
> >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |   RSVD/Flags  |FRG|  Length   | Sequence Number               |
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> >         Figure 12 - MPLS Generic Control Word
> > 
> > 
> >    The meaning of the fields of the MPLS Generic Control Word (Figure
> >    12) is as follows:
> > 
> >        RSVD/Flags (bits 0 to 7):
> >            These bits are available for per payload signaling. Their
> >            definition is encapsulation specific.  If not all of the bits
> >            are required for flags, some may be reserved for future use.
> > 
> >        FRG (bits 8 and 9):
> >            These bits are used when fragmenting a PW payload. Their use
> >            is defined in [FRAG].
> > 
> >        Length (bits 10 to 15):
> >            The length field is used to determine the size of a PW
> >            payload that might have been padded to the minimum Ethernet
> >            MAC frame size during its transit across the PSN.  If the
> >            MPLS payload (defined as the CW + the PW payload + any
> >            additional PW headers is less than 46 bytes, the length MUST
> >            be set to the length of the MPLS payload.  If the MPLS
> >            payload is between 46 bytes and 63 bytes the implementation
> >            MAY either set to the length to the length of the MPLS
> >            payload, or it MAY set it to 0.  If the length of the MPLS
> >            payload is greater than 63 bytes the length MUST be set to 0.
> > 
> >        Sequence number (Bit 16 to 31):
> >            If the sequence number is not used, it is set to zero by
> >            the sender and ignored by the receiver.  Otherwise it
> >            specifies the sequence number of a packet. A circular list
> >            of sequence numbers is used. A sequence number takes a value
> >            from 1 to 65535 (2**16-1).
> > 
> > For TDM applications, it must use the following general forms.
> > 
> > Non-extended form:
> >     0                   1                   2                   3
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |0| Flags | Structure Pointer[0:12] |  Sequence Number[0:13]    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> > Extended form:
> >     0                   1                   2                   3
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |1| Flags | Structure Pointer[0:12] |  Sequence Number[0:13]    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |         Additional encapsulation-specific header fields       |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> >    Structure Pointer[0:12]: If used, the Structure Pointer contains the
> >    offset of the first byte of the payload structure.  Note that some
> >    TDM encapsulations do not require the use of a Structure Pointer,
> >    in which case this field may be reused for other uses.
> > 
> >    Sequence Number[0:13]:  This is a packet sequence number, which
> >    continuously cycles from 0 to 0x3FFF.  It is generated and processed
> >    in accordance with the rules established in [RFC1889].  When the RTP
> >    header is used, this sequence number MUST match the LSBs of the RTP
> >    sequence Number.
> > 
> > Thanks,
> > Andy
> > 
> > -------
> > 
> > At 3/23/2003 10:04 AM +0200, Ron Cohen wrote:
> > 
> >> Stewart,
> >>
> >> I went over your SF arch presentation. I have doubts regarding the
> >> introduction of a requirement/suggestion for an all zero PID field
> >> within the PWE3 control word. My doubts relates both to the scope of
> >> this work as well as for the applications you are describing. Since I
> >> haven't been to the SF IETF, please forgive me in advance if these
> >> issues have already been discussed.
> >>
> >>
> >> MPLS PID scope:
> >> --------------
> >> In your presentation you describe a requirement/suggestion for an MPLS
> >> PID, that allows a network node to distinguish between an IPv4, IPv6 and
> >> PWE3 stream. The Multi-Protocol part of MPLS stands for carrying any
> >> network protocol on top of MPLS, including possibly IPX, CLNS, etc.
> >> Therefore, what you are proposing is introduction of an MPLS Protocol
> >> Identifier, which I believe has a much larger scope than just the PWE3
> >> WG.
> >>
> >> 1. Would you agree that this is an MPLS WG item? Has this requirement
> >> (MPLS PID) been discussed in the MPLS WG before / are there any drafts
> >> written?
> >>
> >> 2. If so, would 4 bits suffice for an MPLS PID?
> >>
> >>
> >> Applications:
> >> ------------
> >> You list a number of applications that require IP flow recognition,
> >> including load balancing, billing, and protection against network abuse
> >> and attacks. I would like to better understand if these applications
> >> indeed require the introduction of the PID field. For example, are these
> >> applications edge applications? Do these applications run on all LSPs,
> >> or are sensitive to BE LSP vs. LSP with priority? Do you run these
> >> applications on TE paths?
> >>
> >> 1. Are there any drafts that describe these applications?
> >>
> >> 2. If not, could you elaborate on each application, its scope, etc?
> >>
> >>
> >> Thanks
> >> Ron
> >>
> >> Ron Cohen
> >> CTO
> >> Lycium Networks
> >> Desk: +972 9 7619004
> >> Mobile: +972 55 245104
> >> Fax: +972 9 7619022
> >>
> >>
> >>
> >> _______________________________________________
> >> pwe3 mailing list
> >> pwe3@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/pwe3
> > 
> > 
> > _______________________________________________
> > pwe3 mailing list
> > pwe3@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pwe3
> > 
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3





From owner-mpls@UU.NET  Tue Mar 25 16:58:30 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05763
	for <mpls-archive@lists.ietf.org>; Tue, 25 Mar 2003 16:58:29 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohpg16349
	for <mpls-archive@lists.ietf.org>; Tue, 25 Mar 2003 22:00:48 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohpg15867;
	Tue, 25 Mar 2003 22:00:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohpe20708
	for mpls-outgoing; Tue, 25 Mar 2003 21:35:06 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohpe20702
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Mar 2003 21:35:04 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohpe17632
	for <mpls@uu.net>; Tue, 25 Mar 2003 21:34:51 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohpe15242
	for <mpls@uu.net>; Tue, 25 Mar 2003 21:34:50 GMT
Received: from zcars04f.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57])
	id QQohpe15230
	for <mpls@uu.net>; Tue, 25 Mar 2003 21:34:50 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2PLYfI23689;
	Tue, 25 Mar 2003 16:34:41 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <GDF47V0R>; Tue, 25 Mar 2003 16:34:41 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D016D2BE6@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'danny@tcb.net'" <danny@tcb.net>, mpls@UU.NET
Subject: RE: [PWE3] MPLS PID 
Date: Tue, 25 Mar 2003 16:34:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2F316.56409BA0"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2F316.56409BA0
Content-Type: text/plain;
	charset="iso-8859-1"

MPLS issue or IP/IANA issue? This is v4 and v6 headers we're discussing.

Similarly I would want to consider what the inherent ability to protocol
multiplex traffic on any LSP "means". Previously payload was negotiated via
signalling and explicitly fixed for any specific label. Now we'll be into
policy as to what PIDs are acceptable. Whereas before we had the simplicity
of one label<->one protocol, in the future that will no longer be true.

IMHO we shouldn't rush to codify the ECMP hack.

cheers
Dave



> -----Original Message-----
> From: Danny McPherson [mailto:danny@tcb.net] 
> Sent: Tuesday, March 25, 2003 3:53 PM
> To: pwe3@ietf.org; mpls@uu.net
> Subject: Re: [PWE3] MPLS PID 
> 
> 
> 
> [Note the cross-post, let's try to move this to MPLS please]
> 
> I tend to agree with Mark & George (and others) that it should 
> be addressed in the MPLS WG, with feedback from PWE3.
> 
> PWE3 Architecture and perhaps Requirements (ugh!) work should be 
> added as appropriate, please send your comments on what needs to 
> be done there ASAP, if you haven't already.
> 
> -danny
> 
> 
> > 
> > I agree too that the PID issue is more of an MPLS issue in 
> general. As 
> > such, the
> > I think the MPLS WG should be tasked with defining exactly 
> what the PID looks 
> > like, and what internode behavior relying on the PID is allowed.
> > 
> > However, the PWE3 architecture cannot ignore this entirely. It is 
> > PWE3's direct
> > use of MPLS as its own PSN more than anything else that is 
> imposing this 
> > practical requirement now (though I suppose it has 
> theoretically always been an 
> > issue), and any definition coming from the MPLS WG would 
> likely be in the form 
> > of a requirement on any header definition that rides 
> directly adjacent to the 
> > last MPLS label in a stack. We all know that this would 
> probably look something 
> > like simply stating that the first four bits MUST be 4 for 
> IPv4, 6 for IPv6, and 
> > up to IANA and the MPLS WG for future additions. Whether 
> that means handing out 
> > values form the remaining 14 available under very tight 
> control (at a minimum, 
> > via an RFC2434 Standards Action and the MPLS WGs blessing), 
> or some other 
> > extended PID method, should be up to MPLS to ultimately 
> decide and PWE3 to 
> > adhere to. This would all be done with PWE3's input of 
> course, since there would 
> > be a lot of overlap in the folks making the decision.
> > 
> > Regarding whether the MPLS WG has discussed this before, Eric Rosen 
> > suggested at
> > the microphone in SF that it had, but at that time the 
> decision obviously was to 
> > not include a PID within MPLS. The bottom line is that 
> perhaps we are seeing 
> > that in hindsight this was an error, and if so this should 
> be openly resolved 
> > within the MPLS WG.
> > 
> > - Mark
> > 
> > Andrew G. Malis wrote:
> > > I would just like to second Ron's questions below, and 
> also add that
> > > there's no mention of the need for a protocol 
> identification field in 
> > > the PWE3 requirements draft.
> > > 
> > > Also, I noticed that the architecture draft had no recognition of 
> > > the
> > > TDM control word format; it only discussed the control 
> word used for L2 
> > > encapsulations.
> > > 
> > > So, I would like to request the following change in
> > > draft-ietf-pwe3-arch-02.txt:
> > > 
> > > 5.4.3. PW over MPLS Generic Control Word
> > > 
> > >    The PW set-up protocol determines whether a particular 
> PW uses a
> > >    control word.  When a control word is used, it MUST have the
> > >    following form for non-TDM encapsulations:
> > > 
> > >        0                   1                   2          
>          3
> > >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 
> 5 6 7 8 9 0 1
> > >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >       |   RSVD/Flags  |FRG|  Length   | Sequence Number   
>             |
> > >       
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > 
> > >         Figure 12 - MPLS Generic Control Word
> > > 
> > > 
> > >    The meaning of the fields of the MPLS Generic Control 
> Word (Figure
> > >    12) is as follows:
> > > 
> > >        RSVD/Flags (bits 0 to 7):
> > >            These bits are available for per payload 
> signaling. Their
> > >            definition is encapsulation specific.  If not 
> all of the bits
> > >            are required for flags, some may be reserved 
> for future 
> > > use.
> > > 
> > >        FRG (bits 8 and 9):
> > >            These bits are used when fragmenting a PW 
> payload. Their use
> > >            is defined in [FRAG].
> > > 
> > >        Length (bits 10 to 15):
> > >            The length field is used to determine the size of a PW
> > >            payload that might have been padded to the 
> minimum Ethernet
> > >            MAC frame size during its transit across the 
> PSN.  If the
> > >            MPLS payload (defined as the CW + the PW payload + any
> > >            additional PW headers is less than 46 bytes, 
> the length MUST
> > >            be set to the length of the MPLS payload.  If the MPLS
> > >            payload is between 46 bytes and 63 bytes the 
> implementation
> > >            MAY either set to the length to the length of the MPLS
> > >            payload, or it MAY set it to 0.  If the length 
> of the MPLS
> > >            payload is greater than 63 bytes the length 
> MUST be set 
> > > to 0.
> > > 
> > >        Sequence number (Bit 16 to 31):
> > >            If the sequence number is not used, it is set 
> to zero by
> > >            the sender and ignored by the receiver.  Otherwise it
> > >            specifies the sequence number of a packet. A 
> circular list
> > >            of sequence numbers is used. A sequence number 
> takes a value
> > >            from 1 to 65535 (2**16-1).
> > > 
> > > For TDM applications, it must use the following general forms.
> > > 
> > > Non-extended form:
> > >     0                   1                   2                   3
> > >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 
> 7 8 9 0 1
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |0| Flags | Structure Pointer[0:12] |  Sequence 
> Number[0:13]    |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > 
> > > Extended form:
> > >     0                   1                   2                   3
> > >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 
> 7 8 9 0 1
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |1| Flags | Structure Pointer[0:12] |  Sequence 
> Number[0:13]    |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |         Additional encapsulation-specific header 
> fields       |
> > >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > 
> > >    Structure Pointer[0:12]: If used, the Structure 
> Pointer contains the
> > >    offset of the first byte of the payload structure.  
> Note that some
> > >    TDM encapsulations do not require the use of a 
> Structure Pointer,
> > >    in which case this field may be reused for other uses.
> > > 
> > >    Sequence Number[0:13]:  This is a packet sequence number, which
> > >    continuously cycles from 0 to 0x3FFF.  It is generated 
> and processed
> > >    in accordance with the rules established in [RFC1889]. 
>  When the RTP
> > >    header is used, this sequence number MUST match the 
> LSBs of the RTP
> > >    sequence Number.
> > > 
> > > Thanks,
> > > Andy
> > > 
> > > -------
> > > 
> > > At 3/23/2003 10:04 AM +0200, Ron Cohen wrote:
> > > 
> > >> Stewart,
> > >>
> > >> I went over your SF arch presentation. I have doubts 
> regarding the 
> > >> introduction of a requirement/suggestion for an all zero 
> PID field 
> > >> within the PWE3 control word. My doubts relates both to 
> the scope 
> > >> of this work as well as for the applications you are describing. 
> > >> Since I haven't been to the SF IETF, please forgive me 
> in advance 
> > >> if these issues have already been discussed.
> > >>
> > >>
> > >> MPLS PID scope:
> > >> --------------
> > >> In your presentation you describe a 
> requirement/suggestion for an 
> > >> MPLS PID, that allows a network node to distinguish between an 
> > >> IPv4, IPv6 and PWE3 stream. The Multi-Protocol part of 
> MPLS stands 
> > >> for carrying any network protocol on top of MPLS, including 
> > >> possibly IPX, CLNS, etc. Therefore, what you are proposing is 
> > >> introduction of an MPLS Protocol Identifier, which I 
> believe has a 
> > >> much larger scope than just the PWE3 WG.
> > >>
> > >> 1. Would you agree that this is an MPLS WG item? Has this 
> > >> requirement (MPLS PID) been discussed in the MPLS WG 
> before / are 
> > >> there any drafts written?
> > >>
> > >> 2. If so, would 4 bits suffice for an MPLS PID?
> > >>
> > >>
> > >> Applications:
> > >> ------------
> > >> You list a number of applications that require IP flow 
> recognition, 
> > >> including load balancing, billing, and protection 
> against network 
> > >> abuse and attacks. I would like to better understand if these 
> > >> applications indeed require the introduction of the PID 
> field. For 
> > >> example, are these applications edge applications? Do these 
> > >> applications run on all LSPs, or are sensitive to BE LSP vs. LSP 
> > >> with priority? Do you run these applications on TE paths?
> > >>
> > >> 1. Are there any drafts that describe these applications?
> > >>
> > >> 2. If not, could you elaborate on each application, its 
> scope, etc?
> > >>
> > >>
> > >> Thanks
> > >> Ron
> > >>
> > >> Ron Cohen
> > >> CTO
> > >> Lycium Networks
> > >> Desk: +972 9 7619004
> > >> Mobile: +972 55 245104
> > >> Fax: +972 9 7619022
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> pwe3 mailing list
> > >> pwe3@ietf.org
> > >> https://www1.ietf.org/mailman/listinfo/pwe3
> > > 
> > > 
> > > _______________________________________________
> > > pwe3 mailing list
> > > pwe3@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/pwe3
> > > 
> > 
> > _______________________________________________
> > pwe3 mailing list
> > pwe3@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pwe3
> 
> 
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
> 

------_=_NextPart_001_01C2F316.56409BA0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [PWE3] MPLS PID </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>MPLS issue or IP/IANA issue? This is v4 and v6 =
headers we're discussing.</FONT>
</P>

<P><FONT SIZE=3D2>Similarly I would want to consider what the inherent =
ability to protocol multiplex traffic on any LSP &quot;means&quot;. =
Previously payload was negotiated via signalling and explicitly fixed =
for any specific label. Now we'll be into policy as to what PIDs are =
acceptable. Whereas before we had the simplicity of one =
label&lt;-&gt;one protocol, in the future that will no longer be =
true.</FONT></P>

<P><FONT SIZE=3D2>IMHO we shouldn't rush to codify the ECMP =
hack.</FONT>
</P>

<P><FONT SIZE=3D2>cheers</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Danny McPherson [<A =
HREF=3D"mailto:danny@tcb.net">mailto:danny@tcb.net</A>] </FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, March 25, 2003 3:53 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: pwe3@ietf.org; mpls@uu.net</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [PWE3] MPLS PID </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [Note the cross-post, let's try to move this to =
MPLS please]</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I tend to agree with Mark &amp; George (and =
others) that it should </FONT>
<BR><FONT SIZE=3D2>&gt; be addressed in the MPLS WG, with feedback from =
PWE3.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; PWE3 Architecture and perhaps Requirements =
(ugh!) work should be </FONT>
<BR><FONT SIZE=3D2>&gt; added as appropriate, please send your comments =
on what needs to </FONT>
<BR><FONT SIZE=3D2>&gt; be done there ASAP, if you haven't =
already.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -danny</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I agree too that the PID issue is more of =
an MPLS issue in </FONT>
<BR><FONT SIZE=3D2>&gt; general. As </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; such, the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I think the MPLS WG should be tasked with =
defining exactly </FONT>
<BR><FONT SIZE=3D2>&gt; what the PID looks </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; like, and what internode behavior relying =
on the PID is allowed.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; However, the PWE3 architecture cannot =
ignore this entirely. It is </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; PWE3's direct</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; use of MPLS as its own PSN more than =
anything else that is </FONT>
<BR><FONT SIZE=3D2>&gt; imposing this </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; practical requirement now (though I =
suppose it has </FONT>
<BR><FONT SIZE=3D2>&gt; theoretically always been an </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; issue), and any definition coming from the =
MPLS WG would </FONT>
<BR><FONT SIZE=3D2>&gt; likely be in the form </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; of a requirement on any header definition =
that rides </FONT>
<BR><FONT SIZE=3D2>&gt; directly adjacent to the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; last MPLS label in a stack. We all know =
that this would </FONT>
<BR><FONT SIZE=3D2>&gt; probably look something </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; like simply stating that the first four =
bits MUST be 4 for </FONT>
<BR><FONT SIZE=3D2>&gt; IPv4, 6 for IPv6, and </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; up to IANA and the MPLS WG for future =
additions. Whether </FONT>
<BR><FONT SIZE=3D2>&gt; that means handing out </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; values form the remaining 14 available =
under very tight </FONT>
<BR><FONT SIZE=3D2>&gt; control (at a minimum, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; via an RFC2434 Standards Action and the =
MPLS WGs blessing), </FONT>
<BR><FONT SIZE=3D2>&gt; or some other </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; extended PID method, should be up to MPLS =
to ultimately </FONT>
<BR><FONT SIZE=3D2>&gt; decide and PWE3 to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; adhere to. This would all be done with =
PWE3's input of </FONT>
<BR><FONT SIZE=3D2>&gt; course, since there would </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; be a lot of overlap in the folks making =
the decision.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Regarding whether the MPLS WG has =
discussed this before, Eric Rosen </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; suggested at</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the microphone in SF that it had, but at =
that time the </FONT>
<BR><FONT SIZE=3D2>&gt; decision obviously was to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; not include a PID within MPLS. The bottom =
line is that </FONT>
<BR><FONT SIZE=3D2>&gt; perhaps we are seeing </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that in hindsight this was an error, and =
if so this should </FONT>
<BR><FONT SIZE=3D2>&gt; be openly resolved </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; within the MPLS WG.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; - Mark</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Andrew G. Malis wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I would just like to second Ron's =
questions below, and </FONT>
<BR><FONT SIZE=3D2>&gt; also add that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; there's no mention of the need for a =
protocol </FONT>
<BR><FONT SIZE=3D2>&gt; identification field in </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the PWE3 requirements draft.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Also, I noticed that the architecture =
draft had no recognition of </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; TDM control word format; it only =
discussed the control </FONT>
<BR><FONT SIZE=3D2>&gt; word used for L2 </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; encapsulations.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; So, I would like to request the =
following change in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; draft-ietf-pwe3-arch-02.txt:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; 5.4.3. PW over MPLS Generic Control =
Word</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; The PW set-up =
protocol determines whether a particular </FONT>
<BR><FONT SIZE=3D2>&gt; PW uses a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; control word.&nbsp; =
When a control word is used, it MUST have the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; following form for =
non-TDM encapsulations:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
3</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0 1 2 3 4 5 6 7 8 9 0 1 =
2 3 4 5 6 7 8 9 0 1 2 3 4 </FONT>
<BR><FONT SIZE=3D2>&gt; 5 6 7 8 9 0 1</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT SIZE=3D2>&gt; =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</FONT>=

<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp; RSVD/Flags&nbsp; |FRG|&nbsp; Length&nbsp;&nbsp; | =
Sequence Number&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</FONT>=

<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Figure 12 - MPLS =
Generic Control Word</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; The meaning of the =
fields of the MPLS Generic Control </FONT>
<BR><FONT SIZE=3D2>&gt; Word (Figure</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; 12) is as =
follows:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RSVD/Flags (bits 0 to =
7):</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
These bits are available for per payload </FONT>
<BR><FONT SIZE=3D2>&gt; signaling. Their</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
definition is encapsulation specific.&nbsp; If not </FONT>
<BR><FONT SIZE=3D2>&gt; all of the bits</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
are required for flags, some may be reserved </FONT>
<BR><FONT SIZE=3D2>&gt; for future </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; use.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FRG (bits 8 and =
9):</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
These bits are used when fragmenting a PW </FONT>
<BR><FONT SIZE=3D2>&gt; payload. Their use</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
is defined in [FRAG].</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Length (bits 10 to =
15):</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
The length field is used to determine the size of a PW</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
payload that might have been padded to the </FONT>
<BR><FONT SIZE=3D2>&gt; minimum Ethernet</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
MAC frame size during its transit across the </FONT>
<BR><FONT SIZE=3D2>&gt; PSN.&nbsp; If the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
MPLS payload (defined as the CW + the PW payload + any</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
additional PW headers is less than 46 bytes, </FONT>
<BR><FONT SIZE=3D2>&gt; the length MUST</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
be set to the length of the MPLS payload.&nbsp; If the MPLS</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
payload is between 46 bytes and 63 bytes the </FONT>
<BR><FONT SIZE=3D2>&gt; implementation</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
MAY either set to the length to the length of the MPLS</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
payload, or it MAY set it to 0.&nbsp; If the length </FONT>
<BR><FONT SIZE=3D2>&gt; of the MPLS</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
payload is greater than 63 bytes the length </FONT>
<BR><FONT SIZE=3D2>&gt; MUST be set </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; to 0.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sequence number (Bit 16 =
to 31):</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
If the sequence number is not used, it is set </FONT>
<BR><FONT SIZE=3D2>&gt; to zero by</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
the sender and ignored by the receiver.&nbsp; Otherwise it</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
specifies the sequence number of a packet. A </FONT>
<BR><FONT SIZE=3D2>&gt; circular list</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
of sequence numbers is used. A sequence number </FONT>
<BR><FONT SIZE=3D2>&gt; takes a value</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
from 1 to 65535 (2**16-1).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; For TDM applications, it must use the =
following general forms.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Non-extended form:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; =
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; 0 1 2 3 4 5 6 =
7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 </FONT>
<BR><FONT SIZE=3D2>&gt; 7 8 9 0 1</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</FONT>=

<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; |0| Flags | =
Structure Pointer[0:12] |&nbsp; Sequence </FONT>
<BR><FONT SIZE=3D2>&gt; Number[0:13]&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</FONT>=

<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Extended form:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; =
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; 0 1 2 3 4 5 6 =
7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 </FONT>
<BR><FONT SIZE=3D2>&gt; 7 8 9 0 1</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</FONT>=

<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; |1| Flags | =
Structure Pointer[0:12] |&nbsp; Sequence </FONT>
<BR><FONT SIZE=3D2>&gt; Number[0:13]&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</FONT>=

<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Additional =
encapsulation-specific header </FONT>
<BR><FONT SIZE=3D2>&gt; fields&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</FONT>=

<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; Structure =
Pointer[0:12]: If used, the Structure </FONT>
<BR><FONT SIZE=3D2>&gt; Pointer contains the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; offset of the first =
byte of the payload structure.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; Note that some</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; TDM encapsulations =
do not require the use of a </FONT>
<BR><FONT SIZE=3D2>&gt; Structure Pointer,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; in which case this =
field may be reused for other uses.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; Sequence =
Number[0:13]:&nbsp; This is a packet sequence number, which</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; continuously cycles =
from 0 to 0x3FFF.&nbsp; It is generated </FONT>
<BR><FONT SIZE=3D2>&gt; and processed</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; in accordance with =
the rules established in [RFC1889]. </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; When the RTP</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; header is used, =
this sequence number MUST match the </FONT>
<BR><FONT SIZE=3D2>&gt; LSBs of the RTP</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; sequence =
Number.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Andy</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; -------</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; At 3/23/2003 10:04 AM +0200, Ron =
Cohen wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; Stewart,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; I went over your SF arch =
presentation. I have doubts </FONT>
<BR><FONT SIZE=3D2>&gt; regarding the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; introduction of a =
requirement/suggestion for an all zero </FONT>
<BR><FONT SIZE=3D2>&gt; PID field </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; within the PWE3 control word. My =
doubts relates both to </FONT>
<BR><FONT SIZE=3D2>&gt; the scope </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; of this work as well as for the =
applications you are describing. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; Since I haven't been to the SF =
IETF, please forgive me </FONT>
<BR><FONT SIZE=3D2>&gt; in advance </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; if these issues have already been =
discussed.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; MPLS PID scope:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; --------------</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; In your presentation you describe =
a </FONT>
<BR><FONT SIZE=3D2>&gt; requirement/suggestion for an </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; MPLS PID, that allows a network =
node to distinguish between an </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; IPv4, IPv6 and PWE3 stream. The =
Multi-Protocol part of </FONT>
<BR><FONT SIZE=3D2>&gt; MPLS stands </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; for carrying any network protocol =
on top of MPLS, including </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; possibly IPX, CLNS, etc. =
Therefore, what you are proposing is </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; introduction of an MPLS Protocol =
Identifier, which I </FONT>
<BR><FONT SIZE=3D2>&gt; believe has a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; much larger scope than just the =
PWE3 WG.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; 1. Would you agree that this is =
an MPLS WG item? Has this </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; requirement (MPLS PID) been =
discussed in the MPLS WG </FONT>
<BR><FONT SIZE=3D2>&gt; before / are </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; there any drafts written?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; 2. If so, would 4 bits suffice =
for an MPLS PID?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; Applications:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; ------------</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; You list a number of applications =
that require IP flow </FONT>
<BR><FONT SIZE=3D2>&gt; recognition, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; including load balancing, =
billing, and protection </FONT>
<BR><FONT SIZE=3D2>&gt; against network </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; abuse and attacks. I would like =
to better understand if these </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; applications indeed require the =
introduction of the PID </FONT>
<BR><FONT SIZE=3D2>&gt; field. For </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; example, are these applications =
edge applications? Do these </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; applications run on all LSPs, or =
are sensitive to BE LSP vs. LSP </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; with priority? Do you run these =
applications on TE paths?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; 1. Are there any drafts that =
describe these applications?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; 2. If not, could you elaborate on =
each application, its </FONT>
<BR><FONT SIZE=3D2>&gt; scope, etc?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; Thanks</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; Ron</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; Ron Cohen</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; CTO</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; Lycium Networks</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; Desk: +972 9 7619004</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; Mobile: +972 55 245104</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; Fax: +972 9 7619022</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; pwe3 mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; pwe3@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/pwe3" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/pwe3</A></FONT>=

<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; pwe3 mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; pwe3@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/pwe3" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/pwe3</A></FONT>=

<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; pwe3 mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; pwe3@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/pwe3" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/pwe3</A></FONT>=

<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; pwe3 mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; pwe3@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/pwe3" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/pwe3</A></FONT>=

<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2F316.56409BA0--


From owner-mpls@UU.NET  Tue Mar 25 17:46:09 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07837
	for <mpls-archive@lists.ietf.org>; Tue, 25 Mar 2003 17:46:09 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohpj09821
	for <mpls-archive@lists.ietf.org>; Tue, 25 Mar 2003 22:48:29 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohpj09307;
	Tue, 25 Mar 2003 22:48:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohph12890
	for mpls-outgoing; Tue, 25 Mar 2003 22:21:53 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQohph12881
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Mar 2003 22:21:45 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohph05154
	for <mpls@uu.net>; Tue, 25 Mar 2003 22:20:08 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohph18243
	for <mpls@uu.net>; Tue, 25 Mar 2003 22:20:07 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohph18224
	for <mpls@uu.net>; Tue, 25 Mar 2003 22:20:07 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2PMK3iH023137
	for <mpls@uu.net>; Tue, 25 Mar 2003 17:20:04 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA23571 for <mpls@uu.net>; Tue, 25 Mar 2003 17:20:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2PMK3E27537 for mpls@uu.net; Tue, 25 Mar 2003 17:20:03 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohph12651
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Mar 2003 22:19:17 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohph27751
	for <mpls@uu.net>; Tue, 25 Mar 2003 22:18:44 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohph19106
	for <mpls@uu.net>; Tue, 25 Mar 2003 22:18:44 GMT
Received: from mother.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [216.241.224.12])
	id QQohph19083
	for <mpls@uu.net>; Tue, 25 Mar 2003 22:18:43 GMT
Received: (qmail 12231 invoked by uid 104); 25 Mar 2003 22:18:37 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4253.  Clear:. 
 Processed in 0.443284 secs); 25 Mar 2003 22:18:37 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by mother.pmc-sierra.com with SMTP; 25 Mar 2003 22:18:36 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h2PMISh11131;
	Tue, 25 Mar 2003 14:18:28 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <DCP4TFMH>; Tue, 25 Mar 2003 14:18:28 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115C829@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'George Swallow'" <swallow@cisco.com>,
        "W. Mark Townsley"
	 <townsley@cisco.com>
Cc: "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'"
	 <mpls@UU.NET>
Subject: RE: [PWE3] MPLS PID 
Date: Tue, 25 Mar 2003 14:18:26 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk


>1.  Dealing with ECMP behavior
>2.  Inband OAM flows
>3.  Identifying flows for netmanagement applications.
>

I don't think any of them justifies adding PID. 

1) ECMP could use only label hashing and not hash IP header.
2) OAM flows could use IPv4/V6 null or MPLS Alert label
3) Netmanagment could identify the flow at the ingress. 


-Shahram



From owner-mpls@UU.NET  Tue Mar 25 18:39:45 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11194
	for <mpls-archive@lists.ietf.org>; Tue, 25 Mar 2003 18:39:45 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohpm04355
	for <mpls-archive@lists.ietf.org>; Tue, 25 Mar 2003 23:42:06 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohpm03879;
	Tue, 25 Mar 2003 23:41:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohpl05742
	for mpls-outgoing; Tue, 25 Mar 2003 23:16:27 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohpl05728
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Mar 2003 23:16:24 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohpl22279
	for <mpls@uu.net>; Tue, 25 Mar 2003 23:15:09 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohpl04555
	for <mpls@uu.net>; Tue, 25 Mar 2003 23:15:09 GMT
Received: from mailhost.avici.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [12.38.212.174])
	id QQohpl04536
	for <mpls@uu.net>; Tue, 25 Mar 2003 23:15:09 GMT
Received: from aatlas-lt.avici.com (b2-pc95.avici.com [10.2.100.125])
	by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id h2PNF2C00027;
	Tue, 25 Mar 2003 18:15:02 -0500 (EST)
Message-Id: <5.1.0.14.2.20030325181331.02012640@mailhost.avici.com>
X-Sender: aatlas@mailhost.avici.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 25 Mar 2003 18:15:22 -0500
To: danny@tcb.net
From: Alia Atlas <aatlas@avici.com>
Subject: Re: [PWE3] MPLS PID 
Cc: pwe3@ietf.org, mpls@UU.NET
In-Reply-To: <20030325205309.83A7855F62@nomad.tcb.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

How does requiring a PID in the PWE3 L2 control word solve or handle the 
case where a control word is not mandatory?

There are pseudo-wires, such as ethernet, where a control word is not 
mandatory.  This would imply that the first nibble (which would be 
identified as the suggested PID) would be that from the ethernet frame.

Alia

At 01:53 PM 3/25/2003 -0700, Danny McPherson wrote:

>[Note the cross-post, let's try to move this to MPLS please]
>
>I tend to agree with Mark & George (and others) that it should
>be addressed in the MPLS WG, with feedback from PWE3.
>
>PWE3 Architecture and perhaps Requirements (ugh!) work should be
>added as appropriate, please send your comments on what needs to
>be done there ASAP, if you haven't already.
>
>-danny
>
>
> >
> > I agree too that the PID issue is more of an MPLS issue in general. As 
> such, the
> > I think the MPLS WG should be tasked with defining exactly what the PID 
> looks
> > like, and what internode behavior relying on the PID is allowed.
> >
> > However, the PWE3 architecture cannot ignore this entirely. It is 
> PWE3's direct
> > use of MPLS as its own PSN more than anything else that is imposing this
> > practical requirement now (though I suppose it has theoretically always 
> been an
> > issue), and any definition coming from the MPLS WG would likely be in 
> the form
> > of a requirement on any header definition that rides directly adjacent 
> to the
> > last MPLS label in a stack. We all know that this would probably look 
> something
> > like simply stating that the first four bits MUST be 4 for IPv4, 6 for 
> IPv6, and
> > up to IANA and the MPLS WG for future additions. Whether that means 
> handing out
> > values form the remaining 14 available under very tight control (at a 
> minimum,
> > via an RFC2434 Standards Action and the MPLS WGs blessing), or some other
> > extended PID method, should be up to MPLS to ultimately decide and PWE3 to
> > adhere to. This would all be done with PWE3's input of course, since 
> there would
> > be a lot of overlap in the folks making the decision.
> >
> > Regarding whether the MPLS WG has discussed this before, Eric Rosen 
> suggested at
> > the microphone in SF that it had, but at that time the decision 
> obviously was to
> > not include a PID within MPLS. The bottom line is that perhaps we are 
> seeing
> > that in hindsight this was an error, and if so this should be openly 
> resolved
> > within the MPLS WG.
> >
> > - Mark
> >
> > Andrew G. Malis wrote:
> > > I would just like to second Ron's questions below, and also add that
> > > there's no mention of the need for a protocol identification field in
> > > the PWE3 requirements draft.
> > >
> > > Also, I noticed that the architecture draft had no recognition of the
> > > TDM control word format; it only discussed the control word used for L2
> > > encapsulations.
> > >
> > > So, I would like to request the following change in
> > > draft-ietf-pwe3-arch-02.txt:
> > >
> > > 5.4.3. PW over MPLS Generic Control Word
> > >
> > >    The PW set-up protocol determines whether a particular PW uses a
> > >    control word.  When a control word is used, it MUST have the
> > >    following form for non-TDM encapsulations:
> > >
> > >        0                   1                   2                   3
> > >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >       |   RSVD/Flags  |FRG|  Length   | Sequence Number               |
> > >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > >         Figure 12 - MPLS Generic Control Word
> > >
> > >
> > >    The meaning of the fields of the MPLS Generic Control Word (Figure
> > >    12) is as follows:
> > >
> > >        RSVD/Flags (bits 0 to 7):
> > >            These bits are available for per payload signaling. Their
> > >            definition is encapsulation specific.  If not all of the bits
> > >            are required for flags, some may be reserved for future use.
> > >
> > >        FRG (bits 8 and 9):
> > >            These bits are used when fragmenting a PW payload. Their use
> > >            is defined in [FRAG].
> > >
> > >        Length (bits 10 to 15):
> > >            The length field is used to determine the size of a PW
> > >            payload that might have been padded to the minimum Ethernet
> > >            MAC frame size during its transit across the PSN.  If the
> > >            MPLS payload (defined as the CW + the PW payload + any
> > >            additional PW headers is less than 46 bytes, the length MUST
> > >            be set to the length of the MPLS payload.  If the MPLS
> > >            payload is between 46 bytes and 63 bytes the implementation
> > >            MAY either set to the length to the length of the MPLS
> > >            payload, or it MAY set it to 0.  If the length of the MPLS
> > >            payload is greater than 63 bytes the length MUST be set to 0.
> > >
> > >        Sequence number (Bit 16 to 31):
> > >            If the sequence number is not used, it is set to zero by
> > >            the sender and ignored by the receiver.  Otherwise it
> > >            specifies the sequence number of a packet. A circular list
> > >            of sequence numbers is used. A sequence number takes a value
> > >            from 1 to 65535 (2**16-1).
> > >
> > > For TDM applications, it must use the following general forms.
> > >
> > > Non-extended form:
> > >     0                   1                   2                   3
> > >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |0| Flags | Structure Pointer[0:12] |  Sequence Number[0:13]    |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > > Extended form:
> > >     0                   1                   2                   3
> > >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |1| Flags | Structure Pointer[0:12] |  Sequence Number[0:13]    |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >    |         Additional encapsulation-specific header fields       |
> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > >    Structure Pointer[0:12]: If used, the Structure Pointer contains the
> > >    offset of the first byte of the payload structure.  Note that some
> > >    TDM encapsulations do not require the use of a Structure Pointer,
> > >    in which case this field may be reused for other uses.
> > >
> > >    Sequence Number[0:13]:  This is a packet sequence number, which
> > >    continuously cycles from 0 to 0x3FFF.  It is generated and processed
> > >    in accordance with the rules established in [RFC1889].  When the RTP
> > >    header is used, this sequence number MUST match the LSBs of the RTP
> > >    sequence Number.
> > >
> > > Thanks,
> > > Andy
> > >
> > > -------
> > >
> > > At 3/23/2003 10:04 AM +0200, Ron Cohen wrote:
> > >
> > >> Stewart,
> > >>
> > >> I went over your SF arch presentation. I have doubts regarding the
> > >> introduction of a requirement/suggestion for an all zero PID field
> > >> within the PWE3 control word. My doubts relates both to the scope of
> > >> this work as well as for the applications you are describing. Since I
> > >> haven't been to the SF IETF, please forgive me in advance if these
> > >> issues have already been discussed.
> > >>
> > >>
> > >> MPLS PID scope:
> > >> --------------
> > >> In your presentation you describe a requirement/suggestion for an MPLS
> > >> PID, that allows a network node to distinguish between an IPv4, IPv6 and
> > >> PWE3 stream. The Multi-Protocol part of MPLS stands for carrying any
> > >> network protocol on top of MPLS, including possibly IPX, CLNS, etc.
> > >> Therefore, what you are proposing is introduction of an MPLS Protocol
> > >> Identifier, which I believe has a much larger scope than just the PWE3
> > >> WG.
> > >>
> > >> 1. Would you agree that this is an MPLS WG item? Has this requirement
> > >> (MPLS PID) been discussed in the MPLS WG before / are there any drafts
> > >> written?
> > >>
> > >> 2. If so, would 4 bits suffice for an MPLS PID?
> > >>
> > >>
> > >> Applications:
> > >> ------------
> > >> You list a number of applications that require IP flow recognition,
> > >> including load balancing, billing, and protection against network abuse
> > >> and attacks. I would like to better understand if these applications
> > >> indeed require the introduction of the PID field. For example, are these
> > >> applications edge applications? Do these applications run on all LSPs,
> > >> or are sensitive to BE LSP vs. LSP with priority? Do you run these
> > >> applications on TE paths?
> > >>
> > >> 1. Are there any drafts that describe these applications?
> > >>
> > >> 2. If not, could you elaborate on each application, its scope, etc?
> > >>
> > >>
> > >> Thanks
> > >> Ron
> > >>
> > >> Ron Cohen
> > >> CTO
> > >> Lycium Networks
> > >> Desk: +972 9 7619004
> > >> Mobile: +972 55 245104
> > >> Fax: +972 9 7619022
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> pwe3 mailing list
> > >> pwe3@ietf.org
> > >> https://www1.ietf.org/mailman/listinfo/pwe3
> > >
> > >
> > > _______________________________________________
> > > pwe3 mailing list
> > > pwe3@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/pwe3
> > >
> >
> > _______________________________________________
> > pwe3 mailing list
> > pwe3@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pwe3
>
>
>
>_______________________________________________
>pwe3 mailing list
>pwe3@ietf.org
>https://www1.ietf.org/mailman/listinfo/pwe3




From owner-mpls@UU.NET  Tue Mar 25 19:17:29 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12570
	for <mpls-archive@lists.ietf.org>; Tue, 25 Mar 2003 19:17:28 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohpp01328
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 00:19:41 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohpp00813;
	Wed, 26 Mar 2003 00:19:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohpn08169
	for mpls-outgoing; Tue, 25 Mar 2003 23:53:50 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQohpn08164
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Mar 2003 23:53:39 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohpn28599
	for <mpls@uu.net>; Tue, 25 Mar 2003 23:52:19 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohpn11918
	for <mpls@uu.net>; Tue, 25 Mar 2003 23:52:18 GMT
Received: from ns2.vivacenetworks.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [64.221.212.135])
	id QQohpn11877
	for <mpls@uu.net>; Tue, 25 Mar 2003 23:52:17 GMT
Received: from amalisxp.vivacenetworks.com ([10.120.0.2]) by vivacenetworks.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 25 Mar 2003 15:52:15 -0800
Message-Id: <5.2.0.9.0.20030325184106.059779b8@po1.vivacenetworks.com>
X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 25 Mar 2003 18:52:02 -0500
To: pwe3@ietf.org
From: "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>
Subject: RE: [PWE3] MPLS PID 
Cc: mpls@UU.NET
In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C829@nt-exch-yow.pmc-s
 ierra.bc.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 25 Mar 2003 23:52:15.0676 (UTC) FILETIME=[901C07C0:01C2F329]
Sender: owner-mpls@UU.NET
Precedence: bulk

Shahram and Alia both make excellent points:

At 3/25/2003 02:18 PM -0800, Shahram Davari wrote:
> >1.  Dealing with ECMP behavior
> >2.  Inband OAM flows
> >3.  Identifying flows for netmanagement applications.
>
>I don't think any of them justifies adding PID.
>
>1) ECMP could use only label hashing and not hash IP header.
>2) OAM flows could use IPv4/V6 null or MPLS Alert label
>3) Netmanagment could identify the flow at the ingress.

At 3/25/2003 06:15 PM -0500, Alia Atlas wrote:
>How does requiring a PID in the PWE3 L2 control word solve or handle the 
>case where a control word is not mandatory?
>
>There are pseudo-wires, such as ethernet, where a control word is not 
>mandatory.  This would imply that the first nibble (which would be 
>identified as the suggested PID) would be that from the ethernet frame.

We're going to have to change the PWE3 drafts to require the control word, 
and change both the SONET/SDH and some of the ATM encapsulations, to 
support a hack.  If you REALLY want multi-protocol identification, then 
have the MPLS WG put a REAL multiprotocol identifier, a la RFC 2427 or 
2684, between the labels and the payload.  See, for example, 
draft-moreels-multiproto-mpls-00.txt for a much more general (and useful) 
method than just a four-bit hack.  And sorry for the cross-post, but this 
really does affect both WGs.

Cheers,
Andy



From owner-mpls@UU.NET  Tue Mar 25 21:13:55 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15126
	for <mpls-archive@lists.ietf.org>; Tue, 25 Mar 2003 21:13:55 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohpx04024
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 02:16:14 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohpx03379;
	Wed, 26 Mar 2003 02:15:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohpv23344
	for mpls-outgoing; Wed, 26 Mar 2003 01:49:28 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohpv23337
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 01:49:10 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohpv21823
	for <mpls@UU.NET>; Wed, 26 Mar 2003 01:49:08 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohpv02013
	for <mpls@UU.NET>; Wed, 26 Mar 2003 01:49:05 GMT
Received: from ns2.vivacenetworks.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [64.221.212.135])
	id QQohpv01980
	for <mpls@UU.NET>; Wed, 26 Mar 2003 01:49:04 GMT
Received: from amalisxp.vivacenetworks.com ([10.120.0.2]) by vivacenetworks.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 25 Mar 2003 17:49:02 -0800
Message-Id: <5.2.0.9.0.20030325204017.05d28298@po1.vivacenetworks.com>
X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 25 Mar 2003 20:48:54 -0500
To: erosen@cisco.com
From: "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>
Subject: Re: Distributing Labels for PWs within an LSP TE Tunnel 
Cc: mpls@UU.NET
In-Reply-To: <200303251504.h2PF48iH017431@rtp-core-1.cisco.com>
References: <Your message of Mon, 24 Mar 2003 10:25:30 +0200. <C87E5A01714C7840B92CDED9E79329CA51F965@leopard.seabridge.co.il>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 26 Mar 2003 01:49:02.0451 (UTC) FILETIME=[E0790C30:01C2F339]
Sender: owner-mpls@UU.NET
Precedence: bulk

At 3/25/2003 10:04 AM -0500, Eric Rosen wrote:

>Nurit> I do look for  a way to bind the (LDP) signaled  PWs to the (RSVP-TE)
>Nurit> signaled transport tunnel LSP, in a way that both PEs know about it.
>
>There is no way to do this using the protocols as currently defined.

I agree with Eric, and it's the way it is for a very good reason - as a 
result of requiring PW labels in the platform label space, deciding which 
RSVP-TE tunnel to use for the LDP-signaled PWs is purely a local matter at 
the PE that's encapsulating the L2 frames.  This allows a number of nice 
properties, such as the ability to very easily switch to a backup tunnel if 
there's a primary tunnel failure and the network isn't using FRR in the 
core, or to load-share over multiple tunnels if the PW doesn't have 
sequentiality requirements (or has partial sequentiality 
requirements).  Using end-to-end signaling to bind a PW to a particular 
tunnel removes these properties.

Cheers,
Andy



From owner-mpls@UU.NET  Tue Mar 25 22:17:37 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16608
	for <mpls-archive@lists.ietf.org>; Tue, 25 Mar 2003 22:17:37 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohqb05162
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 03:19:57 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohqb04620;
	Wed, 26 Mar 2003 03:19:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohpz17140
	for mpls-outgoing; Wed, 26 Mar 2003 02:53:51 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohpz17135
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 02:53:45 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohpz27325
	for <mpls@UU.NET>; Wed, 26 Mar 2003 02:52:37 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohpz07987
	for <mpls@UU.NET>; Wed, 26 Mar 2003 02:52:37 GMT
Received: from exchange.timetra.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host-64-47-48-7.masergy.com [64.47.48.7] (may be forged))
	id QQohpz07977
	for <mpls@UU.NET>; Wed, 26 Mar 2003 02:52:36 GMT
Received: from vkompella ([64.47.48.10] RDNS failed) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 25 Mar 2003 18:52:33 -0800
Reply-To: <vkompella@timetra.com>
From: "Vach Kompella" <vkompella@timetra.com>
To: "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>, <erosen@cisco.com>
Cc: <mpls@UU.NET>
Subject: RE: Distributing Labels for PWs within an LSP TE Tunnel 
Date: Tue, 25 Mar 2003 18:52:37 -0800
Message-ID: <FNEFIPCNJKDDONJGBCNEMEKMDMAA.vkompella@timetra.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <5.2.0.9.0.20030325204017.05d28298@po1.vivacenetworks.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300
X-OriginalArrivalTime: 26 Mar 2003 02:52:33.0824 (UTC) FILETIME=[C03A6A00:01C2F342]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

One of the problems with the new version of the pwe3-control draft is that the
line that says that the platform label space must be used has been dropped from
the text.  I assume that this was unintentional because it doesn't make sense to
use interface-specific labels.  However, it became apparent at the ISOCORE
interop that one vendor didn't realize this.

Could it please be re-inserted, right after where it says liberal label
retention should be used?

  "VC labels MUST be allocated from the per-platform label space."

Thanks.

-Vach

> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Andrew G.
> Malis
> Sent: Tuesday, March 25, 2003 5:49 PM
> To: erosen@cisco.com
> Cc: mpls@UU.NET
> Subject: Re: Distributing Labels for PWs within an LSP TE Tunnel
>
>
> At 3/25/2003 10:04 AM -0500, Eric Rosen wrote:
>
> >Nurit> I do look for  a way to bind the (LDP) signaled  PWs to the (RSVP-TE)
> >Nurit> signaled transport tunnel LSP, in a way that both PEs know about it.
> >
> >There is no way to do this using the protocols as currently defined.
>
> I agree with Eric, and it's the way it is for a very good reason - as a
> result of requiring PW labels in the platform label space, deciding which
> RSVP-TE tunnel to use for the LDP-signaled PWs is purely a local matter at
> the PE that's encapsulating the L2 frames.  This allows a number of nice
> properties, such as the ability to very easily switch to a backup tunnel if
> there's a primary tunnel failure and the network isn't using FRR in the
> core, or to load-share over multiple tunnels if the PW doesn't have
> sequentiality requirements (or has partial sequentiality
> requirements).  Using end-to-end signaling to bind a PW to a particular
> tunnel removes these properties.
>
> Cheers,
> Andy
>
>




From owner-mpls@UU.NET  Wed Mar 26 09:52:13 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28362
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 09:52:13 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohrv14351
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 14:54:33 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohrv13778;
	Wed, 26 Mar 2003 14:54:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohrt17128
	for mpls-outgoing; Wed, 26 Mar 2003 14:27:04 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohrt17123
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 14:27:01 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohrt07347
	for <mpls@uu.net>; Wed, 26 Mar 2003 14:26:13 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohrt23603
	for <mpls@uu.net>; Wed, 26 Mar 2003 14:26:10 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQohrt23553
	for <mpls@uu.net>; Wed, 26 Mar 2003 14:26:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2QEQ2MR009881
	for <mpls@uu.net>; Wed, 26 Mar 2003 09:26:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA11376 for <mpls@uu.net>; Wed, 26 Mar 2003 09:26:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2QEQ2E14734 for mpls@uu.net; Wed, 26 Mar 2003 09:26:02 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQohrt16899
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 14:25:30 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohrt04765
	for <mpls@uu.net>; Wed, 26 Mar 2003 14:24:27 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohrt18450
	for <mpls@uu.net>; Wed, 26 Mar 2003 14:24:27 GMT
Received: from ams-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ams-msg-core-1.cisco.com [144.254.74.60])
	id QQohrt18422
	for <mpls@uu.net>; Wed, 26 Mar 2003 14:24:25 GMT
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2QEMchf008693;
	Wed, 26 Mar 2003 15:22:38 +0100 (MET)
Received: from cisco.com (ams-clip-vpn-dhcp4143.cisco.com [10.61.80.46])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id PAA25806;
	Wed, 26 Mar 2003 15:24:21 +0100 (MET)
Message-ID: <3E81B815.5050209@cisco.com>
Date: Wed, 26 Mar 2003 15:24:21 +0100
From: "W. Mark Townsley" <townsley@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>
CC: pwe3@ietf.org, mpls@UU.NET
Subject: Re: [PWE3] MPLS PID
References: <5.2.0.9.0.20030325184106.059779b8@po1.vivacenetworks.com>
In-Reply-To: <5.2.0.9.0.20030325184106.059779b8@po1.vivacenetworks.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



Andrew G. Malis wrote:
> Shahram and Alia both make excellent points:
> 
> At 3/25/2003 02:18 PM -0800, Shahram Davari wrote:
> 
>> >1.  Dealing with ECMP behavior
>> >2.  Inband OAM flows
>> >3.  Identifying flows for netmanagement applications.
>>
>> I don't think any of them justifies adding PID.
>>
>> 1) ECMP could use only label hashing and not hash IP header.
>> 2) OAM flows could use IPv4/V6 null or MPLS Alert label
>> 3) Netmanagment could identify the flow at the ingress.
> 
> 
> At 3/25/2003 06:15 PM -0500, Alia Atlas wrote:
> 
>> How does requiring a PID in the PWE3 L2 control word solve or handle 
>> the case where a control word is not mandatory?
>>
>> There are pseudo-wires, such as ethernet, where a control word is not 
>> mandatory.  This would imply that the first nibble (which would be 
>> identified as the suggested PID) would be that from the ethernet frame.
> 
> 
> We're going to have to change the PWE3 drafts to require the control 
> word, and change both the SONET/SDH and some of the ATM encapsulations, 
> to support a hack.  If you REALLY want multi-protocol identification, 
> then have the MPLS WG put a REAL multiprotocol identifier, a la RFC 2427 
> or 2684, between the labels and the payload.  See, for example, 
> draft-moreels-multiproto-mpls-00.txt for a much more general (and 
> useful) method than just a four-bit hack.  And sorry for the cross-post, 
> but this really does affect both WGs.

Andy,

The draft you reference here (which, incidently, simply seems to focus on 
multiple new ways to carry PPP and PPPoE over MPLS vs. just using RFC2661) 
doesn't directly address the problem at hand as one is still faced with 
inspecting the first nibble after the bottom of the label stack to determine if 
the payload is IPv4, IPv6, LLC/NLPID (0xf...) or LLC/SNAP (0xa...).

If we are going to be essentially allocating from the first nibble anyway (and I 
can't see how we could get around this considering existing deployments) we 
should go ahead and be explicit about it. If the MPLS WG wants to have a more 
broad and extensive protocol ID than just this first nibble, that is fine, but I 
do not think you can avoid explicitly taking these 4 bits into account without 
deprecating the whole of all MPLS/IP deployments today.

One possibility for an extended PID that comes to mind is defining one of the 
remaining 14 values within the first nibble as "extended PID" and follow it with 
whatever PID definition you like.

- Mark

> 
> Cheers,
> Andy
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
> 



From owner-mpls@UU.NET  Wed Mar 26 10:17:19 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00281
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 10:17:19 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohrx08047
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 15:19:39 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohrx07654;
	Wed, 26 Mar 2003 15:19:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohrv19563
	for mpls-outgoing; Wed, 26 Mar 2003 14:53:34 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohrv19553
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 14:53:25 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohrv16140
	for <mpls@UU.NET>; Wed, 26 Mar 2003 14:52:33 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohrv19547
	for <mpls@UU.NET>; Wed, 26 Mar 2003 14:52:32 GMT
Received: from mta1.wss.scd.yahoo.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mta1.wss.scd.yahoo.com [66.218.85.32])
	id QQohrv19493
	for <mpls@UU.NET>; Wed, 26 Mar 2003 14:52:31 GMT
Received: from ISOVAIO003 (65.213.193.2) by mta1.wss.scd.yahoo.com (6.5.034) (authenticated as rpapneja@isocore.com)
        id 3E7B8B22003701E7; Wed, 26 Mar 2003 06:52:21 -0800
Message-ID: <056201c2f3a7$4e22b2a0$02c1d541@ISOVAIO003>
From: "Rajiv Papneja" <rpapneja@isocore.com>
To: <vkompella@timetra.com>, "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        <erosen@cisco.com>
Cc: <mpls@UU.NET>
References: <FNEFIPCNJKDDONJGBCNEMEKMDMAA.vkompella@timetra.com>
Subject: Re: Distributing Labels for PWs within an LSP TE Tunnel 
Date: Wed, 26 Mar 2003 09:52:20 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Section 3 in draft-ietf-pwe3-control-protocol-01.txt.

Due to this ambiguity, we were never able to bring up the VC tunnels because
one of the vendor followed pwe3-control draft and other followed
draft-martini-l2circuit-trans-mpls-10.txt.

Thanks Vach for pointing out this issue.

 -Rajiv

----- Original Message -----
From: "Vach Kompella" <vkompella@timetra.com>
To: "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>; <erosen@cisco.com>
Cc: <mpls@UU.NET>
Sent: Tuesday, March 25, 2003 9:52 PM
Subject: RE: Distributing Labels for PWs within an LSP TE Tunnel


> One of the problems with the new version of the pwe3-control draft is that
the
> line that says that the platform label space must be used has been dropped
from
> the text.  I assume that this was unintentional because it doesn't make
sense to
> use interface-specific labels.  However, it became apparent at the ISOCORE
> interop that one vendor didn't realize this.
>
> Could it please be re-inserted, right after where it says liberal label
> retention should be used?
>
>   "VC labels MUST be allocated from the per-platform label space."
>
> Thanks.
>
> -Vach
>
> > -----Original Message-----
> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Andrew G.
> > Malis
> > Sent: Tuesday, March 25, 2003 5:49 PM
> > To: erosen@cisco.com
> > Cc: mpls@UU.NET
> > Subject: Re: Distributing Labels for PWs within an LSP TE Tunnel
> >
> >
> > At 3/25/2003 10:04 AM -0500, Eric Rosen wrote:
> >
> > >Nurit> I do look for  a way to bind the (LDP) signaled  PWs to the
(RSVP-TE)
> > >Nurit> signaled transport tunnel LSP, in a way that both PEs know about
it.
> > >
> > >There is no way to do this using the protocols as currently defined.
> >
> > I agree with Eric, and it's the way it is for a very good reason - as a
> > result of requiring PW labels in the platform label space, deciding
which
> > RSVP-TE tunnel to use for the LDP-signaled PWs is purely a local matter
at
> > the PE that's encapsulating the L2 frames.  This allows a number of nice
> > properties, such as the ability to very easily switch to a backup tunnel
if
> > there's a primary tunnel failure and the network isn't using FRR in the
> > core, or to load-share over multiple tunnels if the PW doesn't have
> > sequentiality requirements (or has partial sequentiality
> > requirements).  Using end-to-end signaling to bind a PW to a particular
> > tunnel removes these properties.
> >
> > Cheers,
> > Andy
> >
> >
>
>



From owner-mpls@UU.NET  Wed Mar 26 14:07:20 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07734
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 14:07:20 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsm05469
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 19:09:41 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohsm05053;
	Wed, 26 Mar 2003 19:09:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohsk19013
	for mpls-outgoing; Wed, 26 Mar 2003 18:40:48 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohsk19008
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 18:40:44 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohsk09377
	for <mpls@uu.net>; Wed, 26 Mar 2003 18:39:06 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsk08737
	for <mpls@uu.net>; Wed, 26 Mar 2003 18:39:06 GMT
Received: from zcars0m9.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157])
	id QQohsk08728
	for <mpls@uu.net>; Wed, 26 Mar 2003 18:39:05 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2QIcMb05502;
	Wed, 26 Mar 2003 13:38:22 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <GDF48G0Y>; Wed, 26 Mar 2003 13:38:21 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D016D2BEC@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'Yaakov Stein'" <yaakov_s@rad.com>,
        "W. Mark Townsley"
	 <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>
Cc: pwe3@ietf.org, mpls@UU.NET
Subject: RE: [PWE3] MPLS PID
Date: Wed, 26 Mar 2003 13:38:20 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2F3C6.DFF2F612"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2F3C6.DFF2F612
Content-Type: text/plain;
	charset="iso-8859-1"

Yakov:

We don't have 14 values, we are talking inferring payload on the basis of
defacto IETF protocol payloads (IPv4 and IPv6). PWE3 and MPLS do not own
IPv4/v6 or any subsequent network layer protocols the IETF may choose to
develop. 

I agree with Andy that if a PID is required, lets do it properly. 

Dave

> -----Original Message-----
> From: Yaakov Stein [mailto:yaakov_s@rad.com] 
> Sent: Wednesday, March 26, 2003 11:08 AM
> To: W. Mark Townsley; Andrew G. Malis
> Cc: pwe3@ietf.org; mpls@uu.net
> Subject: RE: [PWE3] MPLS PID
> 
> 
> > One possibility for an extended PID that comes to mind is
> > defining one of the remaining 14 values within the first 
> nibble as "extended PID" 
> > and follow it with whatever PID definition you like.
> 
> Another, which I proposed in draft-stein-pwe3-controlword-00.txt, 
> is to use the 4 bits to disambiguate the relevant possibilities.
> 
> Since an atm-encap implementation will probably not 
> understand ethernet-encap, the non 4/6 values could be used 
> for submodes (e.g. 1:1, N:1, PDU, SDU). Similarly, the TDM 
> sub-identifier could differentiate between raw,  AAL1, AAL2, etc.
> 
> Alternatively, we could go for a "sanity check"
> PWE identifier. We have 14 values available
> and so far have only defined a few PW types
> (ATM, FR, SONET, TDM, ethernet).
> 
> Y(J)S
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
> 

------_=_NextPart_001_01C2F3C6.DFF2F612
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [PWE3] MPLS PID</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Yakov:</FONT>
</P>

<P><FONT SIZE=3D2>We don't have 14 values, we are talking inferring =
payload on the basis of defacto IETF protocol payloads (IPv4 and IPv6). =
PWE3 and MPLS do not own IPv4/v6 or any subsequent network layer =
protocols the IETF may choose to develop. </FONT></P>

<P><FONT SIZE=3D2>I agree with Andy that if a PID is required, lets do =
it properly. </FONT>
</P>

<P><FONT SIZE=3D2>Dave</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Yaakov Stein [<A =
HREF=3D"mailto:yaakov_s@rad.com">mailto:yaakov_s@rad.com</A>] </FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, March 26, 2003 11:08 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: W. Mark Townsley; Andrew G. Malis</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: pwe3@ietf.org; mpls@uu.net</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [PWE3] MPLS PID</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; One possibility for an extended PID that =
comes to mind is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; defining one of the remaining 14 values =
within the first </FONT>
<BR><FONT SIZE=3D2>&gt; nibble as &quot;extended PID&quot; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; and follow it with whatever PID definition =
you like.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Another, which I proposed in =
draft-stein-pwe3-controlword-00.txt, </FONT>
<BR><FONT SIZE=3D2>&gt; is to use the 4 bits to disambiguate the =
relevant possibilities.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Since an atm-encap implementation will probably =
not </FONT>
<BR><FONT SIZE=3D2>&gt; understand ethernet-encap, the non 4/6 values =
could be used </FONT>
<BR><FONT SIZE=3D2>&gt; for submodes (e.g. 1:1, N:1, PDU, SDU). =
Similarly, the TDM </FONT>
<BR><FONT SIZE=3D2>&gt; sub-identifier could differentiate between =
raw,&nbsp; AAL1, AAL2, etc.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Alternatively, we could go for a &quot;sanity =
check&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; PWE identifier. We have 14 values =
available</FONT>
<BR><FONT SIZE=3D2>&gt; and so far have only defined a few PW =
types</FONT>
<BR><FONT SIZE=3D2>&gt; (ATM, FR, SONET, TDM, ethernet).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Y(J)S</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; pwe3 mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; pwe3@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/pwe3" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/pwe3</A></FONT>=

<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2F3C6.DFF2F612--


From owner-mpls@UU.NET  Wed Mar 26 14:26:25 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08531
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 14:26:25 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsn29263
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 19:28:46 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohsn28815;
	Wed, 26 Mar 2003 19:28:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohsl20415
	for mpls-outgoing; Wed, 26 Mar 2003 18:54:52 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohsl20406
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 18:54:35 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohsl28948
	for <mpls@uu.net>; Wed, 26 Mar 2003 18:54:07 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsl00325
	for <mpls@uu.net>; Wed, 26 Mar 2003 18:54:06 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohsl00300
	for <mpls@uu.net>; Wed, 26 Mar 2003 18:54:06 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2QIs3iH004658
	for <mpls@uu.net>; Wed, 26 Mar 2003 13:54:04 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA04014 for <mpls@uu.net>; Wed, 26 Mar 2003 13:54:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2QIs3M29853 for mpls@uu.net; Wed, 26 Mar 2003 13:54:03 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohsl20344
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 18:53:27 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohsl23273
	for <mpls@UU.NET>; Wed, 26 Mar 2003 18:51:54 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsl26493
	for <mpls@UU.NET>; Wed, 26 Mar 2003 18:51:54 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohsl26477
	for <mpls@UU.NET>; Wed, 26 Mar 2003 18:51:53 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2QIpRiH004071;
	Wed, 26 Mar 2003 13:51:27 -0500 (EST)
Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA03812; Wed, 26 Mar 2003 13:51:26 -0500 (EST)
Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id NAA06995; Wed, 26 Mar 2003 13:51:26 -0500 (EST)
Message-Id: <200303261851.NAA06995@bifocal.cisco.com>
X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs
To: Alia Atlas <aatlas@avici.com>
cc: danny@tcb.net, pwe3@ietf.org, mpls@UU.NET, swallow@cisco.com
Subject: Re: [PWE3] MPLS PID 
In-reply-to: Your message of "Tue, 25 Mar 2003 18:15:22 EST."
             <5.1.0.14.2.20030325181331.02012640@mailhost.avici.com> 
Date: Wed, 26 Mar 2003 13:51:26 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

> How does requiring a PID in the PWE3 L2 control word solve or handle the 
> case where a control word is not mandatory?

It doesn't.  But it does give an operator concerned with ECMP and flow
identification a means of doing it.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824



From owner-mpls@UU.NET  Wed Mar 26 14:34:57 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08969
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 14:34:56 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohso10798
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 19:37:18 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohso10334;
	Wed, 26 Mar 2003 19:37:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohsm01870
	for mpls-outgoing; Wed, 26 Mar 2003 19:03:53 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohsm01663
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 19:03:38 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohsl06498
	for <mpls@uu.net>; Wed, 26 Mar 2003 18:58:08 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsl20700
	for <mpls@uu.net>; Wed, 26 Mar 2003 18:58:08 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQohsl20696
	for <mpls@uu.net>; Wed, 26 Mar 2003 18:58:07 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2QIw4MR004470
	for <mpls@uu.net>; Wed, 26 Mar 2003 13:58:05 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA04358 for <mpls@uu.net>; Wed, 26 Mar 2003 13:58:04 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2QIw4Z00149 for mpls@uu.net; Wed, 26 Mar 2003 13:58:04 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohsl20657
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 18:57:00 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohsl02213
	for <mpls@uu.net>; Wed, 26 Mar 2003 18:56:27 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsl18777
	for <mpls@uu.net>; Wed, 26 Mar 2003 18:56:26 GMT
Received: from sj-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-core-1.cisco.com [171.71.177.237])
	id QQohsl18760
	for <mpls@uu.net>; Wed, 26 Mar 2003 18:56:26 GMT
Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34])
	by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2QIuM4c029554;
	Wed, 26 Mar 2003 10:56:22 -0800 (PST)
Received: from cisco.com (sjc-vpn3-168.cisco.com [10.21.64.168])
	by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA)
	with SMTP id AFA58886;
	Wed, 26 Mar 2003 10:55:08 -0800 (PST)
Received: by cisco.com (sSMTP sendmail emulation); Wed, 26 Mar 2003 13:56:22 -0500
Date: Wed, 26 Mar 2003 13:56:22 -0500
From: Scott W Brim <sbrim@cisco.com>
To: pwe3@ietf.org, mpls@UU.NET
Subject: Re: [PWE3] MPLS PID
Message-ID: <20030326185622.GF2124@sbrim-w2k>
Mail-Followup-To: Scott W Brim <sbrim@cisco.com>, pwe3@ietf.org,
	mpls@uu.net
References: <FFFC48AEAA5F7447929F4F0D93FCC12D016D2BEC@zcard031.ca.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <FFFC48AEAA5F7447929F4F0D93FCC12D016D2BEC@zcard031.ca.nortel.com>
User-Agent: Mutt/1.4i
Sender: owner-mpls@UU.NET
Precedence: bulk

On Wed, Mar 26, 2003 01:38:20PM -0500, David Allan allegedly wrote:
> We don't have 14 values, we are talking inferring payload on the basis of
> defacto IETF protocol payloads (IPv4 and IPv6). PWE3 and MPLS do not own
> IPv4/v6 or any subsequent network layer protocols the IETF may choose to
> develop. 

Are you trying to say that we can't guarantee coordination between a
group developing new versions of IP and the MPLS community?  This is a
small logistical problem.  In the absolute worst case we get assignments
from IANA to cover the few we need.

(See http://www.iana.org/assignments/version-numbers).



From owner-mpls@UU.NET  Wed Mar 26 14:42:35 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09274
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 14:42:35 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohso24254
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 19:44:57 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohso23939;
	Wed, 26 Mar 2003 19:44:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohsn11062
	for mpls-outgoing; Wed, 26 Mar 2003 19:15:15 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohsm10796
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 19:14:59 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohsm18445
	for <mpls@uu.net>; Wed, 26 Mar 2003 19:14:12 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsm05798
	for <mpls@uu.net>; Wed, 26 Mar 2003 19:14:11 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohsm05767
	for <mpls@uu.net>; Wed, 26 Mar 2003 19:14:10 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2QJE7iH009705
	for <mpls@uu.net>; Wed, 26 Mar 2003 14:14:08 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA05833 for <mpls@uu.net>; Wed, 26 Mar 2003 14:14:07 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2QJE7J03000 for mpls@uu.net; Wed, 26 Mar 2003 14:14:07 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohsm10672
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 19:12:53 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohsm12025
	for <mpls@uu.net>; Wed, 26 Mar 2003 19:11:22 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsm00834
	for <mpls@uu.net>; Wed, 26 Mar 2003 19:11:21 GMT
Received: from mother.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [216.241.224.12])
	id QQohsm00787
	for <mpls@uu.net>; Wed, 26 Mar 2003 19:11:21 GMT
Received: (qmail 6572 invoked by uid 104); 26 Mar 2003 19:11:19 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4253.  Clear:. 
 Processed in 0.598446 secs); 26 Mar 2003 19:11:19 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by mother.pmc-sierra.com with SMTP; 26 Mar 2003 19:11:18 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h2QJBDh22384;
	Wed, 26 Mar 2003 11:11:18 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <DCP4TYGX>; Wed, 26 Mar 2003 11:11:13 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115C830@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'David Allan'" <dallan@nortelnetworks.com>,
        "'Yaakov Stein'"
	 <yaakov_s@rad.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>
Cc: pwe3@ietf.org, mpls@UU.NET
Subject: RE: [PWE3] MPLS PID
Date: Wed, 26 Mar 2003 11:11:10 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2F3CB.763A5440"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2F3CB.763A5440
Content-Type: text/plain;
	charset="iso-8859-1"

I also agree with Dave/Andy/Ron/Alia. If PID is needed, do it properly by defining a standard protocol Mux header such as LLC/SNAP. Those interested in identifying the protocol in the interior routers would then require to carry this header in all packets.
 
-Shahram

-----Original Message-----
From: David Allan [mailto:dallan@nortelnetworks.com]
Sent: Wednesday, March 26, 2003 1:38 PM
To: 'Yaakov Stein'; W. Mark Townsley; Andrew G. Malis
Cc: pwe3@ietf.org; mpls@uu.net
Subject: RE: [PWE3] MPLS PID



Yakov: 

We don't have 14 values, we are talking inferring payload on the basis of defacto IETF protocol payloads (IPv4 and IPv6). PWE3 and MPLS do not own IPv4/v6 or any subsequent network layer protocols the IETF may choose to develop. 

I agree with Andy that if a PID is required, lets do it properly. 

Dave 

> -----Original Message----- 
> From: Yaakov Stein [ mailto:yaakov_s@rad.com <mailto:yaakov_s@rad.com> ] 
> Sent: Wednesday, March 26, 2003 11:08 AM 
> To: W. Mark Townsley; Andrew G. Malis 
> Cc: pwe3@ietf.org; mpls@uu.net 
> Subject: RE: [PWE3] MPLS PID 
> 
> 
> > One possibility for an extended PID that comes to mind is 
> > defining one of the remaining 14 values within the first 
> nibble as "extended PID" 
> > and follow it with whatever PID definition you like. 
> 
> Another, which I proposed in draft-stein-pwe3-controlword-00.txt, 
> is to use the 4 bits to disambiguate the relevant possibilities. 
> 
> Since an atm-encap implementation will probably not 
> understand ethernet-encap, the non 4/6 values could be used 
> for submodes (e.g. 1:1, N:1, PDU, SDU). Similarly, the TDM 
> sub-identifier could differentiate between raw,  AAL1, AAL2, etc. 
> 
> Alternatively, we could go for a "sanity check" 
> PWE identifier. We have 14 values available 
> and so far have only defined a few PW types 
> (ATM, FR, SONET, TDM, ethernet). 
> 
> Y(J)S 
> 
> _______________________________________________ 
> pwe3 mailing list 
> pwe3@ietf.org 
> https://www1.ietf.org/mailman/listinfo/pwe3 <https://www1.ietf.org/mailman/listinfo/pwe3>  
> 


------_=_NextPart_001_01C2F3CB.763A5440
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [PWE3] MPLS PID</TITLE>

<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=041450519-26032003>I also 
agree with Dave/Andy/Ron/Alia. If PID is needed, do it properly by defining a 
standard protocol Mux header such as LLC/SNAP. Those interested in identifying 
the protocol in the interior routers would then require to carry this header in 
all packets.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=041450519-26032003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=041450519-26032003>-Shahram</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> David Allan 
  [mailto:dallan@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, March 26, 2003 
  1:38 PM<BR><B>To:</B> 'Yaakov Stein'; W. Mark Townsley; Andrew G. 
  Malis<BR><B>Cc:</B> pwe3@ietf.org; mpls@uu.net<BR><B>Subject:</B> RE: [PWE3] 
  MPLS PID<BR><BR></DIV></FONT>
  <P><FONT size=2>Yakov:</FONT> </P>
  <P><FONT size=2>We don't have 14 values, we are talking inferring payload on 
  the basis of defacto IETF protocol payloads (IPv4 and IPv6). PWE3 and MPLS do 
  not own IPv4/v6 or any subsequent network layer protocols the IETF may choose 
  to develop. </FONT></P>
  <P><FONT size=2>I agree with Andy that if a PID is required, lets do it 
  properly. </FONT></P>
  <P><FONT size=2>Dave</FONT> </P>
  <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
  From: Yaakov Stein [<A 
  href="mailto:yaakov_s@rad.com">mailto:yaakov_s@rad.com</A>] </FONT><BR><FONT 
  size=2>&gt; Sent: Wednesday, March 26, 2003 11:08 AM</FONT> <BR><FONT 
  size=2>&gt; To: W. Mark Townsley; Andrew G. Malis</FONT> <BR><FONT size=2>&gt; 
  Cc: pwe3@ietf.org; mpls@uu.net</FONT> <BR><FONT size=2>&gt; Subject: RE: 
  [PWE3] MPLS PID</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; &gt; One possibility for an extended PID that 
  comes to mind is</FONT> <BR><FONT size=2>&gt; &gt; defining one of the 
  remaining 14 values within the first </FONT><BR><FONT size=2>&gt; nibble as 
  "extended PID" </FONT><BR><FONT size=2>&gt; &gt; and follow it with whatever 
  PID definition you like.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; Another, which I proposed in draft-stein-pwe3-controlword-00.txt, 
  </FONT><BR><FONT size=2>&gt; is to use the 4 bits to disambiguate the relevant 
  possibilities.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Since 
  an atm-encap implementation will probably not </FONT><BR><FONT size=2>&gt; 
  understand ethernet-encap, the non 4/6 values could be used </FONT><BR><FONT 
  size=2>&gt; for submodes (e.g. 1:1, N:1, PDU, SDU). Similarly, the TDM 
  </FONT><BR><FONT size=2>&gt; sub-identifier could differentiate between 
  raw,&nbsp; AAL1, AAL2, etc.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; Alternatively, we could go for a "sanity check"</FONT> <BR><FONT 
  size=2>&gt; PWE identifier. We have 14 values available</FONT> <BR><FONT 
  size=2>&gt; and so far have only defined a few PW types</FONT> <BR><FONT 
  size=2>&gt; (ATM, FR, SONET, TDM, ethernet).</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; Y(J)S</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; 
  _______________________________________________</FONT> <BR><FONT size=2>&gt; 
  pwe3 mailing list</FONT> <BR><FONT size=2>&gt; pwe3@ietf.org</FONT> <BR><FONT 
  size=2>&gt; <A href="https://www1.ietf.org/mailman/listinfo/pwe3" 
  target=_blank>https://www1.ietf.org/mailman/listinfo/pwe3</A></FONT> <BR><FONT 
  size=2>&gt; </FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C2F3CB.763A5440--



From owner-mpls@UU.NET  Wed Mar 26 15:16:34 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12049
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 15:16:33 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsr11634
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 20:18:54 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohsr11218;
	Wed, 26 Mar 2003 20:18:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohsp14512
	for mpls-outgoing; Wed, 26 Mar 2003 19:50:01 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohsp14478
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 19:49:41 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohsp24924
	for <mpls@uu.net>; Wed, 26 Mar 2003 19:48:29 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsp28557
	for <mpls@uu.net>; Wed, 26 Mar 2003 19:48:29 GMT
Received: from zcars0m9.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157])
	id QQohsp28538
	for <mpls@uu.net>; Wed, 26 Mar 2003 19:48:28 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2QJm0b23010;
	Wed, 26 Mar 2003 14:48:00 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <GDF48JD4>; Wed, 26 Mar 2003 14:48:00 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D016D2BEE@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'Scott W Brim'" <sbrim@cisco.com>, pwe3@ietf.org, mpls@UU.NET
Subject: RE: [PWE3] MPLS PID
Date: Wed, 26 Mar 2003 14:47:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2F3D0.97C27188"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2F3D0.97C27188
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Scott:

I'm sure you can guarantee coordination. Not sure as to how folks feel about
a 4 bit version number being subsumed as a protocol id as it is a rather
scarce resource, therefore the "few we need" actually consititues
potentially a significant amount of that resource (and one will note that
there is already pressure on it just in this discussion). Yes, sure we can
chain bits (if MSbit set then it's really an 8 bit value) bit that's not
pretty if we're planning on it up front, its simply how you get around a
long standing situation.

If we go on the assertion that MPLS should have had a PID (as opposed to
current practice of binding protocols to labels) then we need to scope what
we are really trying to achieve....

1) Make the payload self describing to end points.
2) Multiplex payloads over a single LSP.
3) Make the payload self-describing to intermediate systems.

At the moment, 3 appears to be the exclusive motivation for this but has
implications in 1 & 2 as we already have mechanisms for achieving those
goals today (indirectly via signalling (1) & label stacking (2)). 

IMHO if we were to add a payload identification to MPLS in particular for
intermediate systems to inspect (bottom label is now really 36 or more bits
that happen to overlap with payload), I would want a lot more from it. For
example, it was a problem folks wrestled with when trying to figure out how
to identify OAM flows (where we went with reserved label as a PID and
therefore only had e2e significance), and I'm sure other applications will
come up.

cheers
Dave

> -----Original Message-----
> From: Scott W Brim [mailto:sbrim@cisco.com] 
> Sent: Wednesday, March 26, 2003 1:56 PM
> To: pwe3@ietf.org; mpls@uu.net
> Subject: Re: [PWE3] MPLS PID
> 
> 
> On Wed, Mar 26, 2003 01:38:20PM -0500, David Allan allegedly wrote:
> > We don't have 14 values, we are talking inferring payload 
> on the basis 
> > of defacto IETF protocol payloads (IPv4 and IPv6). PWE3 and MPLS do 
> > not own IPv4/v6 or any subsequent network layer protocols 
> the IETF may 
> > choose to develop.
> 
> Are you trying to say that we can't guarantee coordination 
> between a group developing new versions of IP and the MPLS 
> community?  This is a small logistical problem.  In the 
> absolute worst case we get assignments from IANA to cover the 
> few we need.
> 
> (See http://www.iana.org/assignments/version-numbers).
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
> 

------_=_NextPart_001_01C2F3D0.97C27188
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [PWE3] MPLS PID</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Scott:</FONT>
</P>

<P><FONT SIZE=3D2>I'm sure you can guarantee coordination. Not sure as =
to how folks feel about a 4 bit version number being subsumed as a =
protocol id as it is a rather scarce resource, therefore the &quot;few =
we need&quot; actually consititues potentially a significant amount of =
that resource (and one will note that there is already pressure on it =
just in this discussion). Yes, sure we can chain bits (if MSbit set =
then it's really an 8 bit value) bit that's not pretty if we're =
planning on it up front, its simply how you get around a long standing =
situation.</FONT></P>

<P><FONT SIZE=3D2>If we go on the assertion that MPLS should have had a =
PID (as opposed to current practice of binding protocols to labels) =
then we need to scope what we are really trying to =
achieve....</FONT></P>

<P><FONT SIZE=3D2>1) Make the payload self describing to end =
points.</FONT>
<BR><FONT SIZE=3D2>2) Multiplex payloads over a single LSP.</FONT>
<BR><FONT SIZE=3D2>3) Make the payload self-describing to intermediate =
systems.</FONT>
</P>

<P><FONT SIZE=3D2>At the moment, 3 appears to be the exclusive =
motivation for this but has implications in 1 &amp; 2 as we already =
have mechanisms for achieving those goals today (indirectly via =
signalling (1) &amp; label stacking (2)). </FONT></P>

<P><FONT SIZE=3D2>IMHO if we were to add a payload identification to =
MPLS in particular for intermediate systems to inspect (bottom label is =
now really 36 or more bits that happen to overlap with payload), I =
would want a lot more from it. For example, it was a problem folks =
wrestled with when trying to figure out how to identify OAM flows =
(where we went with reserved label as a PID and therefore only had e2e =
significance), and I'm sure other applications will come up.</FONT></P>

<P><FONT SIZE=3D2>cheers</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Scott W Brim [<A =
HREF=3D"mailto:sbrim@cisco.com">mailto:sbrim@cisco.com</A>] </FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, March 26, 2003 1:56 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: pwe3@ietf.org; mpls@uu.net</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [PWE3] MPLS PID</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On Wed, Mar 26, 2003 01:38:20PM -0500, David =
Allan allegedly wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; We don't have 14 values, we are talking =
inferring payload </FONT>
<BR><FONT SIZE=3D2>&gt; on the basis </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; of defacto IETF protocol payloads (IPv4 =
and IPv6). PWE3 and MPLS do </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; not own IPv4/v6 or any subsequent network =
layer protocols </FONT>
<BR><FONT SIZE=3D2>&gt; the IETF may </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; choose to develop.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Are you trying to say that we can't guarantee =
coordination </FONT>
<BR><FONT SIZE=3D2>&gt; between a group developing new versions of IP =
and the MPLS </FONT>
<BR><FONT SIZE=3D2>&gt; community?&nbsp; This is a small logistical =
problem.&nbsp; In the </FONT>
<BR><FONT SIZE=3D2>&gt; absolute worst case we get assignments from =
IANA to cover the </FONT>
<BR><FONT SIZE=3D2>&gt; few we need.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; (See <A =
HREF=3D"http://www.iana.org/assignments/version-numbers" =
TARGET=3D"_blank">http://www.iana.org/assignments/version-numbers</A>).<=
/FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; pwe3 mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; pwe3@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/pwe3" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/pwe3</A></FONT>=

<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2F3D0.97C27188--


From owner-mpls@UU.NET  Wed Mar 26 15:28:26 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12864
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 15:28:25 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohss29936
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 20:30:45 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohss29592;
	Wed, 26 Mar 2003 20:30:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohsq21378
	for mpls-outgoing; Wed, 26 Mar 2003 20:01:40 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohsq21353
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 20:01:38 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohsq08157
	for <mpls@uu.net>; Wed, 26 Mar 2003 20:01:14 GMT
From: neil.2.harrison@bt.com
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsq15278
	for <mpls@uu.net>; Wed, 26 Mar 2003 20:01:12 GMT
Received: from cbibipnt05.hc.bt.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: saturn.bt.com [193.113.57.20])
	id QQohsq15259
	for <mpls@uu.net>; Wed, 26 Mar 2003 20:01:12 GMT
Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89)
	id <H4PPR5KJ>; Wed, 26 Mar 2003 20:01:17 -0000
Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D6676@i2km07-ukbr.domain1.systemhost.net>
To: Shahram_Davari@pmc-sierra.com, dallan@nortelnetworks.com, yaakov_s@rad.com,
        townsley@cisco.com, Andy.Malis@vivacenetworks.com
Cc: pwe3@ietf.org, mpls@UU.NET
Subject: RE: [PWE3] MPLS PID
Date: Wed, 26 Mar 2003 20:01:05 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2F3D2.6EF4D164"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2F3D2.6EF4D164
Content-Type: text/plain;
	charset="iso-8859-1"

My vote is with this view too.  regards, Neil

-----Original Message-----
From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
Sent: 26 March 2003 19:11
To: 'David Allan'; 'Yaakov Stein'; W. Mark Townsley; Andrew G. Malis
Cc: pwe3@ietf.org; mpls@uu.net
Subject: RE: [PWE3] MPLS PID


I also agree with Dave/Andy/Ron/Alia. If PID is needed, do it properly by
defining a standard protocol Mux header such as LLC/SNAP. Those interested
in identifying the protocol in the interior routers would then require to
carry this header in all packets.
 
-Shahram

-----Original Message-----
From: David Allan [mailto:dallan@nortelnetworks.com]
Sent: Wednesday, March 26, 2003 1:38 PM
To: 'Yaakov Stein'; W. Mark Townsley; Andrew G. Malis
Cc: pwe3@ietf.org; mpls@uu.net
Subject: RE: [PWE3] MPLS PID



Yakov: 

We don't have 14 values, we are talking inferring payload on the basis of
defacto IETF protocol payloads (IPv4 and IPv6). PWE3 and MPLS do not own
IPv4/v6 or any subsequent network layer protocols the IETF may choose to
develop. 

I agree with Andy that if a PID is required, lets do it properly. 

Dave 

> -----Original Message----- 
> From: Yaakov Stein [ mailto:yaakov_s@rad.com <mailto:yaakov_s@rad.com> ] 
> Sent: Wednesday, March 26, 2003 11:08 AM 
> To: W. Mark Townsley; Andrew G. Malis 
> Cc: pwe3@ietf.org; mpls@uu.net 
> Subject: RE: [PWE3] MPLS PID 
> 
> 
> > One possibility for an extended PID that comes to mind is 
> > defining one of the remaining 14 values within the first 
> nibble as "extended PID" 
> > and follow it with whatever PID definition you like. 
> 
> Another, which I proposed in draft-stein-pwe3-controlword-00.txt, 
> is to use the 4 bits to disambiguate the relevant possibilities. 
> 
> Since an atm-encap implementation will probably not 
> understand ethernet-encap, the non 4/6 values could be used 
> for submodes (e.g. 1:1, N:1, PDU, SDU). Similarly, the TDM 
> sub-identifier could differentiate between raw,  AAL1, AAL2, etc. 
> 
> Alternatively, we could go for a "sanity check" 
> PWE identifier. We have 14 values available 
> and so far have only defined a few PW types 
> (ATM, FR, SONET, TDM, ethernet). 
> 
> Y(J)S 
> 
> _______________________________________________ 
> pwe3 mailing list 
> pwe3@ietf.org 
> https://www1.ietf.org/mailman/listinfo/pwe3
<https://www1.ietf.org/mailman/listinfo/pwe3>  
> 


------_=_NextPart_001_01C2F3D2.6EF4D164
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [PWE3] MPLS PID</TITLE>

<META content="MSHTML 5.00.3013.2600" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#800000 face="Comic Sans MS" size=2><SPAN 
class=710160020-26032003>My vote is with this view too.&nbsp; regards, 
Neil</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #800000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Shahram Davari 
  [mailto:Shahram_Davari@pmc-sierra.com]<BR><B>Sent:</B> 26 March 2003 
  19:11<BR><B>To:</B> 'David Allan'; 'Yaakov Stein'; W. Mark Townsley; Andrew G. 
  Malis<BR><B>Cc:</B> pwe3@ietf.org; mpls@uu.net<BR><B>Subject:</B> RE: [PWE3] 
  MPLS PID<BR><BR></DIV></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=041450519-26032003>I 
  also agree with Dave/Andy/Ron/Alia. If PID is needed, do it properly by 
  defining a standard protocol Mux header such as LLC/SNAP. Those interested in 
  identifying the protocol in the interior routers would then require to carry 
  this header in all packets.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=041450519-26032003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=041450519-26032003>-Shahram</SPAN></FONT></DIV>
  <BLOCKQUOTE 
  style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> David Allan 
    [mailto:dallan@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, March 26, 2003 
    1:38 PM<BR><B>To:</B> 'Yaakov Stein'; W. Mark Townsley; Andrew G. 
    Malis<BR><B>Cc:</B> pwe3@ietf.org; mpls@uu.net<BR><B>Subject:</B> RE: [PWE3] 
    MPLS PID<BR><BR></DIV></FONT>
    <P><FONT size=2>Yakov:</FONT> </P>
    <P><FONT size=2>We don't have 14 values, we are talking inferring payload on 
    the basis of defacto IETF protocol payloads (IPv4 and IPv6). PWE3 and MPLS 
    do not own IPv4/v6 or any subsequent network layer protocols the IETF may 
    choose to develop. </FONT></P>
    <P><FONT size=2>I agree with Andy that if a PID is required, lets do it 
    properly. </FONT></P>
    <P><FONT size=2>Dave</FONT> </P>
    <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
    From: Yaakov Stein [<A 
    href="mailto:yaakov_s@rad.com">mailto:yaakov_s@rad.com</A>] </FONT><BR><FONT 
    size=2>&gt; Sent: Wednesday, March 26, 2003 11:08 AM</FONT> <BR><FONT 
    size=2>&gt; To: W. Mark Townsley; Andrew G. Malis</FONT> <BR><FONT 
    size=2>&gt; Cc: pwe3@ietf.org; mpls@uu.net</FONT> <BR><FONT size=2>&gt; 
    Subject: RE: [PWE3] MPLS PID</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; One possibility for an 
    extended PID that comes to mind is</FONT> <BR><FONT size=2>&gt; &gt; 
    defining one of the remaining 14 values within the first </FONT><BR><FONT 
    size=2>&gt; nibble as "extended PID" </FONT><BR><FONT size=2>&gt; &gt; and 
    follow it with whatever PID definition you like.</FONT> <BR><FONT 
    size=2>&gt; </FONT><BR><FONT size=2>&gt; Another, which I proposed in 
    draft-stein-pwe3-controlword-00.txt, </FONT><BR><FONT size=2>&gt; is to use 
    the 4 bits to disambiguate the relevant possibilities.</FONT> <BR><FONT 
    size=2>&gt; </FONT><BR><FONT size=2>&gt; Since an atm-encap implementation 
    will probably not </FONT><BR><FONT size=2>&gt; understand ethernet-encap, 
    the non 4/6 values could be used </FONT><BR><FONT size=2>&gt; for submodes 
    (e.g. 1:1, N:1, PDU, SDU). Similarly, the TDM </FONT><BR><FONT size=2>&gt; 
    sub-identifier could differentiate between raw,&nbsp; AAL1, AAL2, 
    etc.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    Alternatively, we could go for a "sanity check"</FONT> <BR><FONT size=2>&gt; 
    PWE identifier. We have 14 values available</FONT> <BR><FONT size=2>&gt; and 
    so far have only defined a few PW types</FONT> <BR><FONT size=2>&gt; (ATM, 
    FR, SONET, TDM, ethernet).</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; Y(J)S</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    _______________________________________________</FONT> <BR><FONT size=2>&gt; 
    pwe3 mailing list</FONT> <BR><FONT size=2>&gt; pwe3@ietf.org</FONT> 
    <BR><FONT size=2>&gt; <A href="https://www1.ietf.org/mailman/listinfo/pwe3" 
    target=_blank>https://www1.ietf.org/mailman/listinfo/pwe3</A></FONT> 
    <BR><FONT size=2>&gt; </FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C2F3D2.6EF4D164--


From owner-mpls@UU.NET  Wed Mar 26 15:38:04 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13189
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 15:38:04 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohss26707
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 20:40:23 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohss26354;
	Wed, 26 Mar 2003 20:40:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohsq04711
	for mpls-outgoing; Wed, 26 Mar 2003 20:12:39 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohsq04699
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 20:12:25 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohsq28999
	for <mpls@uu.net>; Wed, 26 Mar 2003 20:11:06 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsq19350
	for <mpls@uu.net>; Wed, 26 Mar 2003 20:11:05 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohsq19338
	for <mpls@uu.net>; Wed, 26 Mar 2003 20:11:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2QKB2iH023124
	for <mpls@uu.net>; Wed, 26 Mar 2003 15:11:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA11455 for <mpls@uu.net>; Wed, 26 Mar 2003 15:11:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2QKB2712743 for mpls@uu.net; Wed, 26 Mar 2003 15:11:02 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohsq03751
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 20:09:37 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohsq26283
	for <mpls@UU.NET>; Wed, 26 Mar 2003 20:09:22 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsq25140
	for <mpls@UU.NET>; Wed, 26 Mar 2003 20:09:22 GMT
Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQohsq25096
	for <mpls@UU.NET>; Wed, 26 Mar 2003 20:09:20 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA30859;
	Wed, 26 Mar 2003 15:09:29 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303262009.PAA30859@workhorse.fictitious.org>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
cc: "'David Allan'" <dallan@nortelnetworks.com>,
        "'Yaakov Stein'" <yaakov_s@rad.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>, pwe3@ietf.org,
        mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: [PWE3] MPLS PID 
In-reply-to: Your message of "Wed, 26 Mar 2003 11:11:10 PST."
             <4B6D09F3B826D411A67300D0B706EFDE0115C830@nt-exch-yow.pmc-sierra.bc.ca> 
Date: Wed, 26 Mar 2003 15:09:28 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <4B6D09F3B826D411A67300D0B706EFDE0115C830@nt-exch-yow.pmc-sierra.bc.
ca>, Shahram Davari writes:
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
> 
> ------_=_NextPart_001_01C2F3CB.763A5440
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> 
> I also agree with Dave/Andy/Ron/Alia. If PID is needed, do it properly by def
> ining a standard protocol Mux header such as LLC/SNAP. Those interested in id
> entifying the protocol in the interior routers would then require to carry th
> is header in all packets.
>  
> -Shahram


LLC/SNAP is overkill.  Something along the lines of the 4 byte L3PID
would probably be better.  It might be worth adding a value in L3PID
or the GMPLS GPID to indicate that the LSP payload has the PID in the
top 4 bytes and use the same set of values rather than inventing new
number spaces for new PIDs (whether PID is payload ID or packet ID).

Curtis



From owner-mpls@UU.NET  Wed Mar 26 16:19:11 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15237
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 16:19:10 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsv24462
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 21:21:29 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohsv23880;
	Wed, 26 Mar 2003 21:21:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohss06890
	for mpls-outgoing; Wed, 26 Mar 2003 20:37:07 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohss06879
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 20:37:00 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohss06287
	for <mpls@uu.net>; Wed, 26 Mar 2003 20:36:08 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohss21330
	for <mpls@uu.net>; Wed, 26 Mar 2003 20:36:08 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohss21299
	for <mpls@uu.net>; Wed, 26 Mar 2003 20:36:07 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2QKa4iH028495
	for <mpls@uu.net>; Wed, 26 Mar 2003 15:36:04 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA13747 for <mpls@uu.net>; Wed, 26 Mar 2003 15:36:04 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2QKa3716552 for mpls@uu.net; Wed, 26 Mar 2003 15:36:03 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohss06616
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 20:35:26 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohss05374
	for <mpls@UU.NET>; Wed, 26 Mar 2003 20:34:38 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohss19499
	for <mpls@UU.NET>; Wed, 26 Mar 2003 20:34:37 GMT
Received: from father.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: father.pmc-sierra.com [216.241.224.13])
	id QQohss19476
	for <mpls@UU.NET>; Wed, 26 Mar 2003 20:34:37 GMT
Received: (qmail 19634 invoked by uid 104); 26 Mar 2003 20:34:32 -0000
Received: from Shahram_Davari@pmc-sierra.com by father by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4253.  Clear:. 
 Processed in 0.471196 secs); 26 Mar 2003 20:34:32 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by father.pmc-sierra.com with SMTP; 26 Mar 2003 20:34:31 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h2QKYUh00576;
	Wed, 26 Mar 2003 12:34:31 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <DCP4T5JN>; Wed, 26 Mar 2003 12:34:30 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115C831@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Thomas D. Nadeau'" <tnadeau@lucidvision.com>,
        "'George Swallow'"
	 <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>
Cc: "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'"
	 <mpls@UU.NET>, tnadeau@cisco.com
Subject: RE: [PWE3] MPLS PID 
Date: Wed, 26 Mar 2003 12:34:28 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

>>
>>1) ECMP could use only label hashing and not hash IP header.
>
>         This is unrealistic. Lots of vendors hash on both,
>one or the other.  Lets not go down the road of trying
>to mandate how ECMP works again. We went down that
>road in MPLS and the response was clear.

Hashing on IP header is not part of any IETF standard, and I am not sure all future IETF
standards should be based on supporting non-standard proprietary implementations. if one likes
to still hash IP header, then he could define a proper protocol mux header and use it all the time.


>
>>2) OAM flows could use IPv4/V6 null or MPLS Alert label
>
>         Encased in the PW or just as a label stack?

Tunnel Label - PW label - IPV4/6 explicit null. And hash only up to 2nd label.

>
>>3) Netmanagment could identify the flow at the ingress.
>
>         What about the egress?

Also egress could identify the flow from bottom label.

-Shahram

>
>         --Tom
>
>
>>-Shahram
>
>



From owner-mpls@UU.NET  Wed Mar 26 16:30:42 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15860
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 16:30:42 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsw04099
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 21:33:01 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohsw03234;
	Wed, 26 Mar 2003 21:32:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohst07990
	for mpls-outgoing; Wed, 26 Mar 2003 20:46:11 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohst07975
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 20:46:08 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohst23062
	for <mpls@uu.net>; Wed, 26 Mar 2003 20:45:16 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohst02605
	for <mpls@uu.net>; Wed, 26 Mar 2003 20:45:15 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQohst02585
	for <mpls@uu.net>; Wed, 26 Mar 2003 20:45:15 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2QKjCMR014451
	for <mpls@uu.net>; Wed, 26 Mar 2003 15:45:12 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA14559 for <mpls@uu.net>; Wed, 26 Mar 2003 15:45:12 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2QKjCZ18102 for mpls@uu.net; Wed, 26 Mar 2003 15:45:12 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohss07439
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 20:44:35 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohss26223
	for <mpls@UU.NET>; Wed, 26 Mar 2003 20:43:13 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohss00101
	for <mpls@UU.NET>; Wed, 26 Mar 2003 20:43:13 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohss00092
	for <mpls@UU.NET>; Wed, 26 Mar 2003 20:43:13 GMT
Received: from bucket.cisco.com (IDENT:mirapoint@bucket.cisco.com [161.44.167.72])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2QKgwiH029786;
	Wed, 26 Mar 2003 15:42:58 -0500 (EST)
Received: from tnadeau-w2k.cisco.com (rtp-vpn2-871.cisco.com [10.82.243.103])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ACV21798;
	Wed, 26 Mar 2003 15:42:56 -0500 (EST)
Message-Id: <5.2.0.9.2.20030326103204.02e9dc70@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 26 Mar 2003 10:34:22 -0500
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>,
        "'George Swallow'" <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: [PWE3] MPLS PID 
Cc: "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'" <mpls@UU.NET>
In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C829@nt-exch-yow.pmc-s
 ierra.bc.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 02:18 PM 3/25/2003 -0800, Shahram Davari wrote:

> >1.  Dealing with ECMP behavior
> >2.  Inband OAM flows
> >3.  Identifying flows for netmanagement applications.
> >
>
>I don't think any of them justifies adding PID.
>
>1) ECMP could use only label hashing and not hash IP header.

         This is unrealistic. Lots of vendors hash on both,
one or the other.  Lets not go down the road of trying
to mandate how ECMP works again. We went down that
road in MPLS and the response was clear.

>2) OAM flows could use IPv4/V6 null or MPLS Alert label

         Encased in the PW or just as a label stack?

>3) Netmanagment could identify the flow at the ingress.

         What about the egress?

         --Tom


>-Shahram


http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X



From owner-mpls@UU.NET  Wed Mar 26 16:30:46 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15875
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 16:30:46 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsw04265
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 21:33:06 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohsw03603;
	Wed, 26 Mar 2003 21:32:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohst08005
	for mpls-outgoing; Wed, 26 Mar 2003 20:46:14 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohst07978
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 20:46:10 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohss21689
	for <mpls@uu.net>; Wed, 26 Mar 2003 20:44:41 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohss01870
	for <mpls@uu.net>; Wed, 26 Mar 2003 20:44:41 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohss01862
	for <mpls@uu.net>; Wed, 26 Mar 2003 20:44:40 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2QKiciH000241
	for <mpls@uu.net>; Wed, 26 Mar 2003 15:44:38 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA14493 for <mpls@uu.net>; Wed, 26 Mar 2003 15:44:37 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2QKibE17828 for mpls@uu.net; Wed, 26 Mar 2003 15:44:37 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohss07328
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 20:43:06 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohss16903
	for <mpls@uu.net>; Wed, 26 Mar 2003 20:43:04 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohss29858
	for <mpls@uu.net>; Wed, 26 Mar 2003 20:43:03 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohss29840
	for <mpls@uu.net>; Wed, 26 Mar 2003 20:43:03 GMT
Received: from bucket.cisco.com (IDENT:mirapoint@bucket.cisco.com [161.44.167.72])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2QKh0iH029809;
	Wed, 26 Mar 2003 15:43:00 -0500 (EST)
Received: from tnadeau-w2k.cisco.com (rtp-vpn2-871.cisco.com [10.82.243.103])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ACV21800;
	Wed, 26 Mar 2003 15:42:59 -0500 (EST)
Message-Id: <5.2.0.9.2.20030326104423.0624bb88@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 26 Mar 2003 10:46:05 -0500
To: "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>, pwe3@ietf.org
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: [PWE3] MPLS PID 
Cc: mpls@UU.NET
In-Reply-To: <5.2.0.9.0.20030325184106.059779b8@po1.vivacenetworks.com>
References: <4B6D09F3B826D411A67300D0B706EFDE0115C829@nt-exch-yow.pmc-s ierra.bc.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 06:52 PM 3/25/2003 -0500, Andrew G. Malis wrote:
>Shahram and Alia both make excellent points:
>
>At 3/25/2003 02:18 PM -0800, Shahram Davari wrote:
>> >1.  Dealing with ECMP behavior
>> >2.  Inband OAM flows
>> >3.  Identifying flows for netmanagement applications.
>>
>>I don't think any of them justifies adding PID.
>>
>>1) ECMP could use only label hashing and not hash IP header.
>>2) OAM flows could use IPv4/V6 null or MPLS Alert label
>>3) Netmanagment could identify the flow at the ingress.
>
>At 3/25/2003 06:15 PM -0500, Alia Atlas wrote:
>>How does requiring a PID in the PWE3 L2 control word solve or handle the 
>>case where a control word is not mandatory?
>>
>>There are pseudo-wires, such as ethernet, where a control word is not 
>>mandatory.  This would imply that the first nibble (which would be 
>>identified as the suggested PID) would be that from the ethernet frame.
>
>We're going to have to change the PWE3 drafts to require the control word, 
>and change both the SONET/SDH and some of the ATM encapsulations, to 
>support a hack.

         Andy,

         Some people believe that the non-use of the control
word is a hack/micro-optimization that should be removed.

>If you REALLY want multi-protocol identification, then have the MPLS WG 
>put a REAL multiprotocol identifier, a la RFC 2427 or 2684, between the 
>labels and the payload.  See, for example, 
>draft-moreels-multiproto-mpls-00.txt for a much more general (and useful) 
>method than just a four-bit hack.  And sorry for the cross-post, but this 
>really does affect both WGs.

         Do you think that it is realistic to go back and change
the MPLS header format at this point in the game?

         --Tom



>Cheers,
>Andy
>
>_______________________________________________
>pwe3 mailing list
>pwe3@ietf.org
>https://www1.ietf.org/mailman/listinfo/pwe3


http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X



From owner-mpls@UU.NET  Wed Mar 26 16:32:47 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15973
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 16:32:47 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsw13735
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 21:35:07 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohsw13116;
	Wed, 26 Mar 2003 21:34:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohst08411
	for mpls-outgoing; Wed, 26 Mar 2003 20:50:39 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohst08376
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 20:50:20 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohst27681
	for <mpls@uu.net>; Wed, 26 Mar 2003 20:50:14 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohst10204
	for <mpls@uu.net>; Wed, 26 Mar 2003 20:50:13 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohst10191
	for <mpls@uu.net>; Wed, 26 Mar 2003 20:50:13 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2QKoAiH001512
	for <mpls@uu.net>; Wed, 26 Mar 2003 15:50:11 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA14993 for <mpls@uu.net>; Wed, 26 Mar 2003 15:50:10 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2QKoAB19143 for mpls@uu.net; Wed, 26 Mar 2003 15:50:10 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohst08147
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 20:48:53 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohst09410
	for <mpls@UU.NET>; Wed, 26 Mar 2003 20:48:35 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohst07785
	for <mpls@UU.NET>; Wed, 26 Mar 2003 20:48:35 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQohst07776
	for <mpls@UU.NET>; Wed, 26 Mar 2003 20:48:34 GMT
Received: from bucket.cisco.com (IDENT:mirapoint@bucket.cisco.com [161.44.167.72])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2QKmTMR014771;
	Wed, 26 Mar 2003 15:48:30 -0500 (EST)
Received: from TNADEAU-W2K6.cisco.com (sjc-vpn4-139.cisco.com [10.21.80.139])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ACV21944;
	Wed, 26 Mar 2003 15:48:27 -0500 (EST)
Message-Id: <4.3.2.7.2.20030326153523.00c67cd0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 26 Mar 2003 15:48:21 -0500
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: RE: [PWE3] MPLS PID 
Cc: "'George Swallow'" <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'" <mpls@UU.NET>
In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C831@nt-exch-yow.pmc-s
 ierra.bc.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 12:34 PM 3/26/2003 -0800, Shahram Davari wrote:
> >>
> >>1) ECMP could use only label hashing and not hash IP header.
> >
> >         This is unrealistic. Lots of vendors hash on both,
> >one or the other.  Lets not go down the road of trying
> >to mandate how ECMP works again. We went down that
> >road in MPLS and the response was clear.
>
>Hashing on IP header is not part of any IETF standard, and I am not sure 
>all future IETF
>standards should be based on supporting non-standard proprietary 
>implementations. if one likes to still hash IP header, then he could 
>define a proper protocol mux header and use it all the time.

         As far as I can tell, the hashing algorithmS employed by
most routers are not an IETF standard. In this case, it is clear that
t is not about supporting a single, proprietary implementation; it is
about supporting ALL implementations. But if you insist on trying to
convince the community as you and others unsuccessfully tried to
in Atlanta to use a standard ECMP algorithm, have fun.

> >>2) OAM flows could use IPv4/V6 null or MPLS Alert label
> >
> >         Encased in the PW or just as a label stack?
>
>Tunnel Label - PW label - IPV4/6 explicit null. And hash only up to 2nd label.

         What about using the PWE header?
What if I am using TE/FRR and there are 3 labels and I
want to hash on all of them?  It sounds to me like you
again are trying to mandate how I do my hashing algorithm.

> >>3) Netmanagment could identify the flow at the ingress.
> >
> >         What about the egress?
>
>Also egress could identify the flow from bottom label.

         Only if it knew that the bottom label was used
for an OAM flow or some other application.

         --Tom



>-Shahram
>
> >
> >         --Tom
> >
> >
> >>-Shahram
> >
> >




From owner-mpls@UU.NET  Wed Mar 26 17:37:48 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18785
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 17:37:48 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohta19524
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 22:40:09 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohta19013;
	Wed, 26 Mar 2003 22:39:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohsw01490
	for mpls-outgoing; Wed, 26 Mar 2003 21:33:35 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohsw01478
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 21:33:24 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohsw24153
	for <mpls@UU.NET>; Wed, 26 Mar 2003 21:31:25 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsw08603
	for <mpls@UU.NET>; Wed, 26 Mar 2003 21:31:25 GMT
Received: from mail.libertysurf.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.libertysurf.net [213.36.80.91])
	id QQohsw08576
	for <mpls@UU.NET>; Wed, 26 Mar 2003 21:31:24 GMT
Received: from enst.fr (212.83.172.148) by mail.libertysurf.net (6.5.026)
        id 3E101A5700DC009E for mpls@UU.NET; Wed, 26 Mar 2003 22:31:24 +0100
Message-ID: <3E821C55.3010804@enst.fr>
Date: Wed, 26 Mar 2003 22:32:05 +0100
From: Mohamed KOUBAA <koubaa@enst.fr>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Disubscribe
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Disubscribe




From owner-mpls@UU.NET  Wed Mar 26 18:13:35 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21552
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 18:13:35 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohtd03126
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 23:15:56 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohtd02673;
	Wed, 26 Mar 2003 23:15:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohsw02207
	for mpls-outgoing; Wed, 26 Mar 2003 21:42:14 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohsw02194
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 21:42:02 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohsw01237
	for <mpls@uu.net>; Wed, 26 Mar 2003 21:39:13 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsw20009
	for <mpls@uu.net>; Wed, 26 Mar 2003 21:39:12 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohsw20004
	for <mpls@uu.net>; Wed, 26 Mar 2003 21:39:12 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2QLd9iH011711
	for <mpls@uu.net>; Wed, 26 Mar 2003 16:39:09 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA19545 for <mpls@uu.net>; Wed, 26 Mar 2003 16:39:08 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2QLd8F00634 for mpls@uu.net; Wed, 26 Mar 2003 16:39:08 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohsw01883
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 21:37:45 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohsw24469
	for <mpls@uu.net>; Wed, 26 Mar 2003 21:36:24 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsw09255
	for <mpls@uu.net>; Wed, 26 Mar 2003 21:36:23 GMT
Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: father.pmc-sierra.com [216.241.224.13])
	id QQohsw09239
	for <mpls@uu.net>; Wed, 26 Mar 2003 21:36:22 GMT
Received: (qmail 14480 invoked by uid 104); 26 Mar 2003 21:36:22 -0000
Received: from Shahram_Davari@pmc-sierra.com by father by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4253.  Clear:. 
 Processed in 0.457517 secs); 26 Mar 2003 21:36:22 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by father.pmc-sierra.com with SMTP; 26 Mar 2003 21:36:21 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h2QLaLh28178;
	Wed, 26 Mar 2003 13:36:21 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <DCP4T64Y>; Wed, 26 Mar 2003 13:36:20 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115C834@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Thomas D. Nadeau'" <tnadeau@cisco.com>,
        "Andrew G. Malis"
	 <Andy.Malis@vivacenetworks.com>, pwe3@ietf.org
Cc: mpls@UU.NET
Subject: RE: [PWE3] MPLS PID 
Date: Wed, 26 Mar 2003 13:36:19 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk


>
>         Some people believe that the non-use of the control
>word is a hack/micro-optimization that should be removed.

Interesting ! ECMP hash is not a hack but signaling non-use of control word is?

-Shahram



From owner-mpls@UU.NET  Wed Mar 26 18:15:12 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21736
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 18:15:12 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohtd03355
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 23:17:33 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohtd02910;
	Wed, 26 Mar 2003 23:17:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohsw02210
	for mpls-outgoing; Wed, 26 Mar 2003 21:42:16 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohsw02198
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 21:42:03 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohsw01296
	for <mpls@uu.net>; Wed, 26 Mar 2003 21:39:14 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsw20031
	for <mpls@uu.net>; Wed, 26 Mar 2003 21:39:13 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohsw20025
	for <mpls@uu.net>; Wed, 26 Mar 2003 21:39:13 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2QLdAiH011718
	for <mpls@uu.net>; Wed, 26 Mar 2003 16:39:10 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA19550 for <mpls@uu.net>; Wed, 26 Mar 2003 16:39:10 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2QLdAp00661 for mpls@uu.net; Wed, 26 Mar 2003 16:39:10 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohsw01885
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 21:37:47 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohsw29006
	for <mpls@UU.NET>; Wed, 26 Mar 2003 21:33:26 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsw04970
	for <mpls@UU.NET>; Wed, 26 Mar 2003 21:33:25 GMT
Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: father.pmc-sierra.com [216.241.224.13])
	id QQohsw04941
	for <mpls@UU.NET>; Wed, 26 Mar 2003 21:33:25 GMT
Received: (qmail 13274 invoked by uid 104); 26 Mar 2003 21:33:20 -0000
Received: from Shahram_Davari@pmc-sierra.com by father by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4253.  Clear:. 
 Processed in 0.455992 secs); 26 Mar 2003 21:33:20 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by father.pmc-sierra.com with SMTP; 26 Mar 2003 21:33:19 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h2QLXJh26851;
	Wed, 26 Mar 2003 13:33:19 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <DCP4T6SJ>; Wed, 26 Mar 2003 13:33:19 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115C833@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Thomas Nadeau'" <tnadeau@cisco.com>
Cc: "'George Swallow'" <swallow@cisco.com>,
        "W. Mark Townsley"
	 <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: [PWE3] MPLS PID 
Date: Wed, 26 Mar 2003 13:33:17 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

>         As far as I can tell, the hashing algorithmS employed by
>most routers are not an IETF standard. In this case, it is clear that
>t is not about supporting a single, proprietary implementation; it is
>about supporting ALL implementations. But if you insist on trying to
>convince the community as you and others unsuccessfully tried to
>in Atlanta to use a standard ECMP algorithm, have fun.

Tweaking IETF standards to try to support all possible proprietary hashing
algorithms is not what I call standards development. What if a vendor decides
to distinguish IP protocol using IP header CRC. Will we now mandate that all encapsulated
protocols should not yield a valid CRC at that specific position in the header? 


>> >>2) OAM flows could use IPv4/V6 null or MPLS Alert label
>> >
>> >         Encased in the PW or just as a label stack?
>>
>>Tunnel Label - PW label - IPV4/6 explicit null. And hash only 
>up to 2nd label.
>
>         What about using the PWE header?
>What if I am using TE/FRR and there are 3 labels and I
>want to hash on all of them?  It sounds to me like you
>again are trying to mandate how I do my hashing algorithm.

No, what I am saying is that the proprietary assumption of using the first nibble to identify IP for hashing key selection should not be the basis for IETF standards.


>
>> >>3) Netmanagment could identify the flow at the ingress.
>> >
>> >         What about the egress?
>>
>>Also egress could identify the flow from bottom label.
>
>         Only if it knew that the bottom label was used
>for an OAM flow or some other application.

Egress always knows what protocol is encapsulated after the bottom label.

-Shahram



From owner-mpls@UU.NET  Wed Mar 26 18:18:27 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21936
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 18:18:26 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohtd09998
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 23:20:47 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohtd09738;
	Wed, 26 Mar 2003 23:20:39 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohsx02641
	for mpls-outgoing; Wed, 26 Mar 2003 21:45:20 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQohsx02626
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 21:45:15 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohsw11012
	for <mpls@UU.NET>; Wed, 26 Mar 2003 21:44:23 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsw27823
	for <mpls@UU.NET>; Wed, 26 Mar 2003 21:44:23 GMT
Received: from zcars04f.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57])
	id QQohsw27801
	for <mpls@UU.NET>; Wed, 26 Mar 2003 21:44:22 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2QLhsQ12377;
	Wed, 26 Mar 2003 16:43:54 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <GDF48M2L>; Wed, 26 Mar 2003 16:43:54 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D016D2BF3@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'Thomas Nadeau'" <tnadeau@cisco.com>,
        Shahram Davari
	 <Shahram_Davari@pmc-sierra.com>
Cc: "'George Swallow'" <swallow@cisco.com>,
        "W. Mark Townsley"
	 <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: [PWE3] MPLS PID 
Date: Wed, 26 Mar 2003 16:43:51 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2F3E0.CABBEC94"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2F3E0.CABBEC94
Content-Type: text/plain;
	charset="iso-8859-1"

Tom
> 
>          As far as I can tell, the hashing algorithmS 
> employed by most routers are not an IETF standard. In this 
> case, it is clear that t is not about supporting a single, 
> proprietary implementation; it is about supporting ALL 
> implementations. But if you insist on trying to convince the 
> community as you and others unsuccessfully tried to in 
> Atlanta to use a standard ECMP algorithm, have fun.

Poor characterization of the Guildlines draft. Didn't propose a standard
algorithm, just suggested specific knobs were required for those operators
who cared to preserve path semantics for test purposes. BTW it is posted as
'03 now.

Dave


------_=_NextPart_001_01C2F3E0.CABBEC94
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [PWE3] MPLS PID </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Tom</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; As =
far as I can tell, the hashing algorithmS </FONT>
<BR><FONT SIZE=3D2>&gt; employed by most routers are not an IETF =
standard. In this </FONT>
<BR><FONT SIZE=3D2>&gt; case, it is clear that t is not about =
supporting a single, </FONT>
<BR><FONT SIZE=3D2>&gt; proprietary implementation; it is about =
supporting ALL </FONT>
<BR><FONT SIZE=3D2>&gt; implementations. But if you insist on trying to =
convince the </FONT>
<BR><FONT SIZE=3D2>&gt; community as you and others unsuccessfully =
tried to in </FONT>
<BR><FONT SIZE=3D2>&gt; Atlanta to use a standard ECMP algorithm, have =
fun.</FONT>
</P>

<P><FONT SIZE=3D2>Poor characterization of the Guildlines draft. Didn't =
propose a standard algorithm, just suggested specific knobs were =
required for those operators who cared to preserve path semantics for =
test purposes. BTW it is posted as '03 now.</FONT></P>

<P><FONT SIZE=3D2>Dave</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2F3E0.CABBEC94--


From owner-mpls@UU.NET  Wed Mar 26 18:19:34 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21979
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 18:19:34 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohtd07917
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 23:21:54 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohtd07459;
	Wed, 26 Mar 2003 23:21:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohsx02667
	for mpls-outgoing; Wed, 26 Mar 2003 21:45:39 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohsx02649
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 21:45:33 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohsx28830
	for <mpls@uu.net>; Wed, 26 Mar 2003 21:45:16 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsx29227
	for <mpls@uu.net>; Wed, 26 Mar 2003 21:45:16 GMT
Received: from ns2.vivacenetworks.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [64.221.212.135])
	id QQohsx29206
	for <mpls@uu.net>; Wed, 26 Mar 2003 21:45:15 GMT
Received: from amalisxp.vivacenetworks.com ([10.120.0.2]) by vivacenetworks.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 26 Mar 2003 13:45:13 -0800
Message-Id: <5.2.0.9.0.20030326164110.01c15940@po1.vivacenetworks.com>
X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 26 Mar 2003 16:45:07 -0500
To: "Thomas D. Nadeau" <tnadeau@cisco.com>
From: "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>
Subject: RE: [PWE3] MPLS PID 
Cc: "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>, pwe3@ietf.org,
        mpls@UU.NET
In-Reply-To: <5.2.0.9.2.20030326104423.0624bb88@bucket.cisco.com>
References: <5.2.0.9.0.20030325184106.059779b8@po1.vivacenetworks.com>
 <4B6D09F3B826D411A67300D0B706EFDE0115C829@nt-exch-yow.pmc-s ierra.bc.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 26 Mar 2003 21:45:14.0220 (UTC) FILETIME=[FBC7E2C0:01C2F3E0]
Sender: owner-mpls@UU.NET
Precedence: bulk

Tom,

Thanks for your messages.  There's a key question I would like to ask in reply:

>>>There are pseudo-wires, such as ethernet, where a control word is not 
>>>mandatory.  This would imply that the first nibble (which would be 
>>>identified as the suggested PID) would be that from the ethernet frame.
>>
>>We're going to have to change the PWE3 drafts to require the control 
>>word, and change both the SONET/SDH and some of the ATM encapsulations, 
>>to support a hack.
>
>         Andy,
>
>         Some people believe that the non-use of the control
>word is a hack/micro-optimization that should be removed.

Does "some people" represent PWE3 WG consensus?  To include Stewart's PID 
in the PWE3 architecture draft, there must be PWE3 WG consensus on two points:

1. The PID in the architecture spec is the right thing to do.
2. The control word MUST be required in all PWE3 encapsulations.

Also, there must be MPLS WG consensus on:

1. There should be an MPLS protocol ID.
2. Stewart's PID is the PWE3 control word in the right way to do it.

Cheers,
Andy



From owner-mpls@UU.NET  Wed Mar 26 18:37:00 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22533
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 18:37:00 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohte07259
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 23:39:21 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohte06668;
	Wed, 26 Mar 2003 23:39:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohsy22599
	for mpls-outgoing; Wed, 26 Mar 2003 22:10:06 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohsy22514
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 22:10:00 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohsy27772
	for <mpls@uu.net>; Wed, 26 Mar 2003 22:08:09 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsy03290
	for <mpls@uu.net>; Wed, 26 Mar 2003 22:08:08 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQohsy03229
	for <mpls@uu.net>; Wed, 26 Mar 2003 22:08:07 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2QM84MR021754
	for <mpls@uu.net>; Wed, 26 Mar 2003 17:08:04 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA21896 for <mpls@uu.net>; Wed, 26 Mar 2003 17:08:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2QM83W04244 for mpls@uu.net; Wed, 26 Mar 2003 17:08:03 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohsy22195
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 22:06:32 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohsy05467
	for <mpls@uu.net>; Wed, 26 Mar 2003 22:05:05 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsy29339
	for <mpls@uu.net>; Wed, 26 Mar 2003 22:05:05 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohsy29334
	for <mpls@uu.net>; Wed, 26 Mar 2003 22:05:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2QM51iH017167;
	Wed, 26 Mar 2003 17:05:01 -0500 (EST)
Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA21659; Wed, 26 Mar 2003 17:05:00 -0500 (EST)
Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA08409; Wed, 26 Mar 2003 17:05:00 -0500 (EST)
Message-Id: <200303262205.RAA08409@bifocal.cisco.com>
X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
cc: mpls@UU.NET
Subject: Re: [PWE3] MPLS PID 
In-reply-to: Your message of "Wed, 26 Mar 2003 12:34:28 PST."
             <4B6D09F3B826D411A67300D0B706EFDE0115C831@nt-exch-yow.pmc-sierra.bc.ca> 
Date: Wed, 26 Mar 2003 17:05:00 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Shahram -

> >>1) ECMP could use only label hashing and not hash IP header.
> >
> >         This is unrealistic. Lots of vendors hash on both,
> >one or the other.  Lets not go down the road of trying
> >to mandate how ECMP works again. We went down that
> >road in MPLS and the response was clear.
> 
> Hashing on IP header is not part of any IETF standard, and I am not
> sure all future IETF standards should be based on supporting
> non-standard proprietary implementations. if one likes to still hash
> IP header, then he could define a proper protocol mux header and use
> it all the time.

There is a long history of standards bodies respecting equipment that
has already been fielded.  In this case we are talking about 100s of
thousands of units.   It was the IETF that chose to define the MPLS
encapsulation without a PID.  That's water under the bridge.  Now we
have to deal with it.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824



From owner-mpls@UU.NET  Wed Mar 26 18:37:55 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22559
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 18:37:55 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohte08887
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 23:40:16 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohte08536;
	Wed, 26 Mar 2003 23:40:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohsy23522
	for mpls-outgoing; Wed, 26 Mar 2003 22:11:53 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohsy23486
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 22:11:37 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohsy02520
	for <mpls@uu.net>; Wed, 26 Mar 2003 22:11:08 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsy06860
	for <mpls@uu.net>; Wed, 26 Mar 2003 22:11:08 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohsy06829
	for <mpls@uu.net>; Wed, 26 Mar 2003 22:11:07 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2QMB5iH018399
	for <mpls@uu.net>; Wed, 26 Mar 2003 17:11:05 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA22156 for <mpls@uu.net>; Wed, 26 Mar 2003 17:11:04 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2QMB4304612 for mpls@uu.net; Wed, 26 Mar 2003 17:11:04 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohsy22472
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 22:09:35 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohsy19943
	for <mpls@UU.NET>; Wed, 26 Mar 2003 22:06:03 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsy00192
	for <mpls@UU.NET>; Wed, 26 Mar 2003 22:06:02 GMT
Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQohsy00138
	for <mpls@UU.NET>; Wed, 26 Mar 2003 22:06:01 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id RAA32424;
	Wed, 26 Mar 2003 17:04:37 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303262204.RAA32424@workhorse.fictitious.org>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
cc: "'Thomas D. Nadeau'" <tnadeau@lucidvision.com>,
        "'George Swallow'" <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'" <mpls@UU.NET>, tnadeau@cisco.com
Reply-To: curtis@fictitious.org
Subject: Re: [PWE3] MPLS PID 
In-reply-to: Your message of "Wed, 26 Mar 2003 12:34:28 PST."
             <4B6D09F3B826D411A67300D0B706EFDE0115C831@nt-exch-yow.pmc-sierra.bc.ca> 
Date: Wed, 26 Mar 2003 17:04:37 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <4B6D09F3B826D411A67300D0B706EFDE0115C831@nt-exch-yow.pmc-sierra.bc.
ca>, Shahram Davari writes:
>  
> >>1) ECMP could use only label hashing and not hash IP header.
> >
> >         This is unrealistic. Lots of vendors hash on both,
> >one or the other.  Lets not go down the road of trying
> >to mandate how ECMP works again. We went down that
> >road in MPLS and the response was clear.
>  
> Hashing on IP header is not part of any IETF standard, and I am not
> sure all fu ture IETF standards should be based on supporting
> non-standard proprietary implementation s. if one likes to still hash
> IP header, then he could define a proper protocol mux header and use
> it all the time.


You keep repeating this "non-standard proprietary" diatribe despite
being corrected.

src/dst based hash has been used for almost 15 years now.  In 1988 you
might have been more justified in calling it "non-standard
proprietary" but not in 2003.

It is documented in RFC 2991.

  2991 Multipath Issues in Unicast and Multicast Next-Hop Selection. D.
       Thaler, C. Hopps. November 2000. (Format: TXT=17796 bytes) (Status:
       INFORMATIONAL)

This makes it far from proprietary and the fact that the document as
informational does not make it non-standard.  It is not mandated by
any specific protocol but it is widely implemented and deployed.

src/dst hash based load split is widely deployed in numerous protocol
and considered important by many ISPs.

So please stop making the "non-standard proprietary" accusation unless
you want to be known as someone who persistantly ignores the facts.

Curtis



From owner-mpls@UU.NET  Wed Mar 26 18:42:50 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22747
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 18:42:50 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohtf14988
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 23:45:11 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohte14248;
	Wed, 26 Mar 2003 23:44:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohsz24508
	for mpls-outgoing; Wed, 26 Mar 2003 22:22:15 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQohsz24420
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 22:22:05 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohsz27837
	for <mpls@uu.net>; Wed, 26 Mar 2003 22:20:16 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsz19806
	for <mpls@uu.net>; Wed, 26 Mar 2003 22:20:16 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohsz19789
	for <mpls@uu.net>; Wed, 26 Mar 2003 22:20:16 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2QMK5iH020180
	for <mpls@uu.net>; Wed, 26 Mar 2003 17:20:13 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA22888 for <mpls@uu.net>; Wed, 26 Mar 2003 17:20:05 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2QMK5c06597 for mpls@uu.net; Wed, 26 Mar 2003 17:20:05 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohsz24284
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 22:19:21 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohsz15255
	for <mpls@UU.NET>; Wed, 26 Mar 2003 22:19:13 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsz20518
	for <mpls@UU.NET>; Wed, 26 Mar 2003 22:19:13 GMT
Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [216.241.224.12])
	id QQohsz20504
	for <mpls@UU.NET>; Wed, 26 Mar 2003 22:19:12 GMT
Received: (qmail 6853 invoked by uid 104); 26 Mar 2003 22:19:06 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4253.  Clear:. 
 Processed in 0.481789 secs); 26 Mar 2003 22:19:06 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by mother.pmc-sierra.com with SMTP; 26 Mar 2003 22:19:05 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h2QMJ4h17974;
	Wed, 26 Mar 2003 14:19:04 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <DCP4T7WR>; Wed, 26 Mar 2003 14:19:04 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115C836@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>
Cc: "'Thomas D. Nadeau'" <tnadeau@lucidvision.com>,
        "'George Swallow'"
	 <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'"
	 <mpls@UU.NET>, tnadeau@cisco.com
Subject: RE: [PWE3] MPLS PID 
Date: Wed, 26 Mar 2003 14:19:03 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

I think you misunderstood me. I said using the first nibble after bottom-most MPLS label to
identify IP header, so that it could be used as part of the hash key, is something new and proprietary (after MPLS was invented) and is not even documented in any informational or standard RFC including RFC2991. After all you could use the MPLS labels only for hash key.

Do you think that all hashing key selection algorithms by all vendors should be supported
by all IETF standards? What if one decides to use CRC to distinguish IP packets? should IETF
standards be backward compatible with that too?

-Shahram

>-----Original Message-----
>From: Curtis Villamizar [mailto:curtis@fictitious.org]
>Sent: Wednesday, March 26, 2003 5:05 PM
>To: Shahram Davari
>Cc: 'Thomas D. Nadeau'; 'George Swallow'; W. Mark Townsley; Andrew G.
>Malis; 'mpls@uu.net'; tnadeau@cisco.com
>Subject: Re: [PWE3] MPLS PID 
>
>
>
>In message 
><4B6D09F3B826D411A67300D0B706EFDE0115C831@nt-exch-yow.pmc-sierra.bc.
>ca>, Shahram Davari writes:
>>  
>> >>1) ECMP could use only label hashing and not hash IP header.
>> >
>> >         This is unrealistic. Lots of vendors hash on both,
>> >one or the other.  Lets not go down the road of trying
>> >to mandate how ECMP works again. We went down that
>> >road in MPLS and the response was clear.
>>  
>> Hashing on IP header is not part of any IETF standard, and I am not
>> sure all fu ture IETF standards should be based on supporting
>> non-standard proprietary implementation s. if one likes to still hash
>> IP header, then he could define a proper protocol mux header and use
>> it all the time.
>
>
>You keep repeating this "non-standard proprietary" diatribe despite
>being corrected.
>
>src/dst based hash has been used for almost 15 years now.  In 1988 you
>might have been more justified in calling it "non-standard
>proprietary" but not in 2003.
>
>It is documented in RFC 2991.
>
>  2991 Multipath Issues in Unicast and Multicast Next-Hop Selection. D.
>       Thaler, C. Hopps. November 2000. (Format: TXT=17796 
>bytes) (Status:
>       INFORMATIONAL)
>
>This makes it far from proprietary and the fact that the document as
>informational does not make it non-standard.  It is not mandated by
>any specific protocol but it is widely implemented and deployed.
>
>src/dst hash based load split is widely deployed in numerous protocol
>and considered important by many ISPs.
>
>So please stop making the "non-standard proprietary" accusation unless
>you want to be known as someone who persistantly ignores the facts.
>
>Curtis
>



From owner-mpls@UU.NET  Wed Mar 26 18:48:16 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23151
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 18:48:16 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohtf13433
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 23:50:37 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohtf12671;
	Wed, 26 Mar 2003 23:50:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohta25475
	for mpls-outgoing; Wed, 26 Mar 2003 22:34:37 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohta25454
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 22:34:33 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohta06590
	for <mpls@uu.net>; Wed, 26 Mar 2003 22:33:14 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohta10732
	for <mpls@uu.net>; Wed, 26 Mar 2003 22:33:13 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQohta10716
	for <mpls@uu.net>; Wed, 26 Mar 2003 22:33:13 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2QMXAMR023764
	for <mpls@uu.net>; Wed, 26 Mar 2003 17:33:11 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA23955 for <mpls@uu.net>; Wed, 26 Mar 2003 17:33:10 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2QMXAg08892 for mpls@uu.net; Wed, 26 Mar 2003 17:33:10 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohta25358
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 22:31:48 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohta02411
	for <mpls@UU.NET>; Wed, 26 Mar 2003 22:30:36 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohta02423
	for <mpls@UU.NET>; Wed, 26 Mar 2003 22:30:36 GMT
Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQohta02403
	for <mpls@UU.NET>; Wed, 26 Mar 2003 22:30:34 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id RAA32946;
	Wed, 26 Mar 2003 17:31:03 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303262231.RAA32946@workhorse.fictitious.org>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
cc: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "'Thomas D. Nadeau'" <tnadeau@lucidvision.com>,
        "'George Swallow'" <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'" <mpls@UU.NET>, tnadeau@cisco.com
Reply-To: curtis@fictitious.org
Subject: Re: [PWE3] MPLS PID 
In-reply-to: Your message of "Wed, 26 Mar 2003 14:19:03 PST."
             <4B6D09F3B826D411A67300D0B706EFDE0115C836@nt-exch-yow.pmc-sierra.bc.ca> 
Date: Wed, 26 Mar 2003 17:31:03 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <4B6D09F3B826D411A67300D0B706EFDE0115C836@nt-exch-yow.pmc-sierra.bc.
ca>, Shahram Davari writes:
> I think you misunderstood me. I said using the first nibble after bottom-most
>  MPLS label to
> identify IP header, so that it could be used as part of the hash key, is some
> thing new and proprietary (after MPLS was invented) and is not even documente
> d in any informational or standard RFC including RFC2991. After all you could
>  use the MPLS labels only for hash key.

A PID is not non-standard and proprietary if it is standardized and
that is what we are discussing.

> Do you think that all hashing key selection algorithms by all vendors should 
> be supported
> by all IETF standards? What if one decides to use CRC to distinguish IP packe
> ts? should IETF
> standards be backward compatible with that too?
> 
> -Shahram

RFC2991 is fine as is.  Load balancing algorithms exist.  There is no
need to standardize them.  Some are based on hashing.

Curtis


> >-----Original Message-----
> >From: Curtis Villamizar [mailto:curtis@fictitious.org]
> >Sent: Wednesday, March 26, 2003 5:05 PM
> >To: Shahram Davari
> >Cc: 'Thomas D. Nadeau'; 'George Swallow'; W. Mark Townsley; Andrew G.
> >Malis; 'mpls@uu.net'; tnadeau@cisco.com
> >Subject: Re: [PWE3] MPLS PID 
> >
> >
> >
> >In message 
> ><4B6D09F3B826D411A67300D0B706EFDE0115C831@nt-exch-yow.pmc-sierra.bc.
> >ca>, Shahram Davari writes:
> >>  
> >> >>1) ECMP could use only label hashing and not hash IP header.
> >> >
> >> >         This is unrealistic. Lots of vendors hash on both,
> >> >one or the other.  Lets not go down the road of trying
> >> >to mandate how ECMP works again. We went down that
> >> >road in MPLS and the response was clear.
> >>  
> >> Hashing on IP header is not part of any IETF standard, and I am not
> >> sure all fu ture IETF standards should be based on supporting
> >> non-standard proprietary implementation s. if one likes to still hash
> >> IP header, then he could define a proper protocol mux header and use
> >> it all the time.
> >
> >
> >You keep repeating this "non-standard proprietary" diatribe despite
> >being corrected.
> >
> >src/dst based hash has been used for almost 15 years now.  In 1988 you
> >might have been more justified in calling it "non-standard
> >proprietary" but not in 2003.
> >
> >It is documented in RFC 2991.
> >
> >  2991 Multipath Issues in Unicast and Multicast Next-Hop Selection. D.
> >       Thaler, C. Hopps. November 2000. (Format: TXT=17796 
> >bytes) (Status:
> >       INFORMATIONAL)
> >
> >This makes it far from proprietary and the fact that the document as
> >informational does not make it non-standard.  It is not mandated by
> >any specific protocol but it is widely implemented and deployed.
> >
> >src/dst hash based load split is widely deployed in numerous protocol
> >and considered important by many ISPs.
> >
> >So please stop making the "non-standard proprietary" accusation unless
> >you want to be known as someone who persistantly ignores the facts.
> >
> >Curtis
> >
> 



From owner-mpls@UU.NET  Wed Mar 26 18:51:32 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23285
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 18:51:32 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohtf09368
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 23:53:52 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohtf09012;
	Wed, 26 Mar 2003 23:53:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohtb26922
	for mpls-outgoing; Wed, 26 Mar 2003 22:46:27 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohtb26908
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 22:46:18 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohtb15673
	for <mpls@uu.net>; Wed, 26 Mar 2003 22:45:43 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohtb28804
	for <mpls@uu.net>; Wed, 26 Mar 2003 22:45:42 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQohtb28795
	for <mpls@uu.net>; Wed, 26 Mar 2003 22:45:41 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2QMjcMR024703
	for <mpls@uu.net>; Wed, 26 Mar 2003 17:45:39 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA24936 for <mpls@uu.net>; Wed, 26 Mar 2003 17:45:38 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2QMjcn11228 for mpls@uu.net; Wed, 26 Mar 2003 17:45:38 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQohta26207
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 22:43:23 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohta23949
	for <mpls@UU.NET>; Wed, 26 Mar 2003 22:42:54 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohta24399
	for <mpls@UU.NET>; Wed, 26 Mar 2003 22:42:54 GMT
Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: father.pmc-sierra.com [216.241.224.13])
	id QQohta24377
	for <mpls@UU.NET>; Wed, 26 Mar 2003 22:42:53 GMT
Received: (qmail 10619 invoked by uid 104); 26 Mar 2003 22:42:52 -0000
Received: from Shahram_Davari@pmc-sierra.com by father by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4253.  Clear:. 
 Processed in 0.461015 secs); 26 Mar 2003 22:42:52 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by father.pmc-sierra.com with SMTP; 26 Mar 2003 22:42:51 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h2QMgp628762;
	Wed, 26 Mar 2003 14:42:51 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <DCP4T8JV>; Wed, 26 Mar 2003 14:42:51 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115C837@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>
Cc: "'Thomas D. Nadeau'" <tnadeau@lucidvision.com>,
        "'George Swallow'"
	 <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'"
	 <mpls@UU.NET>, tnadeau@cisco.com
Subject: RE: [PWE3] MPLS PID 
Date: Wed, 26 Mar 2003 14:42:49 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

>A PID is not non-standard and proprietary if it is standardized and
>that is what we are discussing.

That is exactly what I said. You want to standardize a proprietary PID that
uses the first 4 bits. If it is approved by IETF then off course it won't be
proprietary any more.

>
>> Do you think that all hashing key selection algorithms by 
>all vendors should 
>> be supported
>> by all IETF standards? What if one decides to use CRC to 
>distinguish IP packe
>> ts? should IETF
>> standards be backward compatible with that too?
>> 
>> -Shahram
>
>RFC2991 is fine as is.  Load balancing algorithms exist.  There is no
>need to standardize them.  Some are based on hashing.
>

You didn't answer my question. I asked what if a vendor wants to use CRC as IP PID. 
Should IETF protocols support them too by requiring that all other protocols that
get transported over MPLS not to produce a valid CRC?

BTW I never said we need to standardize load balancing algorithms. Where did you get
that from?

-Shahram


-Shahram



From owner-mpls@UU.NET  Wed Mar 26 19:02:33 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23741
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 19:02:33 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohtg10472
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 00:04:54 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohtg10229;
	Thu, 27 Mar 2003 00:04:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohtd19671
	for mpls-outgoing; Wed, 26 Mar 2003 23:27:07 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohtd19649
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 23:27:02 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohtd08505
	for <mpls@uu.net>; Wed, 26 Mar 2003 23:26:08 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohtd18059
	for <mpls@uu.net>; Wed, 26 Mar 2003 23:26:07 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohtd18034
	for <mpls@uu.net>; Wed, 26 Mar 2003 23:26:07 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2QNQ4iH001063
	for <mpls@uu.net>; Wed, 26 Mar 2003 18:26:05 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA28054 for <mpls@uu.net>; Wed, 26 Mar 2003 18:26:04 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2QNQ4G21568 for mpls@uu.net; Wed, 26 Mar 2003 18:26:04 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohtd19338
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 23:24:45 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohtd21605
	for <mpls@UU.NET>; Wed, 26 Mar 2003 23:23:51 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohtd24540
	for <mpls@UU.NET>; Wed, 26 Mar 2003 23:23:50 GMT
Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQohtd24511
	for <mpls@UU.NET>; Wed, 26 Mar 2003 23:23:50 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id SAA33393;
	Wed, 26 Mar 2003 18:24:20 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303262324.SAA33393@workhorse.fictitious.org>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
cc: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "'Thomas D. Nadeau'" <tnadeau@lucidvision.com>,
        "'George Swallow'" <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'" <mpls@UU.NET>, tnadeau@cisco.com
Reply-To: curtis@fictitious.org
Subject: Re: [PWE3] MPLS PID 
In-reply-to: Your message of "Wed, 26 Mar 2003 14:42:49 PST."
             <4B6D09F3B826D411A67300D0B706EFDE0115C837@nt-exch-yow.pmc-sierra.bc.ca> 
Date: Wed, 26 Mar 2003 18:24:20 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <4B6D09F3B826D411A67300D0B706EFDE0115C837@nt-exch-yow.pmc-sierra.bc.
ca>, Shahram Davari writes:
> >A PID is not non-standard and proprietary if it is standardized and
> >that is what we are discussing.
> 
> That is exactly what I said. You want to standardize a proprietary PID that
> uses the first 4 bits. If it is approved by IETF then off course it won't be
> proprietary any more.
> 
> >
> >> Do you think that all hashing key selection algorithms by 
> >all vendors should 
> >> be supported
> >> by all IETF standards? What if one decides to use CRC to 
> >distinguish IP packe
> >> ts? should IETF
> >> standards be backward compatible with that too?
> >> 
> >> -Shahram
> >
> >RFC2991 is fine as is.  Load balancing algorithms exist.  There is no
> >need to standardize them.  Some are based on hashing.
> >
> 
> You didn't answer my question. I asked what if a vendor wants to use CRC as I
> P PID. 
> Should IETF protocols support them too by requiring that all other protocols 
> that
> get transported over MPLS not to produce a valid CRC?
> 
> BTW I never said we need to standardize load balancing algorithms. Where did 
> you get
> that from?
> 
> -Shahram


I don't feel obligated to answer nonsense questions.  No one has
proposed putting a CRC in the PID.

Curtis

ps - "requiring [..] not to produce a valid CRC" doesn't even parse in
english so your question is complete nonsense.



From owner-mpls@UU.NET  Wed Mar 26 19:11:31 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23952
	for <mpls-archive@lists.ietf.org>; Wed, 26 Mar 2003 19:11:31 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohtg04953
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 00:13:52 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohtg04706;
	Thu, 27 Mar 2003 00:13:39 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohte21270
	for mpls-outgoing; Wed, 26 Mar 2003 23:44:57 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohte21264
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 23:44:56 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohte23011
	for <mpls@UU.NET>; Wed, 26 Mar 2003 23:44:09 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohte05380
	for <mpls@UU.NET>; Wed, 26 Mar 2003 23:44:09 GMT
Received: from mailhost.avici.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [12.38.212.174])
	id QQohte05368
	for <mpls@UU.NET>; Wed, 26 Mar 2003 23:44:08 GMT
Received: from aatlas-lt.avici.com (b2-pc95.avici.com [10.2.100.125])
	by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id h2QNhHC05835;
	Wed, 26 Mar 2003 18:43:17 -0500 (EST)
Message-Id: <5.1.0.14.2.20030326184110.01c2d680@mailhost.avici.com>
X-Sender: aatlas@mailhost.avici.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 26 Mar 2003 18:43:34 -0500
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
From: Alia Atlas <aatlas@avici.com>
Subject: RE: [PWE3] MPLS PID 
Cc: "'Thomas Nadeau'" <tnadeau@cisco.com>,
        "'George Swallow'" <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'" <mpls@UU.NET>
In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C833@nt-exch-yow.pmc-s
 ierra.bc.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 01:33 PM 3/26/2003 -0800, Shahram Davari wrote:
>Tweaking IETF standards to try to support all possible proprietary hashing
>algorithms is not what I call standards development. What if a vendor decides
>to distinguish IP protocol using IP header CRC. Will we now mandate that 
>all encapsulated
>protocols should not yield a valid CRC at that specific position in the 
>header?

There is equipment that does look at the IP header CRC as well as the 
version field and various others for sanity-checking...  but I really think 
that any equipment which is sophisticated enough to compute and verify the 
IP header checksum will also check the version field.

>Egress always knows what protocol is encapsulated after the bottom label.

Not necessarily whether it is IPv4 or IPv6 except by checking the IP header.

Alia



From owner-mpls@UU.NET  Thu Mar 27 05:17:19 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21859
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 05:17:18 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohuv17590
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 10:19:39 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohuv17210;
	Thu, 27 Mar 2003 10:19:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohut10013
	for mpls-outgoing; Thu, 27 Mar 2003 09:52:41 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohut09999
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 09:52:22 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohut11621
	for <mpls@UU.NET>; Thu, 27 Mar 2003 09:49:56 GMT
From: jeremy.de_clercq@alcatel.be
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohut04898
	for <mpls@UU.NET>; Thu, 27 Mar 2003 09:49:55 GMT
Received: from relay2.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alc239.alcatel.be [195.207.101.239])
	id QQohut04843
	for <mpls@UU.NET>; Thu, 27 Mar 2003 09:49:54 GMT
Received: from bemail04.net.alcatel.be (localhost [127.0.0.1])
	by relay2.alcatel.be (8.10.1/8.11.4) with ESMTP id h2R9nDn22669;
	Thu, 27 Mar 2003 10:49:13 +0100 (MET)
Received: from alcatel.be ([138.203.67.106])
          by bemail04.net.alcatel.be (Lotus Domino Release 5.0.11)
          with ESMTP id 2003032710491077:2967 ;
          Thu, 27 Mar 2003 10:49:10 +0100 
Message-ID: <3E82C916.83E88CF0@alcatel.be>
Date: Thu, 27 Mar 2003 10:49:10 +0100
Organization: Alcatel
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: David Allan <dallan@nortelnetworks.com>
Cc: "'Scott W Brim'" <sbrim@cisco.com>, pwe3@ietf.org, mpls@UU.NET
Subject: Re: [PWE3] MPLS PID
References: <FFFC48AEAA5F7447929F4F0D93FCC12D016D2BEE@zcard031.ca.nortel.com>
X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 03/27/2003 10:49:10,
	Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 03/27/2003 10:49:12,
	Serialize complete at 03/27/2003 10:49:12
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dave, all,

> If we go on the assertion that MPLS should have had a PID (as opposed
> to current practice of binding protocols to labels) then we need to
> scope what we are really trying to achieve....
> 
> 1) Make the payload self describing to end points.
> 2) Multiplex payloads over a single LSP.
> 3) Make the payload self-describing to intermediate systems.
> 
> At the moment, 3 appears to be the exclusive motivation for this but
> has implications in 1 & 2 as we already have mechanisms for achieving
> those goals today (indirectly via signalling (1) & label stacking
> (2)).

If MPLS should have a PID, is it something that would be mandatory on
every LSP, or is the presence of this to be signaled (e.g. using a new
'PW type' in draft-ietf-pwe3-control-protocol (e.g. "type
Multi-Protocol")) ? I think that if MPLS PID is defined, the use of it
should be optional and signaled. So not "as opposed to binding protocols
to labels", but "as an optional alternative to binding protocols to
labels".

Applications for motivation 1) are described in
draft-moreels-multiproto-mpls-00.txt and in
draft-sajassi-l2vpn-interworking-01.txt.

thanks,
Jeremy.


From owner-mpls@UU.NET  Thu Mar 27 10:45:41 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04396
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 10:45:40 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohvr17852
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 15:47:59 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohvr17080;
	Thu, 27 Mar 2003 15:47:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohvn01713
	for mpls-outgoing; Thu, 27 Mar 2003 14:57:41 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohvn01708
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 14:57:26 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohvn09080
	for <mpls@uu.net>; Thu, 27 Mar 2003 14:57:08 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohvn02738
	for <mpls@uu.net>; Thu, 27 Mar 2003 14:57:07 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQohvn02698
	for <mpls@uu.net>; Thu, 27 Mar 2003 14:57:06 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2REv3MR019809
	for <mpls@uu.net>; Thu, 27 Mar 2003 09:57:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA13617 for <mpls@uu.net>; Thu, 27 Mar 2003 09:57:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2REv3H12040 for mpls@uu.net; Thu, 27 Mar 2003 09:57:03 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohvn01633
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 14:55:50 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohvn13298
	for <mpls@UU.NET>; Thu, 27 Mar 2003 14:54:03 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohvn14936
	for <mpls@UU.NET>; Thu, 27 Mar 2003 14:54:02 GMT
Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [216.241.224.12])
	id QQohvn14883
	for <mpls@UU.NET>; Thu, 27 Mar 2003 14:54:01 GMT
Received: (qmail 10089 invoked by uid 104); 27 Mar 2003 14:54:00 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4254.  Clear:. 
 Processed in 0.465483 secs); 27 Mar 2003 14:54:00 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by mother.pmc-sierra.com with SMTP; 27 Mar 2003 14:53:59 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h2REro617682;
	Thu, 27 Mar 2003 06:53:50 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <DCP442SX>; Thu, 27 Mar 2003 06:53:50 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115C838@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Alia Atlas'" <aatlas@avici.com>
Cc: "'Thomas Nadeau'" <tnadeau@cisco.com>,
        "'George Swallow'"
	 <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'"
	 <mpls@UU.NET>
Subject: RE: [PWE3] MPLS PID 
Date: Thu, 27 Mar 2003 06:53:48 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Alia,


>There is equipment that does look at the IP header CRC as well as the 
>version field and various others for sanity-checking...  but I 
>really think 
>that any equipment which is sophisticated enough to compute 
>and verify the 
>IP header checksum will also check the version field.

Agree, but what if the decision on whether the encapsulated
protocol is IP or not is done by CRC check and then the ver # is used
to indicate either IPv4 or IPv6?

>
>>Egress always knows what protocol is encapsulated after the 
>bottom label.
>
>Not necessarily whether it is IPv4 or IPv6 except by checking 
>the IP header.

I meant in knows whether it is IP or not. If IP then the Ver could be checked
otherwise ver field has no meaning.

-Shahram

>
>Alia
>



From owner-mpls@UU.NET  Thu Mar 27 11:27:30 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05945
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 11:27:30 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohvt02720
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 16:29:50 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohvt01279;
	Thu, 27 Mar 2003 16:29:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohvo20330
	for mpls-outgoing; Thu, 27 Mar 2003 15:11:07 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohvo20320
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 15:11:03 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohvo26142
	for <mpls@uu.net>; Thu, 27 Mar 2003 15:10:29 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohvo00186
	for <mpls@uu.net>; Thu, 27 Mar 2003 15:10:15 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQohvo00087
	for <mpls@uu.net>; Thu, 27 Mar 2003 15:10:10 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2RFA7MR021019
	for <mpls@uu.net>; Thu, 27 Mar 2003 10:10:07 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA14681 for <mpls@uu.net>; Thu, 27 Mar 2003 10:10:07 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2RFA7A13477 for mpls@uu.net; Thu, 27 Mar 2003 10:10:07 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohvo20046
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 15:09:22 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohvo22705
	for <mpls@UU.NET>; Thu, 27 Mar 2003 15:09:09 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohvo14265
	for <mpls@UU.NET>; Thu, 27 Mar 2003 15:08:56 GMT
Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [216.241.224.12])
	id QQohvo14071
	for <mpls@UU.NET>; Thu, 27 Mar 2003 15:08:40 GMT
Received: (qmail 15409 invoked by uid 104); 27 Mar 2003 15:08:38 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4254.  Clear:. 
 Processed in 0.470374 secs); 27 Mar 2003 15:08:38 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by mother.pmc-sierra.com with SMTP; 27 Mar 2003 15:08:37 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h2RF6o624682;
	Thu, 27 Mar 2003 07:08:37 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <DCP442ZJ>; Thu, 27 Mar 2003 07:06:50 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115C839@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>
Cc: "'Thomas D. Nadeau'" <tnadeau@lucidvision.com>,
        "'George Swallow'"
	 <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'"
	 <mpls@UU.NET>, tnadeau@cisco.com
Subject: RE: [PWE3] MPLS PID 
Date: Thu, 27 Mar 2003 07:06:49 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

>I don't feel obligated to answer nonsense questions.  No one has
>proposed putting a CRC in the PID.

First of all I meant computing CRC over the first 20 byte of payload header
and comparing it to the suspected IP CRC in octets 11 and 12 of the payload.
If they match then it is IPv4, if not it is something else (similar procedure for IPv6)

Secondly I am proposing it now. Is there a problem? I feel my procedure is far superior to just checking 4 bits to decide whether the payload is IP or not. 

>
>Curtis
>
>ps - "requiring [..] not to produce a valid CRC" doesn't even parse in
>english so your question is complete nonsense.


It makes perfect sense if you understand my proposal. I think you need to talk to Alia, since she could parse it correctly :)

-Shahram




From owner-mpls@UU.NET  Thu Mar 27 11:38:58 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06922
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 11:38:58 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohvu27573
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 16:41:18 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohvu26922;
	Thu, 27 Mar 2003 16:41:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohvp22195
	for mpls-outgoing; Thu, 27 Mar 2003 15:22:36 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohvp22177
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 15:22:06 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohvp22380
	for <mpls@uu.net>; Thu, 27 Mar 2003 15:21:11 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohvp06697
	for <mpls@uu.net>; Thu, 27 Mar 2003 15:21:11 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohvp06685
	for <mpls@uu.net>; Thu, 27 Mar 2003 15:21:10 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2RFL7iH012807
	for <mpls@uu.net>; Thu, 27 Mar 2003 10:21:08 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA15760 for <mpls@uu.net>; Thu, 27 Mar 2003 10:21:07 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2RFL7f15215 for mpls@uu.net; Thu, 27 Mar 2003 10:21:07 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohsr05345
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 20:18:16 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohsr09422
	for <mpls@UU.NET>; Wed, 26 Mar 2003 20:17:43 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsr09726
	for <mpls@UU.NET>; Wed, 26 Mar 2003 20:17:42 GMT
Received: from lucidvision.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [206.67.54.196])
	id QQohsr09717
	for <mpls@UU.NET>; Wed, 26 Mar 2003 20:17:41 GMT
Received: from tnadeau-w2k.lucidvision.com [66.30.60.75] by lucidvision.com with ESMTP
  (SMTPD32-7.13) id AAB3B201B6; Wed, 26 Mar 2003 15:16:51 -0500
Message-Id: <5.2.0.9.2.20030326151521.03340220@bucket.cisco.com>
X-Sender: tnadeau@www.lucidvision.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 26 Mar 2003 15:15:38 -0500
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>,
        "'George Swallow'" <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>
From: "Thomas D. Nadeau" <tnadeau@lucidvision.com>
Subject: RE: [PWE3] MPLS PID 
Cc: "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'" <mpls@UU.NET>, tnadeau@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 02:18 PM 3/25/2003 -0800, Shahram Davari wrote:

> >1.  Dealing with ECMP behavior
> >2.  Inband OAM flows
> >3.  Identifying flows for netmanagement applications.
> >
>
>I don't think any of them justifies adding PID.
>
>1) ECMP could use only label hashing and not hash IP header.

         This is unrealistic. Lots of vendors hash on both,
one or the other.  Lets not go down the road of trying
to mandate how ECMP works again. We went down that
road in MPLS and the response was clear.

>2) OAM flows could use IPv4/V6 null or MPLS Alert label

         Encased in the PW or just as a label stack?

>3) Netmanagment could identify the flow at the ingress.

         What about the egress?

         --Tom


>-Shahram




From owner-mpls@UU.NET  Thu Mar 27 11:39:12 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06969
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 11:39:12 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohvu11315
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 16:41:33 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohvu10022;
	Thu, 27 Mar 2003 16:40:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohvp22157
	for mpls-outgoing; Thu, 27 Mar 2003 15:21:39 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohvp22066
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 15:21:34 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohvp24947
	for <mpls@uu.net>; Thu, 27 Mar 2003 15:21:29 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohvp07217
	for <mpls@uu.net>; Thu, 27 Mar 2003 15:21:28 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohvp07209
	for <mpls@uu.net>; Thu, 27 Mar 2003 15:21:27 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2RFLPiH012913
	for <mpls@uu.net>; Thu, 27 Mar 2003 10:21:25 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA15793 for <mpls@uu.net>; Thu, 27 Mar 2003 10:21:24 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2RFLOL15250 for mpls@uu.net; Thu, 27 Mar 2003 10:21:24 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohsr05348
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 20:18:16 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohsr10071
	for <mpls@uu.net>; Wed, 26 Mar 2003 20:18:08 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohsr10485
	for <mpls@uu.net>; Wed, 26 Mar 2003 20:18:07 GMT
Received: from lucidvision.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [206.67.54.196])
	id QQohsr10460
	for <mpls@uu.net>; Wed, 26 Mar 2003 20:18:06 GMT
Received: from tnadeau-w2k.lucidvision.com [66.30.60.75] by lucidvision.com with ESMTP
  (SMTPD32-7.13) id AACD1501A8; Wed, 26 Mar 2003 15:17:17 -0500
Message-Id: <5.2.0.9.2.20030326151606.03383e10@bucket.cisco.com>
X-Sender: tnadeau@www.lucidvision.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 26 Mar 2003 15:16:14 -0500
To: "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>, pwe3@ietf.org
From: "Thomas D. Nadeau" <tnadeau@lucidvision.com>
Subject: RE: [PWE3] MPLS PID 
Cc: mpls@UU.NET, tnadeau@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 06:52 PM 3/25/2003 -0500, Andrew G. Malis wrote:
>Shahram and Alia both make excellent points:
>
>At 3/25/2003 02:18 PM -0800, Shahram Davari wrote:
>> >1.  Dealing with ECMP behavior
>> >2.  Inband OAM flows
>> >3.  Identifying flows for netmanagement applications.
>>
>>I don't think any of them justifies adding PID.
>>
>>1) ECMP could use only label hashing and not hash IP header.
>>2) OAM flows could use IPv4/V6 null or MPLS Alert label
>>3) Netmanagment could identify the flow at the ingress.
>
>At 3/25/2003 06:15 PM -0500, Alia Atlas wrote:
>>How does requiring a PID in the PWE3 L2 control word solve or handle the 
>>case where a control word is not mandatory?
>>
>>There are pseudo-wires, such as ethernet, where a control word is not 
>>mandatory.  This would imply that the first nibble (which would be 
>>identified as the suggested PID) would be that from the ethernet frame.
>
>We're going to have to change the PWE3 drafts to require the control word, 
>and change both the SONET/SDH and some of the ATM encapsulations, to 
>support a hack.

         Andy,

         Some people believe that the non-use of the control
word is a hack/micro-optimization that should be removed.

>If you REALLY want multi-protocol identification, then have the MPLS WG 
>put a REAL multiprotocol identifier, a la RFC 2427 or 2684, between the 
>labels and the payload.  See, for example, 
>draft-moreels-multiproto-mpls-00.txt for a much more general (and useful) 
>method than just a four-bit hack.  And sorry for the cross-post, but this 
>really does affect both WGs.

         Do you think that it is realistic to go back and change
the MPLS header format at this point in the game?

         --Tom



>Cheers,
>Andy
>
>_______________________________________________
>pwe3 mailing list
>pwe3@ietf.org
>https://www1.ietf.org/mailman/listinfo/pwe3




From owner-mpls@UU.NET  Thu Mar 27 11:39:34 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07031
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 11:39:34 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohvu29052
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 16:41:54 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohvu27967;
	Thu, 27 Mar 2003 16:41:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohvp22305
	for mpls-outgoing; Thu, 27 Mar 2003 15:24:13 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohvp22297
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 15:24:11 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohvp24031
	for <mpls@uu.net>; Thu, 27 Mar 2003 15:20:56 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohvp21561
	for <mpls@uu.net>; Thu, 27 Mar 2003 15:20:55 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQohvp21554
	for <mpls@uu.net>; Thu, 27 Mar 2003 15:20:55 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2RFKqMR022053
	for <mpls@uu.net>; Thu, 27 Mar 2003 10:20:52 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA15739 for <mpls@uu.net>; Thu, 27 Mar 2003 10:20:52 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2RFKq015070 for mpls@uu.net; Thu, 27 Mar 2003 10:20:52 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohsj18270
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Mar 2003 18:26:38 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohsj19788
	for <mpls@uu.net>; Wed, 26 Mar 2003 18:26:17 GMT
Received: from antivir1.rad.co.il by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: radmail1.rad.co.il [62.0.23.193])
	id QQohsa08276
	for <mpls@uu.net>; Wed, 26 Mar 2003 16:08:16 GMT
Received: from antivir1.rad.co.il (localhost [127.0.0.1])
	by antivir1.rad.co.il (8.12.1/8.12.1) with ESMTP id h2QG7qY7022721
	for <mpls@uu.net>; Wed, 26 Mar 2003 18:07:52 +0200 (IST)
Received: from exrad2.ad.rad.co.il ([192.114.24.112])
	by antivir1.rad.co.il (8.12.1/8.12.1) with ESMTP id h2QG7poJ022709
	for <mpls@uu.net>; Wed, 26 Mar 2003 18:07:51 +0200 (IST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [PWE3] MPLS PID
Date: Wed, 26 Mar 2003 18:07:58 +0200
Message-ID: <27A0F290348F8E45AEF79889DDE65A5281AC29@exrad2.ad.rad.co.il>
Thread-Topic: [PWE3] MPLS PID
Thread-Index: AcLzpSf9PkyqhDWCQlOuxKT7VMdhEgADAg+Q
From: "Yaakov Stein" <yaakov_s@rad.com>
To: "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>
Cc: <pwe3@ietf.org>, <mpls@UU.NET>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA07031

> One possibility for an extended PID that comes to mind is 
> defining one of the remaining 14 values within the first nibble as "extended PID" 
> and follow it with whatever PID definition you like.

Another, which I proposed in draft-stein-pwe3-controlword-00.txt, 
is to use the 4 bits to disambiguate the relevant possibilities.

Since an atm-encap implementation will probably not understand
ethernet-encap, the non 4/6 values could be used for submodes
(e.g. 1:1, N:1, PDU, SDU).
Similarly, the TDM sub-identifier could differentiate between
raw,  AAL1, AAL2, etc.

Alternatively, we could go for a "sanity check"
PWE identifier. We have 14 values available
and so far have only defined a few PW types
(ATM, FR, SONET, TDM, ethernet).

Y(J)S



From owner-mpls@UU.NET  Thu Mar 27 12:00:06 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07847
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 12:00:06 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohvw02169
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 17:02:26 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohvw01398;
	Thu, 27 Mar 2003 17:02:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohvt15532
	for mpls-outgoing; Thu, 27 Mar 2003 16:15:38 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQohvt15525
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 16:15:26 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohvt08769
	for <mpls@UU.NET>; Thu, 27 Mar 2003 16:15:07 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohvs28896
	for <mpls@UU.NET>; Thu, 27 Mar 2003 16:14:58 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohvs28042
	for <mpls@UU.NET>; Thu, 27 Mar 2003 16:14:40 GMT
Received: from cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2RGDOiH028923;
	Thu, 27 Mar 2003 11:13:24 -0500 (EST)
Message-Id: <200303271613.h2RGDOiH028923@rtp-core-1.cisco.com>
To: jeremy.de_clercq@alcatel.be
cc: David Allan <dallan@nortelnetworks.com>,
        "'Scott W Brim'" <sbrim@cisco.com>, pwe3@ietf.org, mpls@UU.NET
Subject: Re: [PWE3] MPLS PID 
In-reply-to: Your message of Thu, 27 Mar 2003 10:49:10 +0100.
             <3E82C916.83E88CF0@alcatel.be> 
Reply-To: erosen@cisco.com
User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3
 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2
 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 27 Mar 2003 11:13:23 -0500
From: Eric Rosen <erosen@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


Let's try to focus a little. 

1. The  only  reason for  a  PID  field in  MPLS  and/or  PWE3  is to  allow
   intermediate routers to determine whether a particular MPLS payload is an
   IP packet or not. 

   There are a number  of reasons why this is useful, and  no one has argued
   that this is not useful. 

   No one  has provided  a reason  why it might  be useful  for intermediate
   routers to know, if the payload is not IP, what kind of packet it is.  

2. The reason there is  no PID field in the MPLS header  is that there was a
   consensus to keep the header as short as possible.

3. The reason the PWE3 control word is optional is that there is a consensus
   (apparently a continuing one) to  allow service providers to specify that
   the header be kept as short as possible. 

4. My conclusion from 2 and 3 is that there isn't much hope for any solution
   which includes both a PWE3 control word AND a 4-byte MPLS PID field. 

5. There is anyway  no way for the IETF to change  the basic MPLS forwarding
   logic, at least  not in the time  frame over which one would  like to see
   PWE3 deployments.

5. My further  conclusion is that, as Mark has  suggested, the only possible
   outcome  of a  discussion in  the MPLS  WG is  a recommendation  that any
   non-IP application using  MPLS specify a control word  whose first nibble
   is as Stewart has proposed for PWE3. 

6. No one has given  a reason why the first nibble of  any such control word
   should not be as Stewart has proposed.

7. The PWE3 control word can be specified as a mandatory-to-implement option
   which a SP  can disable if his environment is such  he doesn't care about
   the absence of the PID. 

So I really think there is only one possible outcome.  The only issue is how
much time  and breath we want  to waste until we  get there.  A  SP is faced
with the choice of either:

a. Requiring the use of a Martini-style PID, or 

b. Ensuring that his pseudowires only carry non-order-sensitive traffic, or

c. Ensuring that  his PWE3 packets do not pass  through any MPLS environment
   in which load balancing is done. 

Encapsulations which do not use the Martini-style control word are therefore
at a  disadvantage.  We  should make sure  therefore that  any encapsulation
which actually solves a problem for the industry has a control word with the
first nibble as Stewart has proposed. 








From owner-mpls@UU.NET  Thu Mar 27 13:01:46 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10451
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 13:01:46 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwa01289
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 18:04:07 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohwa00331;
	Thu, 27 Mar 2003 18:03:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohvy10726
	for mpls-outgoing; Thu, 27 Mar 2003 17:37:01 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohvy10721
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 17:36:57 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohvy27541
	for <mpls@UU.NET>; Thu, 27 Mar 2003 17:35:58 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohvy26762
	for <mpls@UU.NET>; Thu, 27 Mar 2003 17:35:57 GMT
Received: from thurn.corp.titan.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: thurn.corp.titan.com [159.62.51.20])
	id QQohvy26745
	for <mpls@UU.NET>; Thu, 27 Mar 2003 17:35:57 GMT
Received: from vcmd-nt1.validity.com (val114-005.validity.titan.com [159.62.114.5])
	by thurn.corp.titan.com (8.12.8/8.12.8) with ESMTP id h2RHZDrF026896;
	Thu, 27 Mar 2003 09:35:15 -0800
Received: by VCMD-NT1 with Internet Mail Service (5.5.2655.55)
	id <HYNAVHM8>; Thu, 27 Mar 2003 12:34:29 -0500
Message-ID: <561621C69F17D511A3A20050047340EC01AAF645@VCMD-NT1>
From: "Ferrell, William" <William.Ferrell@titan.com>
To: "'Naidu, Venkata'" <Venkata.Naidu@Marconi.com>,
        "'Shahram Davari'"
	 <Shahram_Davari@pmc-sierra.com>,
        "'curtis@fictitious.org'"
	 <curtis@fictitious.org>
Cc: "'Thomas D. Nadeau'" <tnadeau@lucidvision.com>,
        "'George Swallow'"
	 <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'"
	 <mpls@UU.NET>, tnadeau@cisco.com
Subject: RE: [PWE3] MPLS PID 
Date: Thu, 27 Mar 2003 12:34:19 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

I tend to agree , useing the CRC is one of the oldest and proven methods but
is one of the easiest to subvert and corrupt. When developing the protocol
one has to keep in mind of a way of integrating a security solution. oftens
we've put in a functional solution and then been forced change/modify it to
fit with a security option and ending up with a less effective product in
the end.
Will

-----Original Message-----
From: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com]
Sent: Thursday, March 27, 2003 12:12 PM
To: 'Shahram Davari'; 'curtis@fictitious.org'
Cc: 'Thomas D. Nadeau'; 'George Swallow'; W. Mark Townsley; Andrew G.
Malis; 'mpls@uu.net'; tnadeau@cisco.com
Subject: RE: [PWE3] MPLS PID 


Shahram,

-> First of all I meant computing CRC over the first 20 byte of 
-> payload header
-> and comparing it to the suspected IP CRC in octets 11 and 12 
-> of the payload.
-> If they match then it is IPv4, if not it is something else 
-> (similar procedure for IPv6)
-> 
-> Secondly I am proposing it now. Is there a problem? 

  Yes. There is a problem. First of all relaying on CRC to
  figure out the *type* of payload is not at all advisable.
  One could produce (there is a remote possibility) a payload
  which is not IPv4 or IPv6 but the CRC can be matched to
  the payload of first 20 bytes to the bytes in 11 & 12.

  RFC1071 uses 16 bit's one's compliment, which we all know
  that won't catch all the bit errors/flips.

Venkata.


From owner-mpls@UU.NET  Thu Mar 27 13:17:02 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10780
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 13:17:01 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohvy04474
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 17:39:41 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohvy03679;
	Thu, 27 Mar 2003 17:39:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohvw08966
	for mpls-outgoing; Thu, 27 Mar 2003 17:13:26 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohvw08955
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 17:13:12 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohvw11014
	for <mpls@UU.NET>; Thu, 27 Mar 2003 17:12:47 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohvw21057
	for <mpls@UU.NET>; Thu, 27 Mar 2003 17:12:47 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQohvw21030
	for <mpls@UU.NET>; Thu, 27 Mar 2003 17:12:47 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA12272;
	Thu, 27 Mar 2003 12:12:35 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA06526;
	Thu, 27 Mar 2003 12:12:07 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <HMVZC7F1>; Thu, 27 Mar 2003 12:12:07 -0500
Message-ID: <39469E08BD83D411A3D900204840EC55763570@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        "'curtis@fictitious.org'" <curtis@fictitious.org>
Cc: "'Thomas D. Nadeau'" <tnadeau@lucidvision.com>,
        "'George Swallow'"
	 <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'"
	 <mpls@UU.NET>, tnadeau@cisco.com
Subject: RE: [PWE3] MPLS PID 
Date: Thu, 27 Mar 2003 12:12:06 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Shahram,

-> First of all I meant computing CRC over the first 20 byte of 
-> payload header
-> and comparing it to the suspected IP CRC in octets 11 and 12 
-> of the payload.
-> If they match then it is IPv4, if not it is something else 
-> (similar procedure for IPv6)
-> 
-> Secondly I am proposing it now. Is there a problem? 

  Yes. There is a problem. First of all relaying on CRC to
  figure out the *type* of payload is not at all advisable.
  One could produce (there is a remote possibility) a payload
  which is not IPv4 or IPv6 but the CRC can be matched to
  the payload of first 20 bytes to the bytes in 11 & 12.

  RFC1071 uses 16 bit's one's compliment, which we all know
  that won't catch all the bit errors/flips.

Venkata.


From owner-mpls@UU.NET  Thu Mar 27 13:47:07 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12013
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 13:47:06 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwd27777
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 18:49:26 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohwd25449;
	Thu, 27 Mar 2003 18:48:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohwb02423
	for mpls-outgoing; Thu, 27 Mar 2003 18:17:08 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohwb02415
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 18:17:03 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohwb12878
	for <mpls@uu.net>; Thu, 27 Mar 2003 18:16:09 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwb29815
	for <mpls@uu.net>; Thu, 27 Mar 2003 18:16:08 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohwb29725
	for <mpls@uu.net>; Thu, 27 Mar 2003 18:16:06 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2RIG3iH024441
	for <mpls@uu.net>; Thu, 27 Mar 2003 13:16:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA01014 for <mpls@uu.net>; Thu, 27 Mar 2003 13:16:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2RIG2s05803 for mpls@uu.net; Thu, 27 Mar 2003 13:16:02 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohwa01932
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 18:14:50 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohwa08808
	for <mpls@UU.NET>; Thu, 27 Mar 2003 18:13:36 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwa16642
	for <mpls@UU.NET>; Thu, 27 Mar 2003 18:13:35 GMT
Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [216.241.224.12])
	id QQohwa16627
	for <mpls@UU.NET>; Thu, 27 Mar 2003 18:13:34 GMT
Received: (qmail 24148 invoked by uid 104); 27 Mar 2003 18:13:34 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4254.  Clear:. 
 Processed in 0.485773 secs); 27 Mar 2003 18:13:34 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by mother.pmc-sierra.com with SMTP; 27 Mar 2003 18:13:33 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h2RICB626868;
	Thu, 27 Mar 2003 10:12:11 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <DCP44M77>; Thu, 27 Mar 2003 10:12:11 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115C843@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Naidu, Venkata'" <Venkata.Naidu@Marconi.com>,
        "'curtis@fictitious.org'" <curtis@fictitious.org>
Cc: "'Thomas D. Nadeau'" <tnadeau@lucidvision.com>,
        "'George Swallow'"
	 <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'"
	 <mpls@UU.NET>, tnadeau@cisco.com
Subject: RE: [PWE3] MPLS PID 
Date: Thu, 27 Mar 2003 10:12:08 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

>Shahram,
>
>-> First of all I meant computing CRC over the first 20 byte of 
>-> payload header
>-> and comparing it to the suspected IP CRC in octets 11 and 12 
>-> of the payload.
>-> If they match then it is IPv4, if not it is something else 
>-> (similar procedure for IPv6)
>-> 
>-> Secondly I am proposing it now. Is there a problem? 
>
>  Yes. There is a problem. First of all relaying on CRC to
>  figure out the *type* of payload is not at all advisable.
>  One could produce (there is a remote possibility) a payload
>  which is not IPv4 or IPv6 but the CRC can be matched to
>  the payload of first 20 bytes to the bytes in 11 & 12.
>
>  RFC1071 uses 16 bit's one's compliment, which we all know
>  that won't catch all the bit errors/flips.

Agree, but isn't it better than relying on the first 4 bit of the
payload to indicate IPV4/v6? The possibility of a non-IP
payload to have its first 4 bits to be equal 2 or 4 is 2/16=12.5% while
the possibility of a 20 byte payload to match a particular CRC-32
is much mush lower.

The reason I mentioned this example was that some argued that all
ECMP methods must be supported.

-Shahram

>
>Venkata.
>



From owner-mpls@UU.NET  Thu Mar 27 14:07:32 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13267
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 14:07:32 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwe16058
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 19:09:53 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohwe15113;
	Thu, 27 Mar 2003 19:09:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohwb03141
	for mpls-outgoing; Thu, 27 Mar 2003 18:27:25 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohwb03136
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 18:27:24 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohwb01984
	for <mpls@UU.NET>; Thu, 27 Mar 2003 18:26:12 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwb24360
	for <mpls@UU.NET>; Thu, 27 Mar 2003 18:26:11 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohwb24269
	for <mpls@UU.NET>; Thu, 27 Mar 2003 18:26:09 GMT
Received: from cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2RIQ2iH026546;
	Thu, 27 Mar 2003 13:26:03 -0500 (EST)
Message-Id: <200303271826.h2RIQ2iH026546@rtp-core-1.cisco.com>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
cc: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "'Thomas D. Nadeau'" <tnadeau@lucidvision.com>,
        "'George Swallow'" <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'" <mpls@UU.NET>, tnadeau@cisco.com
Subject: Re: [PWE3] MPLS PID 
In-reply-to: Your message of Thu, 27 Mar 2003 07:06:49 -0800.
             <4B6D09F3B826D411A67300D0B706EFDE0115C839@nt-exch-yow.pmc-sierra.bc.ca> 
Reply-To: erosen@cisco.com
User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3
 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2
 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 27 Mar 2003 13:26:02 -0500
From: Eric Rosen <erosen@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


Shahram> First  of all  I meant  computing  CRC over  the first  20 byte  of
Shahram> payload header and  comparing it to the suspected  IP CRC in octets
Shahram> 11 and 12 of the payload. If  they match then it is IPv4, if not it
Shahram> is something else (similar procedure for IPv6)

Shahram> Secondly  I am  proposing it  now. Is  there a  problem? I  feel my
Shahram> procedure is far superior to just checking 4 bits to decide whether
Shahram> the payload is IP or not. 

Certainly it's  not superior in  terms of the  amount of computation  or the
number of memory accesses required ;-)

Architecturally,  it doesn't  seem  superior  either.  It  is  based on  the
assumption that the one's complement sum of the first 20 bytes of a non-IPv4
payload will not be zero.  And it doesn't seem to handle IPv6. 





From owner-mpls@UU.NET  Thu Mar 27 17:57:27 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23124
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 17:57:27 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwt11284
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 22:59:47 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohwt10290;
	Thu, 27 Mar 2003 22:59:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohwd06011
	for mpls-outgoing; Thu, 27 Mar 2003 18:54:28 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohwd05990
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 18:54:10 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohwd24888
	for <mpls@uu.net>; Thu, 27 Mar 2003 18:53:20 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwd29795
	for <mpls@uu.net>; Thu, 27 Mar 2003 18:53:18 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohwd29753
	for <mpls@uu.net>; Thu, 27 Mar 2003 18:53:17 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2RIrEiH002338
	for <mpls@uu.net>; Thu, 27 Mar 2003 13:53:14 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA04347 for <mpls@uu.net>; Thu, 27 Mar 2003 13:53:13 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2RIrDS10725 for mpls@uu.net; Thu, 27 Mar 2003 13:53:13 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohwd05672
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 18:51:47 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohwd18231
	for <mpls@UU.NET>; Thu, 27 Mar 2003 18:51:14 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwd25821
	for <mpls@UU.NET>; Thu, 27 Mar 2003 18:51:14 GMT
Received: from father.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: father.pmc-sierra.com [216.241.224.13])
	id QQohwd25796
	for <mpls@UU.NET>; Thu, 27 Mar 2003 18:51:13 GMT
Received: (qmail 29582 invoked by uid 104); 27 Mar 2003 18:51:13 -0000
Received: from Shahram_Davari@pmc-sierra.com by father by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4254.  Clear:. 
 Processed in 0.476148 secs); 27 Mar 2003 18:51:13 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by father.pmc-sierra.com with SMTP; 27 Mar 2003 18:51:11 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h2RIo1614633;
	Thu, 27 Mar 2003 10:50:01 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <DCP44N6F>; Thu, 27 Mar 2003 10:50:00 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115C845@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'erosen@cisco.com'" <erosen@cisco.com>
Cc: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "'Thomas D. Nadeau'" <tnadeau@lucidvision.com>,
        "'George Swallow'"
	 <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'"
	 <mpls@UU.NET>, tnadeau@cisco.com
Subject: RE: [PWE3] MPLS PID 
Date: Thu, 27 Mar 2003 10:49:58 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

>Shahram> First  of all  I meant  computing  CRC over  the 
>first  20 byte  of
>Shahram> payload header and  comparing it to the suspected  IP 
>CRC in octets
>Shahram> 11 and 12 of the payload. If  they match then it is 
>IPV4, if not it
>Shahram> is something else (similar procedure for IPV6)
>
>Shahram> Secondly  I am  proposing it  now. Is  there a  
>problem? I  feel my
>Shahram> procedure is far superior to just checking 4 bits to 
>decide whether
>Shahram> the payload is IP or not. 
>
>Certainly it's  not superior in  terms of the  amount of 
>computation  or the
>number of memory accesses required ;-)

Checksum is easy and is done all the time in routers, but the main point is that
my proposal superior in terms of probability of false positives,
which is much more important. Using the first 4 bit to detect whether
the payload is IP or not gives you a probability of false positive of
1/8=12.5%, while using CRC to detect IP gives you a probability of false
positive of 1/(2^16)= 0.0015%.

>
>Architecturally,  it doesn't  seem  superior  either.  It  is  
>based on  the
>assumption that the one's complement sum of the first 20 bytes 
>of a non-IPv4
>payload will not be zero.

Which ensures a much less probability of false positive than simply using the first nibble.

> And it doesn't seem to handle IPv6.

Correct.

-Shahram
>
>
>



From owner-mpls@UU.NET  Thu Mar 27 18:09:11 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24011
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 18:09:11 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwu27174
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 23:11:29 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohwu23602;
	Thu, 27 Mar 2003 23:09:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohwd06357
	for mpls-outgoing; Thu, 27 Mar 2003 18:58:47 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohwd06338
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 18:58:31 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohwd08341
	for <mpls@uu.net>; Thu, 27 Mar 2003 18:58:09 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwd16572
	for <mpls@uu.net>; Thu, 27 Mar 2003 18:58:08 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQohwd16533
	for <mpls@uu.net>; Thu, 27 Mar 2003 18:58:07 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2RIw4MR012557
	for <mpls@uu.net>; Thu, 27 Mar 2003 13:58:04 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA04853 for <mpls@uu.net>; Thu, 27 Mar 2003 13:58:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2RIw3D11346 for mpls@uu.net; Thu, 27 Mar 2003 13:58:03 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohwd06276
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 18:56:41 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohwd21963
	for <mpls@UU.NET>; Thu, 27 Mar 2003 18:56:30 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwd06313
	for <mpls@UU.NET>; Thu, 27 Mar 2003 18:56:29 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohwd06305
	for <mpls@UU.NET>; Thu, 27 Mar 2003 18:56:29 GMT
Received: from bucket.cisco.com (IDENT:mirapoint@bucket.cisco.com [161.44.167.72])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2RIuMiH002936;
	Thu, 27 Mar 2003 13:56:22 -0500 (EST)
Received: from tnadeau-w2k.cisco.com (ch2-dhcp134-173.cisco.com [161.44.134.173])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ACV38862;
	Thu, 27 Mar 2003 13:56:20 -0500 (EST)
Message-Id: <5.2.0.9.2.20030327135539.02a2ee78@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 27 Mar 2003 13:56:17 -0500
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>,
        "'curtis@fictitious.org'" <curtis@fictitious.org>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: [PWE3] MPLS PID 
Cc: "'Thomas D. Nadeau'" <tnadeau@lucidvision.com>,
        "'George Swallow'" <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'" <mpls@UU.NET>
In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C839@nt-exch-yow.pmc-s
 ierra.bc.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


> >I don't feel obligated to answer nonsense questions.  No one has
> >proposed putting a CRC in the PID.
>
>First of all I meant computing CRC over the first 20 byte of payload header
>and comparing it to the suspected IP CRC in octets 11 and 12 of the payload.
>If they match then it is IPv4, if not it is something else (similar 
>procedure for IPv6)

         Doesn't this seem like a bit of a kludge that is prone to
potential errors?

         --Tom


>Secondly I am proposing it now. Is there a problem? I feel my procedure is 
>far superior to just checking 4 bits to decide whether the payload is IP 
>or not.
>
> >
> >Curtis
> >
> >ps - "requiring [..] not to produce a valid CRC" doesn't even parse in
> >english so your question is complete nonsense.
>
>
>It makes perfect sense if you understand my proposal. I think you need to 
>talk to Alia, since she could parse it correctly :)
>
>-Shahram


http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X




From owner-mpls@UU.NET  Thu Mar 27 18:12:23 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24490
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 18:12:23 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwu04081
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 23:14:43 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohwu02418;
	Thu, 27 Mar 2003 23:13:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohwe15057
	for mpls-outgoing; Thu, 27 Mar 2003 19:01:28 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohwe14791
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 19:01:25 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohwe13868
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:00:19 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwe14210
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:00:18 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohwe14185
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:00:18 GMT
Received: from cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2RJ07iH003717;
	Thu, 27 Mar 2003 14:00:08 -0500 (EST)
Message-Id: <200303271900.h2RJ07iH003717@rtp-core-1.cisco.com>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
cc: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "'Thomas D. Nadeau'" <tnadeau@lucidvision.com>,
        "'George Swallow'" <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'" <mpls@UU.NET>, tnadeau@cisco.com
Subject: Re: [PWE3] MPLS PID 
In-reply-to: Your message of Thu, 27 Mar 2003 10:49:58 -0800.
             <4B6D09F3B826D411A67300D0B706EFDE0115C845@nt-exch-yow.pmc-sierra.bc.ca> 
Reply-To: erosen@cisco.com
User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3
 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2
 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 27 Mar 2003 14:00:06 -0500
From: Eric Rosen <erosen@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


Shahram> my proposal superior in terms of probability of false positives,

Only in  the absence of  the control word.   In the presence of  the control
word, there are no false positives. 

Shahram> Checksum is easy and is done all the time in routers

For IPv4  packets, but for non-IPv4  packets, this is extra  work that would
not otherwise need  to be done.  Extra code too (gates  or microcode), as it
would happen  in a different  forwarding path than  that used for  IPv4, and
microcoders and hardware designers are not very big on calling subroutines. 





From owner-mpls@UU.NET  Thu Mar 27 18:18:58 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25132
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 18:18:57 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwv09240
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 23:21:16 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohwv06408;
	Thu, 27 Mar 2003 23:19:59 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohwe24557
	for mpls-outgoing; Thu, 27 Mar 2003 19:05:25 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohwe24118
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 19:04:51 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohwe14250
	for <mpls@uu.net>; Thu, 27 Mar 2003 19:04:25 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwe01949
	for <mpls@uu.net>; Thu, 27 Mar 2003 19:04:21 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQohwe01240
	for <mpls@uu.net>; Thu, 27 Mar 2003 19:04:06 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2RJ43MR013090
	for <mpls@uu.net>; Thu, 27 Mar 2003 14:04:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA05407 for <mpls@uu.net>; Thu, 27 Mar 2003 14:04:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2RJ43J12005 for mpls@uu.net; Thu, 27 Mar 2003 14:04:03 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQohwe11713
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 19:00:59 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohwe21039
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:00:11 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwe20644
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:00:10 GMT
Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [216.241.224.12])
	id QQohwe20443
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:00:05 GMT
Received: (qmail 9247 invoked by uid 104); 27 Mar 2003 19:00:00 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4254.  Clear:. 
 Processed in 0.463899 secs); 27 Mar 2003 19:00:00 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by mother.pmc-sierra.com with SMTP; 27 Mar 2003 18:59:59 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h2RIwc618504;
	Thu, 27 Mar 2003 10:58:38 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <DCP443D1>; Thu, 27 Mar 2003 10:58:32 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115C846@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Thomas D. Nadeau'" <tnadeau@cisco.com>,
        "'curtis@fictitious.org'"
	 <curtis@fictitious.org>
Cc: "'Thomas D. Nadeau'" <tnadeau@lucidvision.com>,
        "'George Swallow'"
	 <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'"
	 <mpls@UU.NET>
Subject: RE: [PWE3] MPLS PID 
Date: Thu, 27 Mar 2003 10:58:31 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

It certainly is a better kludge than checking the first 4 bits to decide whether
the payload is IP or not.

-Shahram

>-----Original Message-----
>From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
>Sent: Thursday, March 27, 2003 1:56 PM
>To: Shahram Davari; 'curtis@fictitious.org'
>Cc: 'Thomas D. Nadeau'; 'George Swallow'; W. Mark Townsley; Andrew G.
>Malis; 'mpls@uu.net'
>Subject: RE: [PWE3] MPLS PID 
>
>
>
>> >I don't feel obligated to answer nonsense questions.  No one has
>> >proposed putting a CRC in the PID.
>>
>>First of all I meant computing CRC over the first 20 byte of 
>payload header
>>and comparing it to the suspected IP CRC in octets 11 and 12 
>of the payload.
>>If they match then it is IPv4, if not it is something else (similar 
>>procedure for IPv6)
>
>         Doesn't this seem like a bit of a kludge that is prone to
>potential errors?
>
>         --Tom
>
>
>>Secondly I am proposing it now. Is there a problem? I feel my 
>procedure is 
>>far superior to just checking 4 bits to decide whether the 
>payload is IP 
>>or not.
>>
>> >
>> >Curtis
>> >
>> >ps - "requiring [..] not to produce a valid CRC" doesn't 
>even parse in
>> >english so your question is complete nonsense.
>>
>>
>>It makes perfect sense if you understand my proposal. I think 
>you need to 
>>talk to Alia, since she could parse it correctly :)
>>
>>-Shahram
>
>
>http://www.elsevier-international.com/catalogue/title.cfm?ISBN=
>155860751X
>
>



From owner-mpls@UU.NET  Thu Mar 27 18:18:58 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25137
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 18:18:58 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwv09325
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 23:21:18 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohwv06570;
	Thu, 27 Mar 2003 23:20:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohwe24018
	for mpls-outgoing; Thu, 27 Mar 2003 19:04:23 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohwe23989
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 19:04:12 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohwe23008
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:03:47 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwe23954
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:03:44 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohwe23765
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:03:41 GMT
Received: from cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2RJ3PiH004523;
	Thu, 27 Mar 2003 14:03:25 -0500 (EST)
Message-Id: <200303271903.h2RJ3PiH004523@rtp-core-1.cisco.com>
To: "David Allan" <dallan@nortelnetworks.com>
cc: jeremy.de_clercq@alcatel.be, "'Scott W Brim'" <sbrim@cisco.com>,
        pwe3@ietf.org, mpls@UU.NET
Subject: Re: [PWE3] MPLS PID 
In-reply-to: Your message of Thu, 27 Mar 2003 13:48:26 -0500.
             <FFFC48AEAA5F7447929F4F0D93FCC12D016D2BFF@zcard031.ca.nortel.com> 
Reply-To: erosen@cisco.com
User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3
 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2
 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 27 Mar 2003 14:03:25 -0500
From: Eric Rosen <erosen@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


David> You're not a student of OAM. 

Guilty as charged.   Perhaps the pid field needs  to identify three distinct
categories, IP, OAM, and other. 

David> load balancing limited to the label stack is also an option

That's not  very good if the  LSP payload consists  of a large number  of IP
microflows, which is highly likely. 



From owner-mpls@UU.NET  Thu Mar 27 18:22:48 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25311
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 18:22:48 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohws29790
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 22:40:42 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohws29275;
	Thu, 27 Mar 2003 22:40:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohwd05651
	for mpls-outgoing; Thu, 27 Mar 2003 18:51:22 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQohwd05641
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 18:51:11 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohwd06031
	for <mpls@UU.NET>; Thu, 27 Mar 2003 18:49:10 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwd28741
	for <mpls@UU.NET>; Thu, 27 Mar 2003 18:49:08 GMT
Received: from zcars0m9.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157])
	id QQohwd28653
	for <mpls@UU.NET>; Thu, 27 Mar 2003 18:49:02 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2RImTY09680;
	Thu, 27 Mar 2003 13:48:29 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <GDF486Z8>; Thu, 27 Mar 2003 13:48:29 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D016D2BFF@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'erosen@cisco.com'" <erosen@cisco.com>, jeremy.de_clercq@alcatel.be
Cc: "'Scott W Brim'" <sbrim@cisco.com>, pwe3@ietf.org, mpls@UU.NET
Subject: RE: [PWE3] MPLS PID 
Date: Thu, 27 Mar 2003 13:48:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2F491.7343C372"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2F491.7343C372
Content-Type: text/plain;
	charset="iso-8859-1"

Eric:

> Let's try to focus a little. 
> 
> 1. The  only  reason for  a  PID  field in  MPLS  and/or PWE3  is to
allow
>    intermediate routers to determine whether a particular MPLS payload is
an
>    IP packet or not.

Actually at the moment it appears to be to stop ECMP implementations from
buggering non-IP flows. However sticking with having to use additional
labels to discriminate protocol flows or router alert or whatever gets
similarely broken by ECMP. A pid plus one or two bits obviates the need for
ALL reserved labels in order to perform the same functions. 

Seeing as folks were opposed to codifying things like not hashing reserved
labels and excluding the 's' bit in NHLFE selection in Atlanta, adding the
option of an extended label with a PID and some control bits looks very
attractive.
 
> 
>    There are a number  of reasons why this is useful, and  no one has
argued
>    that this is not useful. 
> 
>    No one  has provided  a reason  why it might  be useful for
intermediate
>    routers to know, if the payload is not IP, what kind of packet it is.

You're not a student of OAM. Tom's VCCV stuff and my guidelines draft are
all about trying to carry protocols across the network without having ECMP
'exceed its mandate'....Some of us would love to have segment OAM ability as
well.
  
> 
> 2. The reason there is  no PID field in the MPLS header  is that there was
a
>    consensus to keep the header as short as possible.

And that's wonderful for the high running case (v4/v6), beyond that having
to use another 32 bits exclusively as a PID is not that efficient.

> 
> 3. The reason the PWE3 control word is optional is that there is a
consensus
>    (apparently a continuing one) to  allow service providers to specify
that
>    the header be kept as short as possible. 
> 
> 4. My conclusion from 2 and 3 is that there isn't much hope for any
solution
>    which includes both a PWE3 control word AND a 4-byte MPLS PID field.

I'm certainly not suggesting that.
 
> 
> 5. There is anyway  no way for the IETF to change  the basic MPLS
forwarding
>    logic, at least  not in the time  frame over which one would  like to
see
>    PWE3 deployments.

Don't think anyone is suggesting that either.

> 6. No one has given  a reason why the first nibble of  any such control
word
>    should not be as Stewart has proposed.

Except that it breaks some implementations that may have 0x04 in the first
nybble without being IP packets.


> 7. The PWE3 control word can be specified as a mandatory-to-implement
option
>    which a SP  can disable if his environment is such  he doesn't care
about
>    the absence of the PID. 

> So I really think there is only one possible outcome.  The only issue is
how much time  and breath we want  to waste  
> until we  get there.  A  SP is faced with the choice of either:

> a. Requiring the use of a Martini-style PID, or 

> b. Ensuring that his pseudowires only carry non-order-sensitive traffic,
or

> c. Ensuring that  his PWE3 packets do not pass  through any MPLS
environment
>    in which IP payload based load balancing is done. 
		  ^^^^^^^^^^^^^^^^

d. load balancing limited to the label stack is also an option, having an
alternative to reserved labels for LSP specific functions works even
better.....esp. w.r.t. the genie already out there

Dave







------_=_NextPart_001_01C2F491.7343C372
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [PWE3] MPLS PID </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Eric:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Let's try to focus a little. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 1. The&nbsp; only&nbsp; reason for&nbsp; =
a&nbsp; PID&nbsp; field in&nbsp; MPLS&nbsp; and/or PWE3&nbsp; is =
to&nbsp; allow</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; intermediate routers to =
determine whether a particular MPLS payload is an</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; IP packet or not.</FONT>
</P>

<P><FONT SIZE=3D2>Actually at the moment it appears to be to stop ECMP =
implementations from buggering non-IP flows. However sticking with =
having to use additional labels to discriminate protocol flows or =
router alert or whatever gets similarely broken by ECMP. A pid plus one =
or two bits obviates the need for ALL reserved labels in order to =
perform the same functions. </FONT></P>

<P><FONT SIZE=3D2>Seeing as folks were opposed to codifying things like =
not hashing reserved labels and excluding the 's' bit in NHLFE =
selection in Atlanta, adding the option of an extended label with a PID =
and some control bits looks very attractive.</FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; There are a number&nbsp; of =
reasons why this is useful, and&nbsp; no one has argued</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; that this is not useful. =
</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; No one&nbsp; has =
provided&nbsp; a reason&nbsp; why it might&nbsp; be useful for =
intermediate</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; routers to know, if the =
payload is not IP, what kind of packet it is.</FONT>
</P>

<P><FONT SIZE=3D2>You're not a student of OAM. Tom's VCCV stuff and my =
guidelines draft are all about trying to carry protocols across the =
network without having ECMP 'exceed its mandate'....Some of us would =
love to have segment OAM ability as well.</FONT></P>

<P><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 2. The reason there is&nbsp; no PID field in =
the MPLS header&nbsp; is that there was a</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; consensus to keep the header =
as short as possible.</FONT>
</P>

<P><FONT SIZE=3D2>And that's wonderful for the high running case =
(v4/v6), beyond that having to use another 32 bits exclusively as a PID =
is not that efficient.</FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 3. The reason the PWE3 control word is optional =
is that there is a consensus</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; (apparently a continuing one) =
to&nbsp; allow service providers to specify that</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; the header be kept as short =
as possible. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 4. My conclusion from 2 and 3 is that there =
isn't much hope for any solution</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; which includes both a PWE3 =
control word AND a 4-byte MPLS PID field.</FONT>
</P>

<P><FONT SIZE=3D2>I'm certainly not suggesting that.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 5. There is anyway&nbsp; no way for the IETF to =
change&nbsp; the basic MPLS forwarding</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; logic, at least&nbsp; not in =
the time&nbsp; frame over which one would&nbsp; like to see</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; PWE3 deployments.</FONT>
</P>

<P><FONT SIZE=3D2>Don't think anyone is suggesting that either.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; 6. No one has given&nbsp; a reason why the first =
nibble of&nbsp; any such control word</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; should not be as Stewart has =
proposed.</FONT>
</P>

<P><FONT SIZE=3D2>Except that it breaks some implementations that may =
have 0x04 in the first nybble without being IP packets.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; 7. The PWE3 control word can be specified as a =
mandatory-to-implement option</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; which a SP&nbsp; can disable =
if his environment is such&nbsp; he doesn't care about</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; the absence of the PID. =
</FONT>
</P>

<P><FONT SIZE=3D2>&gt; So I really think there is only one possible =
outcome.&nbsp; The only issue is how much time&nbsp; and breath we =
want&nbsp; to waste&nbsp; </FONT></P>

<P><FONT SIZE=3D2>&gt; until we&nbsp; get there.&nbsp; A&nbsp; SP is =
faced with the choice of either:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; a. Requiring the use of a Martini-style PID, or =
</FONT>
</P>

<P><FONT SIZE=3D2>&gt; b. Ensuring that his pseudowires only carry =
non-order-sensitive traffic, or</FONT>
</P>

<P><FONT SIZE=3D2>&gt; c. Ensuring that&nbsp; his PWE3 packets do not =
pass&nbsp; through any MPLS environment</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; in which IP payload based =
load balancing is done. </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>&nbsp; =
^^^^^^^^^^^^^^^^</FONT>
</P>

<P><FONT SIZE=3D2>d. load balancing limited to the label stack is also =
an option, having an alternative to reserved labels for LSP specific =
functions works even better.....esp. w.r.t. the genie already out =
there</FONT></P>

<P><FONT SIZE=3D2>Dave</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C2F491.7343C372--


From owner-mpls@UU.NET  Thu Mar 27 18:23:08 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25342
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 18:23:08 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwv18996
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 23:25:29 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohwv16728;
	Thu, 27 Mar 2003 23:24:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohwe26152
	for mpls-outgoing; Thu, 27 Mar 2003 19:12:26 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQohwe25960
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 19:12:19 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohwe07535
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:11:42 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwe22190
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:11:40 GMT
Received: from zcars0m9.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157])
	id QQohwe22135
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:11:38 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2RJAqY18209;
	Thu, 27 Mar 2003 14:10:52 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <GDF487NA>; Thu, 27 Mar 2003 14:10:52 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D016D2C00@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'Ferrell, William'" <William.Ferrell@titan.com>,
        "'Naidu, Venkata'"
	 <Venkata.Naidu@Marconi.com>,
        "'Shahram Davari'"
	 <Shahram_Davari@pmc-sierra.com>,
        "'curtis@fictitious.org'"
	 <curtis@fictitious.org>
Cc: "'Thomas D. Nadeau'" <tnadeau@lucidvision.com>,
        "'George Swallow'"
	 <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'"
	 <mpls@UU.NET>, tnadeau@cisco.com
Subject: RE: [PWE3] MPLS PID 
Date: Thu, 27 Mar 2003 14:10:45 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2F494.90D96F42"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2F494.90D96F42
Content-Type: text/plain;
	charset="iso-8859-1"

Hang on....

Using CRC as a sanity check (ensuring somthing starting with 0x04 is
actually an IP packet) prior to load balancing is the suggestion, an
imperfect improvement assuming the first nybble cannot be completely trusted
as authoritative indication of payload type. Suggesting that it is then
vulnerable to malicious attacks is a non-sequitor. The goal is to avoid
misordering flows across the network. A rogue packet is a flow unto itself
and would only impact its neighbors if load spreading was somehow stateful.

Did I miss somthing?
Dave



> -----Original Message-----
> From: Ferrell, William [mailto:William.Ferrell@titan.com] 
> Sent: Thursday, March 27, 2003 12:34 PM
> To: 'Naidu, Venkata'; 'Shahram Davari'; 'curtis@fictitious.org'
> Cc: 'Thomas D. Nadeau'; 'George Swallow'; W. Mark Townsley; 
> Andrew G. Malis; 'mpls@uu.net'; tnadeau@cisco.com
> Subject: RE: [PWE3] MPLS PID 
> 
> 
> I tend to agree , useing the CRC is one of the oldest and 
> proven methods but is one of the easiest to subvert and 
> corrupt. When developing the protocol one has to keep in mind 
> of a way of integrating a security solution. oftens we've put 
> in a functional solution and then been forced change/modify 
> it to fit with a security option and ending up with a less 
> effective product in the end. Will
> 
> -----Original Message-----
> From: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com]
> Sent: Thursday, March 27, 2003 12:12 PM
> To: 'Shahram Davari'; 'curtis@fictitious.org'
> Cc: 'Thomas D. Nadeau'; 'George Swallow'; W. Mark Townsley; 
> Andrew G. Malis; 'mpls@uu.net'; tnadeau@cisco.com
> Subject: RE: [PWE3] MPLS PID 
> 
> 
> Shahram,
> 
> -> First of all I meant computing CRC over the first 20 byte of
> -> payload header
> -> and comparing it to the suspected IP CRC in octets 11 and 12 
> -> of the payload.
> -> If they match then it is IPv4, if not it is something else 
> -> (similar procedure for IPv6)
> -> 
> -> Secondly I am proposing it now. Is there a problem?
> 
>   Yes. There is a problem. First of all relaying on CRC to
>   figure out the *type* of payload is not at all advisable.
>   One could produce (there is a remote possibility) a payload
>   which is not IPv4 or IPv6 but the CRC can be matched to
>   the payload of first 20 bytes to the bytes in 11 & 12.
> 
>   RFC1071 uses 16 bit's one's compliment, which we all know
>   that won't catch all the bit errors/flips.
> 
> Venkata.
> 

------_=_NextPart_001_01C2F494.90D96F42
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [PWE3] MPLS PID </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hang on....</FONT>
</P>

<P><FONT SIZE=3D2>Using CRC as a sanity check (ensuring somthing =
starting with 0x04 is actually an IP packet) prior to load balancing is =
the suggestion, an imperfect improvement assuming the first nybble =
cannot be completely trusted as authoritative indication of payload =
type. Suggesting that it is then vulnerable to malicious attacks is a =
non-sequitor. The goal is to avoid misordering flows across the =
network. A rogue packet is a flow unto itself and would only impact its =
neighbors if load spreading was somehow stateful.</FONT></P>

<P><FONT SIZE=3D2>Did I miss somthing?</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Ferrell, William [<A =
HREF=3D"mailto:William.Ferrell@titan.com">mailto:William.Ferrell@titan.c=
om</A>] </FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, March 27, 2003 12:34 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'Naidu, Venkata'; 'Shahram Davari'; =
'curtis@fictitious.org'</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'Thomas D. Nadeau'; 'George Swallow'; W. =
Mark Townsley; </FONT>
<BR><FONT SIZE=3D2>&gt; Andrew G. Malis; 'mpls@uu.net'; =
tnadeau@cisco.com</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [PWE3] MPLS PID </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I tend to agree , useing the CRC is one of the =
oldest and </FONT>
<BR><FONT SIZE=3D2>&gt; proven methods but is one of the easiest to =
subvert and </FONT>
<BR><FONT SIZE=3D2>&gt; corrupt. When developing the protocol one has =
to keep in mind </FONT>
<BR><FONT SIZE=3D2>&gt; of a way of integrating a security solution. =
oftens we've put </FONT>
<BR><FONT SIZE=3D2>&gt; in a functional solution and then been forced =
change/modify </FONT>
<BR><FONT SIZE=3D2>&gt; it to fit with a security option and ending up =
with a less </FONT>
<BR><FONT SIZE=3D2>&gt; effective product in the end. Will</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Naidu, Venkata [<A =
HREF=3D"mailto:Venkata.Naidu@Marconi.com">mailto:Venkata.Naidu@Marconi.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, March 27, 2003 12:12 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'Shahram Davari'; =
'curtis@fictitious.org'</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'Thomas D. Nadeau'; 'George Swallow'; W. =
Mark Townsley; </FONT>
<BR><FONT SIZE=3D2>&gt; Andrew G. Malis; 'mpls@uu.net'; =
tnadeau@cisco.com</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [PWE3] MPLS PID </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Shahram,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -&gt; First of all I meant computing CRC over =
the first 20 byte of</FONT>
<BR><FONT SIZE=3D2>&gt; -&gt; payload header</FONT>
<BR><FONT SIZE=3D2>&gt; -&gt; and comparing it to the suspected IP CRC =
in octets 11 and 12 </FONT>
<BR><FONT SIZE=3D2>&gt; -&gt; of the payload.</FONT>
<BR><FONT SIZE=3D2>&gt; -&gt; If they match then it is IPv4, if not it =
is something else </FONT>
<BR><FONT SIZE=3D2>&gt; -&gt; (similar procedure for IPv6)</FONT>
<BR><FONT SIZE=3D2>&gt; -&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -&gt; Secondly I am proposing it now. Is there =
a problem?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; Yes. There is a problem. First of =
all relaying on CRC to</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; figure out the *type* of payload is =
not at all advisable.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; One could produce (there is a =
remote possibility) a payload</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; which is not IPv4 or IPv6 but the =
CRC can be matched to</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; the payload of first 20 bytes to =
the bytes in 11 &amp; 12.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; RFC1071 uses 16 bit's one's =
compliment, which we all know</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; that won't catch all the bit =
errors/flips.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Venkata.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2F494.90D96F42--


From owner-mpls@UU.NET  Thu Mar 27 18:23:22 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25386
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 18:23:22 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwv19483
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 23:25:42 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohwv11584;
	Thu, 27 Mar 2003 23:22:15 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohwe26166
	for mpls-outgoing; Thu, 27 Mar 2003 19:12:45 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohwe26156
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 19:12:29 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohwe03305
	for <mpls@uu.net>; Thu, 27 Mar 2003 19:12:06 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwe15748
	for <mpls@uu.net>; Thu, 27 Mar 2003 19:12:06 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohwe15730
	for <mpls@uu.net>; Thu, 27 Mar 2003 19:12:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2RJC2iH006324
	for <mpls@uu.net>; Thu, 27 Mar 2003 14:12:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA06128 for <mpls@uu.net>; Thu, 27 Mar 2003 14:12:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2RJC2A12752 for mpls@uu.net; Thu, 27 Mar 2003 14:12:02 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohwe25438
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 19:10:26 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohwe24539
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:09:47 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwe10849
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:09:46 GMT
Received: from father.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: father.pmc-sierra.com [216.241.224.13])
	id QQohwe10805
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:09:45 GMT
Received: (qmail 6464 invoked by uid 104); 27 Mar 2003 19:09:44 -0000
Received: from Shahram_Davari@pmc-sierra.com by father by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4254.  Clear:. 
 Processed in 0.458964 secs); 27 Mar 2003 19:09:44 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by father.pmc-sierra.com with SMTP; 27 Mar 2003 19:09:43 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h2RJ8j623373;
	Thu, 27 Mar 2003 11:08:45 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <DCP443P6>; Thu, 27 Mar 2003 11:08:45 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115C847@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'erosen@cisco.com'" <erosen@cisco.com>
Cc: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "'Thomas D. Nadeau'" <tnadeau@lucidvision.com>,
        "'George Swallow'"
	 <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'"
	 <mpls@UU.NET>, tnadeau@cisco.com
Subject: RE: [PWE3] MPLS PID 
Date: Thu, 27 Mar 2003 11:08:44 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

>Shahram> my proposal superior in terms of probability of false 
>positives,
>
>Only in  the absence of  the control word.   In the presence 
>of  the control
>word, there are no false positives. 

Wrong. Have a look at SONET/SDH PW control word.


>
>Shahram> Checksum is easy and is done all the time in routers
>
>For IPv4  packets, but for non-IPv4  packets, this is extra  
>work that would
>not otherwise need  to be done.  Extra code too (gates  or 
>microcode), as it
>would happen  in a different  forwarding path than  that used 
>for  IPv4, and
>microcoders and hardware designers are not very big on calling 
>subroutines.

Checksum has been designed to be simple so that it can be implemented in software.
But still my argument is mostly about false positives which is a much important
issue. 

-Shahram



From owner-mpls@UU.NET  Thu Mar 27 18:32:08 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25893
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 18:32:08 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohww05847
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 23:34:25 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohww04060;
	Thu, 27 Mar 2003 23:33:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohwg27555
	for mpls-outgoing; Thu, 27 Mar 2003 19:30:37 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQohwg27548
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 19:30:22 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohwf01793
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:29:19 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwf26206
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:29:19 GMT
Received: from thurn.corp.titan.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: thurn.corp.titan.com [159.62.51.20])
	id QQohwf26186
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:29:18 GMT
Received: from vcmd-nt1.validity.com (val114-005.validity.titan.com [159.62.114.5])
	by thurn.corp.titan.com (8.12.8/8.12.8) with ESMTP id h2RJSarF004645;
	Thu, 27 Mar 2003 11:28:37 -0800
Received: by VCMD-NT1 with Internet Mail Service (5.5.2655.55)
	id <HYNAVHW0>; Thu, 27 Mar 2003 14:27:52 -0500
Message-ID: <561621C69F17D511A3A20050047340EC01AAF649@VCMD-NT1>
From: "Ferrell, William" <William.Ferrell@titan.com>
To: "'erosen@cisco.com'" <erosen@cisco.com>,
        Shahram Davari
	 <Shahram_Davari@pmc-sierra.com>
Cc: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "'Thomas D. Nadeau'" <tnadeau@lucidvision.com>,
        "'George Swallow'"
	 <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'"
	 <mpls@UU.NET>, tnadeau@cisco.com
Subject: RE: [PWE3] MPLS PID 
Date: Thu, 27 Mar 2003 14:27:45 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk


Sorry , I had to check my dictionary.....In laymans terms.... 

Im not saying that the proposal will not work.(this is a forum for different
ideas) I agree that checksums are used all of the time. My issues are the
overhead on the router and with the common use of checksums and its known
expoitability. If we implement another protocol on a proven fallible
technology then how does that improve the overall secure footprint of our
traffic. Again operationally I think that the solution will work , that does
not account for overt and malicious use/misues. From comprehensive
perspective this may create another wider avenue for exploitation, we should
simply consider that in the planning stages.
Will

-----Original Message-----
From: Eric Rosen [mailto:erosen@cisco.com]
Sent: Thursday, March 27, 2003 2:00 PM
To: Shahram Davari
Cc: 'curtis@fictitious.org'; 'Thomas D. Nadeau'; 'George Swallow'; W.
Mark Townsley; Andrew G. Malis; 'mpls@uu.net'; tnadeau@cisco.com
Subject: Re: [PWE3] MPLS PID 



Shahram> my proposal superior in terms of probability of false positives,

Only in  the absence of  the control word.   In the presence of  the control
word, there are no false positives. 

Shahram> Checksum is easy and is done all the time in routers

For IPv4  packets, but for non-IPv4  packets, this is extra  work that would
not otherwise need  to be done.  Extra code too (gates  or microcode), as it
would happen  in a different  forwarding path than  that used for  IPv4, and
microcoders and hardware designers are not very big on calling subroutines. 




From owner-mpls@UU.NET  Thu Mar 27 18:32:27 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25913
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 18:32:27 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohww06606
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 23:34:44 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohww03979;
	Thu, 27 Mar 2003 23:33:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohwg27729
	for mpls-outgoing; Thu, 27 Mar 2003 19:31:24 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohwg27565
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 19:30:56 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohwf21827
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:29:43 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwf26938
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:29:42 GMT
Received: from thurn.corp.titan.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: thurn.corp.titan.com [159.62.51.20])
	id QQohwf26904
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:29:41 GMT
Received: from vcmd-nt1.validity.com (val114-005.validity.titan.com [159.62.114.5])
	by thurn.corp.titan.com (8.12.8/8.12.8) with ESMTP id h2RJTQrF004706;
	Thu, 27 Mar 2003 11:29:27 -0800
Received: by VCMD-NT1 with Internet Mail Service (5.5.2655.55)
	id <HYNAVHXA>; Thu, 27 Mar 2003 14:28:42 -0500
Message-ID: <561621C69F17D511A3A20050047340EC01AAF64A@VCMD-NT1>
From: "Ferrell, William" <William.Ferrell@titan.com>
To: "'Thomas D. Nadeau'" <tnadeau@cisco.com>,
        Shahram Davari
	 <Shahram_Davari@pmc-sierra.com>,
        "'curtis@fictitious.org'"
	 <curtis@fictitious.org>
Cc: "'Thomas D. Nadeau'" <tnadeau@lucidvision.com>,
        "'George Swallow'"
	 <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'"
	 <mpls@UU.NET>
Subject: RE: [PWE3] MPLS PID 
Date: Thu, 27 Mar 2003 14:28:41 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk


Tom 
Kludge indeed 
Will

-----Original Message-----
From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
Sent: Thursday, March 27, 2003 1:56 PM
To: Shahram Davari; 'curtis@fictitious.org'
Cc: 'Thomas D. Nadeau'; 'George Swallow'; W. Mark Townsley; Andrew G.
Malis; 'mpls@uu.net'
Subject: RE: [PWE3] MPLS PID 



> >I don't feel obligated to answer nonsense questions.  No one has
> >proposed putting a CRC in the PID.
>
>First of all I meant computing CRC over the first 20 byte of payload header
>and comparing it to the suspected IP CRC in octets 11 and 12 of the
payload.
>If they match then it is IPv4, if not it is something else (similar 
>procedure for IPv6)

         Doesn't this seem like a bit of a kludge that is prone to
potential errors?

         --Tom


>Secondly I am proposing it now. Is there a problem? I feel my procedure is 
>far superior to just checking 4 bits to decide whether the payload is IP 
>or not.
>
> >
> >Curtis
> >
> >ps - "requiring [..] not to produce a valid CRC" doesn't even parse in
> >english so your question is complete nonsense.
>
>
>It makes perfect sense if you understand my proposal. I think you need to 
>talk to Alia, since she could parse it correctly :)
>
>-Shahram


http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X



From owner-mpls@UU.NET  Thu Mar 27 18:34:38 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25939
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 18:34:37 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohww04935
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 23:36:57 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohww03893;
	Thu, 27 Mar 2003 23:36:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohwg28512
	for mpls-outgoing; Thu, 27 Mar 2003 19:44:43 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohwg28503
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 19:44:33 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohwg01394
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:44:19 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwg28464
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:44:17 GMT
Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQohwg28439
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:44:16 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA17259;
	Thu, 27 Mar 2003 14:44:02 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA27258;
	Thu, 27 Mar 2003 14:44:03 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <HMVZDAX4>; Thu, 27 Mar 2003 14:44:03 -0500
Message-ID: <39469E08BD83D411A3D900204840EC55763572@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'David Allan'" <dallan@nortelnetworks.com>,
        "'Ferrell, William'"
	 <William.Ferrell@titan.com>,
        "'Shahram Davari'"
	 <Shahram_Davari@pmc-sierra.com>,
        "'curtis@fictitious.org'"
	 <curtis@fictitious.org>
Cc: "'Thomas D. Nadeau'" <tnadeau@lucidvision.com>,
        "'George Swallow'"
	 <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'"
	 <mpls@UU.NET>, tnadeau@cisco.com
Subject: RE: [PWE3] MPLS PID 
Date: Thu, 27 Mar 2003 14:44:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Dave,

-> Hang on.... 
-> Using CRC as a sanity check (ensuring somthing starting 
-> with 0x04 is actually an IP packet) prior to load balancing 
-> is the suggestion, an imperfect improvement assuming the 
-> first nybble cannot be completely trusted as authoritative 
-> indication of payload type. Suggesting that it is then 
-> vulnerable to malicious attacks is a non-sequitor. 

  More than malicious attacks, my strong objection is
  because of the approximations in the suggestion. If
  all that we want to achieve is to find the payload type
  then that should not be *guessed* by some approximations
  or probabilistic method. Propose something concrete to
  identify the payload type. In networking all such 
  approximation algorithms are called hacks. In the history
  there is such a hack called henk-hack already :-)

-> The goal is to avoid misordering flows across the network. 

  If that is the goal, why even to bother to find the payload
  type. Search for and reserve a bit (just a bit) - for example
  from EXP bits (if not used from Diffserv) - then ask the
  sender to set the bit as NL (no-load-balance bit). This acts
  just as good as Don't fragment (DF) bit in IP Header. But,
  I suppose that won't suffice for your requirement.

-> A rogue packet is a flow unto itself and would only 
-> impact its neighbors if load spreading was somehow stateful.

  If that is the case, we shouldn't have spent so much time 
  in security. The difficult thing is to find whether the 
  packet is *real-rogue* packet or *rogue packet relative to IP*

Venkata.


From owner-mpls@UU.NET  Thu Mar 27 18:34:47 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25959
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 18:34:46 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohww05494
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 23:37:08 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohww04786;
	Thu, 27 Mar 2003 23:36:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohwg28096
	for mpls-outgoing; Thu, 27 Mar 2003 19:37:05 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohwg28079
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 19:36:51 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohwg14761
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:36:28 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwg10663
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:36:27 GMT
Received: from thurn.corp.titan.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: thurn.corp.titan.com [159.62.51.20])
	id QQohwg10615
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:36:26 GMT
Received: from vcmd-nt1.validity.com (val114-005.validity.titan.com [159.62.114.5])
	by thurn.corp.titan.com (8.12.8/8.12.8) with ESMTP id h2RJZarF005345;
	Thu, 27 Mar 2003 11:35:37 -0800
Received: by VCMD-NT1 with Internet Mail Service (5.5.2655.55)
	id <HYNAVHXW>; Thu, 27 Mar 2003 14:34:51 -0500
Message-ID: <561621C69F17D511A3A20050047340EC01AAF64B@VCMD-NT1>
From: "Ferrell, William" <William.Ferrell@titan.com>
To: "'David Allan'" <dallan@nortelnetworks.com>,
        "'erosen@cisco.com'"
	 <erosen@cisco.com>, jeremy.de_clercq@alcatel.be
Cc: "'Scott W Brim'" <sbrim@cisco.com>, pwe3@ietf.org, mpls@UU.NET
Subject: RE: [PWE3] MPLS PID 
Date: Thu, 27 Mar 2003 14:34:44 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2F497.EB5D1420"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2F497.EB5D1420
Content-Type: text/plain;
	charset="iso-8859-1"

Dave 
That was a sound summary , but clarify why the exeption in #6 is so easily
ignored in your opinion.
will
6. No one has given  a reason why the first nibble of  any such control word

>    should not be as Stewart has proposed. 
Except that it breaks some implementations that may have 0x04 in the first
nybble without being IP packets. 

 

 

 

 

 

-----Original Message-----
From: David Allan [mailto:dallan@nortelnetworks.com]
Sent: Thursday, March 27, 2003 1:48 PM
To: 'erosen@cisco.com'; jeremy.de_clercq@alcatel.be
Cc: 'Scott W Brim'; pwe3@ietf.org; mpls@UU.NET
Subject: RE: [PWE3] MPLS PID 



Eric: 

> Let's try to focus a little. 
> 
> 1. The  only  reason for  a  PID  field in  MPLS  and/or PWE3  is to
allow 
>    intermediate routers to determine whether a particular MPLS payload is
an 
>    IP packet or not. 

Actually at the moment it appears to be to stop ECMP implementations from
buggering non-IP flows. However sticking with having to use additional
labels to discriminate protocol flows or router alert or whatever gets
similarely broken by ECMP. A pid plus one or two bits obviates the need for
ALL reserved labels in order to perform the same functions. 

Seeing as folks were opposed to codifying things like not hashing reserved
labels and excluding the 's' bit in NHLFE selection in Atlanta, adding the
option of an extended label with a PID and some control bits looks very
attractive.


> 
>    There are a number  of reasons why this is useful, and  no one has
argued 
>    that this is not useful. 
> 
>    No one  has provided  a reason  why it might  be useful for
intermediate 
>    routers to know, if the payload is not IP, what kind of packet it is. 

You're not a student of OAM. Tom's VCCV stuff and my guidelines draft are
all about trying to carry protocols across the network without having ECMP
'exceed its mandate'....Some of us would love to have segment OAM ability as
well.

  
> 
> 2. The reason there is  no PID field in the MPLS header  is that there was
a 
>    consensus to keep the header as short as possible. 

And that's wonderful for the high running case (v4/v6), beyond that having
to use another 32 bits exclusively as a PID is not that efficient.

> 
> 3. The reason the PWE3 control word is optional is that there is a
consensus 
>    (apparently a continuing one) to  allow service providers to specify
that 
>    the header be kept as short as possible. 
> 
> 4. My conclusion from 2 and 3 is that there isn't much hope for any
solution 
>    which includes both a PWE3 control word AND a 4-byte MPLS PID field. 

I'm certainly not suggesting that. 
  
> 
> 5. There is anyway  no way for the IETF to change  the basic MPLS
forwarding 
>    logic, at least  not in the time  frame over which one would  like to
see 
>    PWE3 deployments. 

Don't think anyone is suggesting that either. 

> 6. No one has given  a reason why the first nibble of  any such control
word 
>    should not be as Stewart has proposed. 

Except that it breaks some implementations that may have 0x04 in the first
nybble without being IP packets. 


> 7. The PWE3 control word can be specified as a mandatory-to-implement
option 
>    which a SP  can disable if his environment is such  he doesn't care
about 
>    the absence of the PID. 

> So I really think there is only one possible outcome.  The only issue is
how much time  and breath we want  to waste  

> until we  get there.  A  SP is faced with the choice of either: 

> a. Requiring the use of a Martini-style PID, or 

> b. Ensuring that his pseudowires only carry non-order-sensitive traffic,
or 

> c. Ensuring that  his PWE3 packets do not pass  through any MPLS
environment 
>    in which IP payload based load balancing is done. 
                  ^^^^^^^^^^^^^^^^ 

d. load balancing limited to the label stack is also an option, having an
alternative to reserved labels for LSP specific functions works even
better.....esp. w.r.t. the genie already out there

Dave 







------_=_NextPart_001_01C2F497.EB5D1420
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [PWE3] MPLS PID</TITLE>

<META content="MSHTML 5.50.4916.2300" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=565343319-27032003><FONT size=2>Dave </FONT></SPAN></DIV>
<DIV><SPAN class=565343319-27032003><FONT size=2>That was a sound summary , but 
clarify why the exeption in #6&nbsp;is so easily ignored&nbsp;in your 
opinion.</FONT></SPAN></DIV>
<DIV><SPAN class=565343319-27032003><FONT size=2>will</FONT></SPAN></DIV>
<DIV><FONT size=2>6. No one has given&nbsp; a reason why the first nibble 
of&nbsp; any such control word</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; 
should not be as Stewart has proposed.</FONT> </DIV>
<DIV><FONT size=2>Except that it breaks some implementations that may have 0x04 
in the first nybble without being IP packets.</FONT> </DIV>
<P><FONT size=2></FONT>&nbsp;</P>
<P><FONT size=2></FONT>&nbsp;</P>
<P><FONT size=2></FONT>&nbsp;</P>
<P><FONT size=2></FONT>&nbsp;</P>
<P><FONT size=2></FONT>&nbsp;</P>
<BLOCKQUOTE>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> David Allan 
  [mailto:dallan@nortelnetworks.com]<BR><B>Sent:</B> Thursday, March 27, 2003 
  1:48 PM<BR><B>To:</B> 'erosen@cisco.com'; 
  jeremy.de_clercq@alcatel.be<BR><B>Cc:</B> 'Scott W Brim'; pwe3@ietf.org; 
  mpls@UU.NET<BR><B>Subject:</B> RE: [PWE3] MPLS PID <BR><BR></FONT></DIV>
  <P><FONT size=2>Eric:</FONT> </P>
  <P><FONT size=2>&gt; Let's try to focus a little. </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; 1. The&nbsp; only&nbsp; reason for&nbsp; a&nbsp; 
  PID&nbsp; field in&nbsp; MPLS&nbsp; and/or PWE3&nbsp; is to&nbsp; allow</FONT> 
  <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; intermediate routers to determine 
  whether a particular MPLS payload is an</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp; IP packet or not.</FONT> </P>
  <P><FONT size=2>Actually at the moment it appears to be to stop ECMP 
  implementations from buggering non-IP flows. However sticking with having to 
  use additional labels to discriminate protocol flows or router alert or 
  whatever gets similarely broken by ECMP. A pid plus one or two bits obviates 
  the need for ALL reserved labels in order to perform the same functions. 
  </FONT></P>
  <P><FONT size=2>Seeing as folks were opposed to codifying things like not 
  hashing reserved labels and excluding the 's' bit in NHLFE selection in 
  Atlanta, adding the option of an extended label with a PID and some control 
  bits looks very attractive.</FONT></P>
  <P><FONT size=2></FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp; There are a number&nbsp; of reasons why this is 
  useful, and&nbsp; no one has argued</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp; that this is not useful. </FONT><BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; No one&nbsp; has 
  provided&nbsp; a reason&nbsp; why it might&nbsp; be useful for 
  intermediate</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; routers to know, 
  if the payload is not IP, what kind of packet it is.</FONT> </P>
  <P><FONT size=2>You're not a student of OAM. Tom's VCCV stuff and my 
  guidelines draft are all about trying to carry protocols across the network 
  without having ECMP 'exceed its mandate'....Some of us would love to have 
  segment OAM ability as well.</FONT></P>
  <P><FONT size=2>&nbsp; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; 2. The reason there is&nbsp; no PID field in the MPLS header&nbsp; 
  is that there was a</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; consensus 
  to keep the header as short as possible.</FONT> </P>
  <P><FONT size=2>And that's wonderful for the high running case (v4/v6), beyond 
  that having to use another 32 bits exclusively as a PID is not that 
  efficient.</FONT></P>
  <P><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 3. The reason the PWE3 
  control word is optional is that there is a consensus</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp; (apparently a continuing one) to&nbsp; allow 
  service providers to specify that</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp; the header be kept as short as possible. 
  </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 4. My conclusion 
  from 2 and 3 is that there isn't much hope for any solution</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp; which includes both a PWE3 control word AND a 
  4-byte MPLS PID field.</FONT> </P>
  <P><FONT size=2>I'm certainly not suggesting that.</FONT> <BR><FONT 
  size=2>&nbsp;</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 5. 
  There is anyway&nbsp; no way for the IETF to change&nbsp; the basic MPLS 
  forwarding</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; logic, at 
  least&nbsp; not in the time&nbsp; frame over which one would&nbsp; like to 
  see</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; PWE3 deployments.</FONT> 
  </P>
  <P><FONT size=2>Don't think anyone is suggesting that either.</FONT> </P>
  <P><FONT size=2>&gt; 6. No one has given&nbsp; a reason why the first nibble 
  of&nbsp; any such control word</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; 
  should not be as Stewart has proposed.</FONT> </P>
  <P><FONT size=2>Except that it breaks some implementations that may have 0x04 
  in the first nybble without being IP packets.</FONT> </P><BR>
  <P><FONT size=2>&gt; 7. The PWE3 control word can be specified as a 
  mandatory-to-implement option</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; 
  which a SP&nbsp; can disable if his environment is such&nbsp; he doesn't care 
  about</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; the absence of the PID. 
  </FONT></P>
  <P><FONT size=2>&gt; So I really think there is only one possible 
  outcome.&nbsp; The only issue is how much time&nbsp; and breath we want&nbsp; 
  to waste&nbsp; </FONT></P>
  <P><FONT size=2>&gt; until we&nbsp; get there.&nbsp; A&nbsp; SP is faced with 
  the choice of either:</FONT> </P>
  <P><FONT size=2>&gt; a. Requiring the use of a Martini-style PID, or 
  </FONT></P>
  <P><FONT size=2>&gt; b. Ensuring that his pseudowires only carry 
  non-order-sensitive traffic, or</FONT> </P>
  <P><FONT size=2>&gt; c. Ensuring that&nbsp; his PWE3 packets do not pass&nbsp; 
  through any MPLS environment</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; in 
  which IP payload based load balancing is done. 
  </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&nbsp; 
  ^^^^^^^^^^^^^^^^</FONT> </P>
  <P><FONT size=2>d. load balancing limited to the label stack is also an 
  option, having an alternative to reserved labels for LSP specific functions 
  works even better.....esp. w.r.t. the genie already out there</FONT></P>
  <P><FONT size=2>Dave</FONT> </P><BR><BR><BR><BR><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C2F497.EB5D1420--


From owner-mpls@UU.NET  Thu Mar 27 18:38:05 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26080
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 18:38:04 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohww18221
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 23:40:21 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohww16573;
	Thu, 27 Mar 2003 23:39:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohwi18006
	for mpls-outgoing; Thu, 27 Mar 2003 20:09:28 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohwi17945
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 20:09:13 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohwi09576
	for <mpls@UU.NET>; Thu, 27 Mar 2003 20:03:47 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwi25578
	for <mpls@UU.NET>; Thu, 27 Mar 2003 20:03:45 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohwi25500
	for <mpls@UU.NET>; Thu, 27 Mar 2003 20:03:40 GMT
Received: from cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2RK3HiH018084;
	Thu, 27 Mar 2003 15:03:17 -0500 (EST)
Message-Id: <200303272003.h2RK3HiH018084@rtp-core-1.cisco.com>
To: "Ferrell, William" <William.Ferrell@titan.com>
cc: "'David Allan'" <dallan@nortelnetworks.com>, jeremy.de_clercq@alcatel.be,
        "'Scott W Brim'" <sbrim@cisco.com>, pwe3@ietf.org, mpls@UU.NET
Subject: Re: [PWE3] MPLS PID 
In-reply-to: Your message of Thu, 27 Mar 2003 14:34:44 -0500.
             <561621C69F17D511A3A20050047340EC01AAF64B@VCMD-NT1> 
Reply-To: erosen@cisco.com
User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3
 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2
 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 27 Mar 2003 15:03:17 -0500
From: Eric Rosen <erosen@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


Eric> 6. No one has given a  reason why the first nibble of any such control
Eric>    word should not be as Stewart has proposed. 

David> Except that it breaks some  implementations that may have 0x04 in the
David> first nibble without being IP packets. 

Referring to implementations which don't use a martini control word? 

William> clarify  why  the exception  in  #6 is  so  easily  ignored in  your
William> opinion. 

Well, my company  does have implementations which omit  the control word, so
that's not it ;-)

We're in  a situation now in  which we have  things that don't work  so well
together (core routers doing ECMP  with MPLS, edge routers doing pseudowires
without a  martini control word).  If  we want everything  to work together,
something has to give, and it's not going to be something in the core ;-)




From owner-mpls@UU.NET  Thu Mar 27 18:38:52 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26112
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 18:38:52 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohww20283
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 23:41:12 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohww17343;
	Thu, 27 Mar 2003 23:39:59 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohwh29794
	for mpls-outgoing; Thu, 27 Mar 2003 19:59:33 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohwh29789
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 19:59:16 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohwh26477
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:58:20 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwh01862
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:58:16 GMT
Received: from zcars0m9.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157])
	id QQohwh01737
	for <mpls@UU.NET>; Thu, 27 Mar 2003 19:58:12 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2RJveY27021;
	Thu, 27 Mar 2003 14:57:40 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <GDF4884T>; Thu, 27 Mar 2003 14:57:40 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D016D2C02@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'Ferrell, William'" <William.Ferrell@titan.com>,
        "'erosen@cisco.com'"
	 <erosen@cisco.com>, jeremy.de_clercq@alcatel.be
Cc: "'Scott W Brim'" <sbrim@cisco.com>, pwe3@ietf.org, mpls@UU.NET
Subject: RE: [PWE3] MPLS PID 
Date: Thu, 27 Mar 2003 14:57:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2F49B.1CEA8A1A"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2F49B.1CEA8A1A
Content-Type: text/plain;
	charset="iso-8859-1"

Hi William:
 
I wouldn't describe it as easily ignored, what exists is mutually
incompatible protocol designs (which if I understand some of the comments
are both implemented and deployed). If I understand some of the comments
correctly, control word formats already exist that will misorder if IP
payload based ECMP is on.
 
Dave

-----Original Message-----
From: Ferrell, William [mailto:William.Ferrell@titan.com] 
Sent: Thursday, March 27, 2003 2:35 PM
To: Allan, David [CAR:NS00:EXCH]; 'erosen@cisco.com';
jeremy.de_clercq@alcatel.be
Cc: 'Scott W Brim'; pwe3@ietf.org; mpls@UU.NET
Subject: RE: [PWE3] MPLS PID 


Dave 
That was a sound summary , but clarify why the exeption in #6 is so easily
ignored in your opinion.
will
6. No one has given  a reason why the first nibble of  any such control word

>    should not be as Stewart has proposed. 
Except that it breaks some implementations that may have 0x04 in the first
nybble without being IP packets. 

 

 

 

 

 

-----Original Message-----
From: David Allan [mailto:dallan@nortelnetworks.com]
Sent: Thursday, March 27, 2003 1:48 PM
To: 'erosen@cisco.com'; jeremy.de_clercq@alcatel.be
Cc: 'Scott W Brim'; pwe3@ietf.org; mpls@UU.NET
Subject: RE: [PWE3] MPLS PID 



Eric: 

> Let's try to focus a little. 
> 
> 1. The  only  reason for  a  PID  field in  MPLS  and/or PWE3  is to
allow 
>    intermediate routers to determine whether a particular MPLS payload is
an 
>    IP packet or not. 

Actually at the moment it appears to be to stop ECMP implementations from
buggering non-IP flows. However sticking with having to use additional
labels to discriminate protocol flows or router alert or whatever gets
similarely broken by ECMP. A pid plus one or two bits obviates the need for
ALL reserved labels in order to perform the same functions. 

Seeing as folks were opposed to codifying things like not hashing reserved
labels and excluding the 's' bit in NHLFE selection in Atlanta, adding the
option of an extended label with a PID and some control bits looks very
attractive.


> 
>    There are a number  of reasons why this is useful, and  no one has
argued 
>    that this is not useful. 
> 
>    No one  has provided  a reason  why it might  be useful for
intermediate 
>    routers to know, if the payload is not IP, what kind of packet it is. 

You're not a student of OAM. Tom's VCCV stuff and my guidelines draft are
all about trying to carry protocols across the network without having ECMP
'exceed its mandate'....Some of us would love to have segment OAM ability as
well.

  
> 
> 2. The reason there is  no PID field in the MPLS header  is that there was
a 
>    consensus to keep the header as short as possible. 

And that's wonderful for the high running case (v4/v6), beyond that having
to use another 32 bits exclusively as a PID is not that efficient.

> 
> 3. The reason the PWE3 control word is optional is that there is a
consensus 
>    (apparently a continuing one) to  allow service providers to specify
that 
>    the header be kept as short as possible. 
> 
> 4. My conclusion from 2 and 3 is that there isn't much hope for any
solution 
>    which includes both a PWE3 control word AND a 4-byte MPLS PID field. 

I'm certainly not suggesting that. 
  
> 
> 5. There is anyway  no way for the IETF to change  the basic MPLS
forwarding 
>    logic, at least  not in the time  frame over which one would  like to
see 
>    PWE3 deployments. 

Don't think anyone is suggesting that either. 

> 6. No one has given  a reason why the first nibble of  any such control
word 
>    should not be as Stewart has proposed. 

Except that it breaks some implementations that may have 0x04 in the first
nybble without being IP packets. 


> 7. The PWE3 control word can be specified as a mandatory-to-implement
option 
>    which a SP  can disable if his environment is such  he doesn't care
about 
>    the absence of the PID. 

> So I really think there is only one possible outcome.  The only issue is
how much time  and breath we want  to waste  

> until we  get there.  A  SP is faced with the choice of either: 

> a. Requiring the use of a Martini-style PID, or 

> b. Ensuring that his pseudowires only carry non-order-sensitive traffic,
or 

> c. Ensuring that  his PWE3 packets do not pass  through any MPLS
environment 
>    in which IP payload based load balancing is done. 
                  ^^^^^^^^^^^^^^^^ 

d. load balancing limited to the label stack is also an option, having an
alternative to reserved labels for LSP specific functions works even
better.....esp. w.r.t. the genie already out there

Dave 







------_=_NextPart_001_01C2F49B.1CEA8A1A
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>Message</TITLE>

<META content="MSHTML 5.50.4919.2200" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=010083819-27032003><FONT face=Arial color=#0000ff size=2>Hi 
William:</FONT></SPAN></DIV>
<DIV><SPAN class=010083819-27032003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=010083819-27032003><FONT face=Arial color=#0000ff size=2>I 
wouldn't describe it as easily ignored, what exists is mutually incompatible 
protocol&nbsp;designs (which if I understand some of the comments are both 
implemented and deployed). If I understand some of the comments correctly, 
control word formats already exist that will misorder if IP payload based ECMP 
is on.</FONT></SPAN></DIV>
<DIV><SPAN class=010083819-27032003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=010083819-27032003><FONT face=Arial color=#0000ff 
size=2>Dave</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT 
  face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Ferrell, William 
  [mailto:William.Ferrell@titan.com] <BR><B>Sent:</B> Thursday, March 27, 2003 
  2:35 PM<BR><B>To:</B> Allan, David [CAR:NS00:EXCH]; 'erosen@cisco.com'; 
  jeremy.de_clercq@alcatel.be<BR><B>Cc:</B> 'Scott W Brim'; pwe3@ietf.org; 
  mpls@UU.NET<BR><B>Subject:</B> RE: [PWE3] MPLS PID <BR><BR></FONT></DIV>
  <DIV><SPAN class=565343319-27032003><FONT size=2>Dave </FONT></SPAN></DIV>
  <DIV><SPAN class=565343319-27032003><FONT size=2>That was a sound summary , 
  but clarify why the exeption in #6&nbsp;is so easily ignored&nbsp;in your 
  opinion.</FONT></SPAN></DIV>
  <DIV><SPAN class=565343319-27032003><FONT size=2>will</FONT></SPAN></DIV>
  <DIV><FONT size=2>6. No one has given&nbsp; a reason why the first nibble 
  of&nbsp; any such control word</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; 
  should not be as Stewart has proposed.</FONT> </DIV>
  <DIV><FONT size=2>Except that it breaks some implementations that may have 
  0x04 in the first nybble without being IP packets.</FONT> </DIV>
  <P><FONT size=2></FONT>&nbsp;</P>
  <P><FONT size=2></FONT>&nbsp;</P>
  <P><FONT size=2></FONT>&nbsp;</P>
  <P><FONT size=2></FONT>&nbsp;</P>
  <P><FONT size=2></FONT>&nbsp;</P>
  <BLOCKQUOTE>
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> David Allan 
    [mailto:dallan@nortelnetworks.com]<BR><B>Sent:</B> Thursday, March 27, 2003 
    1:48 PM<BR><B>To:</B> 'erosen@cisco.com'; 
    jeremy.de_clercq@alcatel.be<BR><B>Cc:</B> 'Scott W Brim'; pwe3@ietf.org; 
    mpls@UU.NET<BR><B>Subject:</B> RE: [PWE3] MPLS PID <BR><BR></FONT></DIV>
    <P><FONT size=2>Eric:</FONT> </P>
    <P><FONT size=2>&gt; Let's try to focus a little. </FONT><BR><FONT 
    size=2>&gt; </FONT><BR><FONT size=2>&gt; 1. The&nbsp; only&nbsp; reason 
    for&nbsp; a&nbsp; PID&nbsp; field in&nbsp; MPLS&nbsp; and/or PWE3&nbsp; is 
    to&nbsp; allow</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; intermediate 
    routers to determine whether a particular MPLS payload is an</FONT> 
    <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; IP packet or not.</FONT> </P>
    <P><FONT size=2>Actually at the moment it appears to be to stop ECMP 
    implementations from buggering non-IP flows. However sticking with having to 
    use additional labels to discriminate protocol flows or router alert or 
    whatever gets similarely broken by ECMP. A pid plus one or two bits obviates 
    the need for ALL reserved labels in order to perform the same functions. 
    </FONT></P>
    <P><FONT size=2>Seeing as folks were opposed to codifying things like not 
    hashing reserved labels and excluding the 's' bit in NHLFE selection in 
    Atlanta, adding the option of an extended label with a PID and some control 
    bits looks very attractive.</FONT></P>
    <P><FONT size=2></FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt;&nbsp;&nbsp;&nbsp; There are a number&nbsp; of reasons why this 
    is useful, and&nbsp; no one has argued</FONT> <BR><FONT 
    size=2>&gt;&nbsp;&nbsp;&nbsp; that this is not useful. </FONT><BR><FONT 
    size=2>&gt; </FONT><BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; No one&nbsp; has 
    provided&nbsp; a reason&nbsp; why it might&nbsp; be useful for 
    intermediate</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; routers to know, 
    if the payload is not IP, what kind of packet it is.</FONT> </P>
    <P><FONT size=2>You're not a student of OAM. Tom's VCCV stuff and my 
    guidelines draft are all about trying to carry protocols across the network 
    without having ECMP 'exceed its mandate'....Some of us would love to have 
    segment OAM ability as well.</FONT></P>
    <P><FONT size=2>&nbsp; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; 2. The reason there is&nbsp; no PID field in the MPLS 
    header&nbsp; is that there was a</FONT> <BR><FONT 
    size=2>&gt;&nbsp;&nbsp;&nbsp; consensus to keep the header as short as 
    possible.</FONT> </P>
    <P><FONT size=2>And that's wonderful for the high running case (v4/v6), 
    beyond that having to use another 32 bits exclusively as a PID is not that 
    efficient.</FONT></P>
    <P><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 3. The reason the PWE3 
    control word is optional is that there is a consensus</FONT> <BR><FONT 
    size=2>&gt;&nbsp;&nbsp;&nbsp; (apparently a continuing one) to&nbsp; allow 
    service providers to specify that</FONT> <BR><FONT 
    size=2>&gt;&nbsp;&nbsp;&nbsp; the header be kept as short as possible. 
    </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 4. My conclusion 
    from 2 and 3 is that there isn't much hope for any solution</FONT> <BR><FONT 
    size=2>&gt;&nbsp;&nbsp;&nbsp; which includes both a PWE3 control word AND a 
    4-byte MPLS PID field.</FONT> </P>
    <P><FONT size=2>I'm certainly not suggesting that.</FONT> <BR><FONT 
    size=2>&nbsp;</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 5. 
    There is anyway&nbsp; no way for the IETF to change&nbsp; the basic MPLS 
    forwarding</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; logic, at 
    least&nbsp; not in the time&nbsp; frame over which one would&nbsp; like to 
    see</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; PWE3 deployments.</FONT> 
    </P>
    <P><FONT size=2>Don't think anyone is suggesting that either.</FONT> </P>
    <P><FONT size=2>&gt; 6. No one has given&nbsp; a reason why the first nibble 
    of&nbsp; any such control word</FONT> <BR><FONT 
    size=2>&gt;&nbsp;&nbsp;&nbsp; should not be as Stewart has proposed.</FONT> 
    </P>
    <P><FONT size=2>Except that it breaks some implementations that may have 
    0x04 in the first nybble without being IP packets.</FONT> </P><BR>
    <P><FONT size=2>&gt; 7. The PWE3 control word can be specified as a 
    mandatory-to-implement option</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; 
    which a SP&nbsp; can disable if his environment is such&nbsp; he doesn't 
    care about</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; the absence of the 
    PID. </FONT></P>
    <P><FONT size=2>&gt; So I really think there is only one possible 
    outcome.&nbsp; The only issue is how much time&nbsp; and breath we 
    want&nbsp; to waste&nbsp; </FONT></P>
    <P><FONT size=2>&gt; until we&nbsp; get there.&nbsp; A&nbsp; SP is faced 
    with the choice of either:</FONT> </P>
    <P><FONT size=2>&gt; a. Requiring the use of a Martini-style PID, or 
    </FONT></P>
    <P><FONT size=2>&gt; b. Ensuring that his pseudowires only carry 
    non-order-sensitive traffic, or</FONT> </P>
    <P><FONT size=2>&gt; c. Ensuring that&nbsp; his PWE3 packets do not 
    pass&nbsp; through any MPLS environment</FONT> <BR><FONT 
    size=2>&gt;&nbsp;&nbsp;&nbsp; in which IP payload based load balancing is 
    done. </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>&nbsp; 
    ^^^^^^^^^^^^^^^^</FONT> </P>
    <P><FONT size=2>d. load balancing limited to the label stack is also an 
    option, having an alternative to reserved labels for LSP specific functions 
    works even better.....esp. w.r.t. the genie already out there</FONT></P>
    <P><FONT size=2>Dave</FONT> 
</P><BR><BR><BR><BR><BR></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C2F49B.1CEA8A1A--


From owner-mpls@UU.NET  Thu Mar 27 18:40:44 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26150
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 18:40:44 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohww11472
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 23:43:03 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohww09536;
	Thu, 27 Mar 2003 23:42:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohwj19637
	for mpls-outgoing; Thu, 27 Mar 2003 20:22:13 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQohwj19566
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 20:21:52 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohwj13491
	for <mpls@UU.NET>; Thu, 27 Mar 2003 20:21:10 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwj05288
	for <mpls@UU.NET>; Thu, 27 Mar 2003 20:21:09 GMT
Received: from thurn.corp.titan.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: thurn.corp.titan.com [159.62.51.20])
	id QQohwj05198
	for <mpls@UU.NET>; Thu, 27 Mar 2003 20:21:07 GMT
Received: from vcmd-nt1.validity.com (val114-005.validity.titan.com [159.62.114.5])
	by thurn.corp.titan.com (8.12.8/8.12.8) with ESMTP id h2RKKcrF009169;
	Thu, 27 Mar 2003 12:20:39 -0800
Received: by VCMD-NT1 with Internet Mail Service (5.5.2655.55)
	id <HYNAVH72>; Thu, 27 Mar 2003 15:19:53 -0500
Message-ID: <561621C69F17D511A3A20050047340EC01AAF64D@VCMD-NT1>
From: "Ferrell, William" <William.Ferrell@titan.com>
To: "'David Allan'" <dallan@nortelnetworks.com>,
        "'Naidu, Venkata'"
	 <Venkata.Naidu@Marconi.com>,
        "Ferrell, William"
	 <William.Ferrell@titan.com>,
        "'Shahram Davari'"
	 <Shahram_Davari@pmc-sierra.com>,
        "'curtis@fictitious.org'"
	 <curtis@fictitious.org>
Cc: "'Thomas D. Nadeau'" <tnadeau@lucidvision.com>,
        "'George Swallow'"
	 <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'"
	 <mpls@UU.NET>, tnadeau@cisco.com
Subject: RE: [PWE3] MPLS PID 
Date: Thu, 27 Mar 2003 15:19:45 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2F49E.3535E5D0"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2F49E.3535E5D0
Content-Type: text/plain;
	charset="iso-8859-1"

Dave 
Thats concrete, clear and undisputeable...touche
Will

-----Original Message-----
From: David Allan [mailto:dallan@nortelnetworks.com]
Sent: Thursday, March 27, 2003 3:12 PM
To: 'Naidu, Venkata'; 'Ferrell, William'; 'Shahram Davari';
'curtis@fictitious.org'
Cc: 'Thomas D. Nadeau'; 'George Swallow'; W. Mark Townsley; Andrew G. Malis;
'mpls@uu.net'; tnadeau@cisco.com
Subject: RE: [PWE3] MPLS PID 



Hi Venkata: 

> -> Hang on.... 
> -> Using CRC as a sanity check (ensuring somthing starting 
> -> with 0x04 is actually an IP packet) prior to load balancing 
> -> is the suggestion, an imperfect improvement assuming the 
> -> first nybble cannot be completely trusted as authoritative 
> -> indication of payload type. Suggesting that it is then 
> -> vulnerable to malicious attacks is a non-sequitor. 
> 
>   More than malicious attacks, my strong objection is 
>   because of the approximations in the suggestion. If 
>   all that we want to achieve is to find the payload type 
>   then that should not be *guessed* by some approximations 
>   or probabilistic method. Propose something concrete to 
>   identify the payload type. In networking all such 
>   approximation algorithms are called hacks. In the history 
>   there is such a hack called henk-hack already :-) 

See Eric's last post, summarizes the overall situation quite nicely although
some may not agree with the proposed resolution ;-). As to the above, I
agree with you which is why I explicitly said "imperfect solution".


> -> The goal is to avoid misordering flows across the network. 
> 
>   If that is the goal, why even to bother to find the payload 
>   type. Search for and reserve a bit (just a bit) - for example 
>   from EXP bits (if not used from Diffserv) - then ask the 
>   sender to set the bit as NL (no-load-balance bit). This acts 
>   just as good as Don't fragment (DF) bit in IP Header. But, 
>   I suppose that won't suffice for your requirement. 

It probably would if such a bit were available. T'would have been nice to
have an OAM bit too.... 

> 
> -> A rogue packet is a flow unto itself and would only 
> -> impact its neighbors if load spreading was somehow stateful. 
> 
>   If that is the case, we shouldn't have spent so much time 
>   in security. The difficult thing is to find whether the 
>   packet is *real-rogue* packet or *rogue packet relative to IP* 

I don't think load spreading cares.... 

cheers 
Dave 


------_=_NextPart_001_01C2F49E.3535E5D0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [PWE3] MPLS PID</TITLE>

<META content="MSHTML 5.50.4916.2300" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=502261920-27032003><FONT face=Arial color=#0000ff size=2>Dave 
</FONT></SPAN></DIV>
<DIV><SPAN class=502261920-27032003><FONT face=Arial color=#0000ff size=2>Thats 
concrete, clear and undisputeable...touche</FONT></SPAN></DIV>
<DIV><SPAN class=502261920-27032003><FONT face=Arial color=#0000ff 
size=2>Will</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> David Allan 
  [mailto:dallan@nortelnetworks.com]<BR><B>Sent:</B> Thursday, March 27, 2003 
  3:12 PM<BR><B>To:</B> 'Naidu, Venkata'; 'Ferrell, William'; 'Shahram Davari'; 
  'curtis@fictitious.org'<BR><B>Cc:</B> 'Thomas D. Nadeau'; 'George Swallow'; W. 
  Mark Townsley; Andrew G. Malis; 'mpls@uu.net'; 
  tnadeau@cisco.com<BR><B>Subject:</B> RE: [PWE3] MPLS PID <BR><BR></FONT></DIV>
  <P><FONT size=2>Hi Venkata:</FONT> </P>
  <P><FONT size=2>&gt; -&gt; Hang on....</FONT> <BR><FONT size=2>&gt; -&gt; 
  Using CRC as a sanity check (ensuring somthing starting </FONT><BR><FONT 
  size=2>&gt; -&gt; with 0x04 is actually an IP packet) prior to load balancing 
  </FONT><BR><FONT size=2>&gt; -&gt; is the suggestion, an imperfect improvement 
  assuming the </FONT><BR><FONT size=2>&gt; -&gt; first nybble cannot be 
  completely trusted as authoritative </FONT><BR><FONT size=2>&gt; -&gt; 
  indication of payload type. Suggesting that it is then </FONT><BR><FONT 
  size=2>&gt; -&gt; vulnerable to malicious attacks is a non-sequitor. 
  </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;&nbsp;&nbsp; More 
  than malicious attacks, my strong objection is</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp; because of the approximations in the suggestion. 
  If</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp; all that we want to achieve is to 
  find the payload type</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp; then that 
  should not be *guessed* by some approximations</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp; or probabilistic method. Propose something concrete 
  to</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp; identify the payload type. In 
  networking all such </FONT><BR><FONT size=2>&gt;&nbsp;&nbsp; approximation 
  algorithms are called hacks. In the history</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp; there is such a hack called henk-hack already 
  :-)</FONT> </P>
  <P><FONT size=2>See Eric's last post, summarizes the overall situation quite 
  nicely although some may not agree with the proposed resolution ;-). As to the 
  above, I agree with you which is why I explicitly said "imperfect 
  solution".</FONT></P>
  <P><FONT size=2></FONT> <BR><FONT size=2>&gt; -&gt; The goal is to avoid 
  misordering flows across the network.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt;&nbsp;&nbsp; If that is the goal, why even to 
  bother to find the payload</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp; type. 
  Search for and reserve a bit (just a bit) - for example</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp; from EXP bits (if not used from Diffserv) - then ask 
  the</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp; sender to set the bit as NL 
  (no-load-balance bit). This acts</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp; just 
  as good as Don't fragment (DF) bit in IP Header. But,</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp; I suppose that won't suffice for your 
  requirement.</FONT> </P>
  <P><FONT size=2>It probably would if such a bit were available. T'would have 
  been nice to have an OAM bit too....</FONT> </P>
  <P><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; -&gt; A rogue packet is a 
  flow unto itself and would only</FONT> <BR><FONT size=2>&gt; -&gt; impact its 
  neighbors if load spreading was somehow stateful.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt;&nbsp;&nbsp; If that is the case, we shouldn't 
  have spent so much time </FONT><BR><FONT size=2>&gt;&nbsp;&nbsp; in security. 
  The difficult thing is to find whether the </FONT><BR><FONT 
  size=2>&gt;&nbsp;&nbsp; packet is *real-rogue* packet or *rogue packet 
  relative to IP*</FONT> </P>
  <P><FONT size=2>I don't think load spreading cares....</FONT> </P>
  <P><FONT size=2>cheers</FONT> <BR><FONT size=2>Dave</FONT> 
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C2F49E.3535E5D0--


From owner-mpls@UU.NET  Thu Mar 27 22:52:03 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03152
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 22:52:02 -0500 (EST)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohww15796;
	Thu, 27 Mar 2003 23:41:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohwj19507
	for mpls-outgoing; Thu, 27 Mar 2003 20:20:15 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQohwj19499
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 20:20:11 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohwj06246
	for <mpls@UU.NET>; Thu, 27 Mar 2003 20:19:04 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwj02450
	for <mpls@UU.NET>; Thu, 27 Mar 2003 20:19:02 GMT
Received: from thurn.corp.titan.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: thurn.corp.titan.com [159.62.51.20])
	id QQohwj02391
	for <mpls@UU.NET>; Thu, 27 Mar 2003 20:19:01 GMT
Received: from vcmd-nt1.validity.com (val114-005.validity.titan.com [159.62.114.5])
	by thurn.corp.titan.com (8.12.8/8.12.8) with ESMTP id h2RKHwrF008927;
	Thu, 27 Mar 2003 12:17:59 -0800
Received: by VCMD-NT1 with Internet Mail Service (5.5.2655.55)
	id <HYNAVH7A>; Thu, 27 Mar 2003 15:17:13 -0500
Message-ID: <561621C69F17D511A3A20050047340EC01AAF64C@VCMD-NT1>
From: "Ferrell, William" <William.Ferrell@titan.com>
To: "'erosen@cisco.com'" <erosen@cisco.com>,
        "Ferrell, William"
	 <William.Ferrell@titan.com>
Cc: "'David Allan'" <dallan@nortelnetworks.com>, jeremy.de_clercq@alcatel.be,
        "'Scott W Brim'" <sbrim@cisco.com>, pwe3@ietf.org, mpls@UU.NET
Subject: RE: [PWE3] MPLS PID 
Date: Thu, 27 Mar 2003 15:17:05 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

I see Eric

It seems as though your perspective is more specific to your
implementation.right ?
Will

-----Original Message-----
From: Eric Rosen [mailto:erosen@cisco.com]
Sent: Thursday, March 27, 2003 3:03 PM
To: Ferrell, William
Cc: 'David Allan'; jeremy.de_clercq@alcatel.be; 'Scott W Brim';
pwe3@ietf.org; mpls@UU.NET
Subject: Re: [PWE3] MPLS PID 



Eric> 6. No one has given a  reason why the first nibble of any such control
Eric>    word should not be as Stewart has proposed. 

David> Except that it breaks some  implementations that may have 0x04 in the
David> first nibble without being IP packets. 

Referring to implementations which don't use a martini control word? 

William> clarify  why  the exception  in  #6 is  so  easily  ignored in
your
William> opinion. 

Well, my company  does have implementations which omit  the control word, so
that's not it ;-)

We're in  a situation now in  which we have  things that don't work  so well
together (core routers doing ECMP  with MPLS, edge routers doing pseudowires
without a  martini control word).  If  we want everything  to work together,
something has to give, and it's not going to be something in the core ;-)



From owner-mpls@UU.NET  Fri Mar 28 02:11:22 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18058
	for <mpls-archive@lists.ietf.org>; Fri, 28 Mar 2003 02:11:18 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohxd18375
	for <mpls-archive@lists.ietf.org>; Fri, 28 Mar 2003 01:25:20 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohxd17816;
	Fri, 28 Mar 2003 01:25:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohxb25930
	for mpls-outgoing; Fri, 28 Mar 2003 00:57:31 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohxb25923
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Mar 2003 00:57:19 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohxb28578
	for <mpls@UU.NET>; Fri, 28 Mar 2003 00:56:11 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohxb17403
	for <mpls@UU.NET>; Fri, 28 Mar 2003 00:56:10 GMT
Received: from ix.eng.level3.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: machine78.Level3.com [209.244.5.93])
	id QQohxb17376
	for <mpls@UU.NET>; Fri, 28 Mar 2003 00:56:07 GMT
Received: from level3.net (localhost.eng.level3.com [127.0.0.1])
	by ix.eng.level3.com (8.11.0/8.11.0) with ESMTP id h2S0tg402137;
	Thu, 27 Mar 2003 17:55:42 -0700
Message-ID: <3E839D8E.2090509@level3.net>
Date: Thu, 27 Mar 2003 17:55:42 -0700
From: Luca Martini <luca@level3.net>
Organization: Level3 Communications LLC.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: Italian [it],French/Canada [fr-
MIME-Version: 1.0
To: Alia Atlas <aatlas@avici.com>
CC: danny@tcb.net, pwe3@ietf.org, mpls@UU.NET
Subject: Re: [PWE3] MPLS PID
References: <5.1.0.14.2.20030325181331.02012640@mailhost.avici.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



Alia Atlas wrote:
> How does requiring a PID in the PWE3 L2 control word solve or handle the 
> case where a control word is not mandatory?
> 
some networks might not care.
Lcua



> There are pseudo-wires, such as ethernet, where a control word is not 
> mandatory.  This would imply that the first nibble (which would be 
> identified as the suggested PID) would be that from the ethernet frame.
> 
> Alia
> 
> At 01:53 PM 3/25/2003 -0700, Danny McPherson wrote:
> 
>> [Note the cross-post, let's try to move this to MPLS please]
>>
>> I tend to agree with Mark & George (and others) that it should
>> be addressed in the MPLS WG, with feedback from PWE3.
>>
>> PWE3 Architecture and perhaps Requirements (ugh!) work should be
>> added as appropriate, please send your comments on what needs to
>> be done there ASAP, if you haven't already.
>>
>> -danny
>>
>>
>> >
>> > I agree too that the PID issue is more of an MPLS issue in general. 
>> As such, the
>> > I think the MPLS WG should be tasked with defining exactly what the 
>> PID looks
>> > like, and what internode behavior relying on the PID is allowed.
>> >
>> > However, the PWE3 architecture cannot ignore this entirely. It is 
>> PWE3's direct
>> > use of MPLS as its own PSN more than anything else that is imposing 
>> this
>> > practical requirement now (though I suppose it has theoretically 
>> always been an
>> > issue), and any definition coming from the MPLS WG would likely be 
>> in the form
>> > of a requirement on any header definition that rides directly 
>> adjacent to the
>> > last MPLS label in a stack. We all know that this would probably 
>> look something
>> > like simply stating that the first four bits MUST be 4 for IPv4, 6 
>> for IPv6, and
>> > up to IANA and the MPLS WG for future additions. Whether that means 
>> handing out
>> > values form the remaining 14 available under very tight control (at 
>> a minimum,
>> > via an RFC2434 Standards Action and the MPLS WGs blessing), or some 
>> other
>> > extended PID method, should be up to MPLS to ultimately decide and 
>> PWE3 to
>> > adhere to. This would all be done with PWE3's input of course, since 
>> there would
>> > be a lot of overlap in the folks making the decision.
>> >
>> > Regarding whether the MPLS WG has discussed this before, Eric Rosen 
>> suggested at
>> > the microphone in SF that it had, but at that time the decision 
>> obviously was to
>> > not include a PID within MPLS. The bottom line is that perhaps we 
>> are seeing
>> > that in hindsight this was an error, and if so this should be openly 
>> resolved
>> > within the MPLS WG.
>> >
>> > - Mark
>> >
>> > Andrew G. Malis wrote:
>> > > I would just like to second Ron's questions below, and also add that
>> > > there's no mention of the need for a protocol identification field in
>> > > the PWE3 requirements draft.
>> > >
>> > > Also, I noticed that the architecture draft had no recognition of the
>> > > TDM control word format; it only discussed the control word used 
>> for L2
>> > > encapsulations.
>> > >
>> > > So, I would like to request the following change in
>> > > draft-ietf-pwe3-arch-02.txt:
>> > >
>> > > 5.4.3. PW over MPLS Generic Control Word
>> > >
>> > >    The PW set-up protocol determines whether a particular PW uses a
>> > >    control word.  When a control word is used, it MUST have the
>> > >    following form for non-TDM encapsulations:
>> > >
>> > >        0                   1                   2                   3
>> > >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 
>> 0 1
>> > >       
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > >       |   RSVD/Flags  |FRG|  Length   | Sequence 
>> Number               |
>> > >       
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > >
>> > >         Figure 12 - MPLS Generic Control Word
>> > >
>> > >
>> > >    The meaning of the fields of the MPLS Generic Control Word (Figure
>> > >    12) is as follows:
>> > >
>> > >        RSVD/Flags (bits 0 to 7):
>> > >            These bits are available for per payload signaling. Their
>> > >            definition is encapsulation specific.  If not all of 
>> the bits
>> > >            are required for flags, some may be reserved for future 
>> use.
>> > >
>> > >        FRG (bits 8 and 9):
>> > >            These bits are used when fragmenting a PW payload. 
>> Their use
>> > >            is defined in [FRAG].
>> > >
>> > >        Length (bits 10 to 15):
>> > >            The length field is used to determine the size of a PW
>> > >            payload that might have been padded to the minimum 
>> Ethernet
>> > >            MAC frame size during its transit across the PSN.  If the
>> > >            MPLS payload (defined as the CW + the PW payload + any
>> > >            additional PW headers is less than 46 bytes, the length 
>> MUST
>> > >            be set to the length of the MPLS payload.  If the MPLS
>> > >            payload is between 46 bytes and 63 bytes the 
>> implementation
>> > >            MAY either set to the length to the length of the MPLS
>> > >            payload, or it MAY set it to 0.  If the length of the MPLS
>> > >            payload is greater than 63 bytes the length MUST be set 
>> to 0.
>> > >
>> > >        Sequence number (Bit 16 to 31):
>> > >            If the sequence number is not used, it is set to zero by
>> > >            the sender and ignored by the receiver.  Otherwise it
>> > >            specifies the sequence number of a packet. A circular list
>> > >            of sequence numbers is used. A sequence number takes a 
>> value
>> > >            from 1 to 65535 (2**16-1).
>> > >
>> > > For TDM applications, it must use the following general forms.
>> > >
>> > > Non-extended form:
>> > >     0                   1                   2                   3
>> > >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > >    |0| Flags | Structure Pointer[0:12] |  Sequence Number[0:13]    |
>> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > >
>> > > Extended form:
>> > >     0                   1                   2                   3
>> > >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > >    |1| Flags | Structure Pointer[0:12] |  Sequence Number[0:13]    |
>> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > >    |         Additional encapsulation-specific header fields       |
>> > >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > >
>> > >    Structure Pointer[0:12]: If used, the Structure Pointer 
>> contains the
>> > >    offset of the first byte of the payload structure.  Note that some
>> > >    TDM encapsulations do not require the use of a Structure Pointer,
>> > >    in which case this field may be reused for other uses.
>> > >
>> > >    Sequence Number[0:13]:  This is a packet sequence number, which
>> > >    continuously cycles from 0 to 0x3FFF.  It is generated and 
>> processed
>> > >    in accordance with the rules established in [RFC1889].  When 
>> the RTP
>> > >    header is used, this sequence number MUST match the LSBs of the 
>> RTP
>> > >    sequence Number.
>> > >
>> > > Thanks,
>> > > Andy
>> > >
>> > > -------
>> > >
>> > > At 3/23/2003 10:04 AM +0200, Ron Cohen wrote:
>> > >
>> > >> Stewart,
>> > >>
>> > >> I went over your SF arch presentation. I have doubts regarding the
>> > >> introduction of a requirement/suggestion for an all zero PID field
>> > >> within the PWE3 control word. My doubts relates both to the scope of
>> > >> this work as well as for the applications you are describing. 
>> Since I
>> > >> haven't been to the SF IETF, please forgive me in advance if these
>> > >> issues have already been discussed.
>> > >>
>> > >>
>> > >> MPLS PID scope:
>> > >> --------------
>> > >> In your presentation you describe a requirement/suggestion for an 
>> MPLS
>> > >> PID, that allows a network node to distinguish between an IPv4, 
>> IPv6 and
>> > >> PWE3 stream. The Multi-Protocol part of MPLS stands for carrying any
>> > >> network protocol on top of MPLS, including possibly IPX, CLNS, etc.
>> > >> Therefore, what you are proposing is introduction of an MPLS 
>> Protocol
>> > >> Identifier, which I believe has a much larger scope than just the 
>> PWE3
>> > >> WG.
>> > >>
>> > >> 1. Would you agree that this is an MPLS WG item? Has this 
>> requirement
>> > >> (MPLS PID) been discussed in the MPLS WG before / are there any 
>> drafts
>> > >> written?
>> > >>
>> > >> 2. If so, would 4 bits suffice for an MPLS PID?
>> > >>
>> > >>
>> > >> Applications:
>> > >> ------------
>> > >> You list a number of applications that require IP flow recognition,
>> > >> including load balancing, billing, and protection against network 
>> abuse
>> > >> and attacks. I would like to better understand if these applications
>> > >> indeed require the introduction of the PID field. For example, 
>> are these
>> > >> applications edge applications? Do these applications run on all 
>> LSPs,
>> > >> or are sensitive to BE LSP vs. LSP with priority? Do you run these
>> > >> applications on TE paths?
>> > >>
>> > >> 1. Are there any drafts that describe these applications?
>> > >>
>> > >> 2. If not, could you elaborate on each application, its scope, etc?
>> > >>
>> > >>
>> > >> Thanks
>> > >> Ron
>> > >>
>> > >> Ron Cohen
>> > >> CTO
>> > >> Lycium Networks
>> > >> Desk: +972 9 7619004
>> > >> Mobile: +972 55 245104
>> > >> Fax: +972 9 7619022
>> > >>
>> > >>
>> > >>
>> > >> _______________________________________________
>> > >> pwe3 mailing list
>> > >> pwe3@ietf.org
>> > >> https://www1.ietf.org/mailman/listinfo/pwe3
>> > >
>> > >
>> > > _______________________________________________
>> > > pwe3 mailing list
>> > > pwe3@ietf.org
>> > > https://www1.ietf.org/mailman/listinfo/pwe3
>> > >
>> >
>> > _______________________________________________
>> > pwe3 mailing list
>> > pwe3@ietf.org
>> > https://www1.ietf.org/mailman/listinfo/pwe3
>>
>>
>>
>> _______________________________________________
>> pwe3 mailing list
>> pwe3@ietf.org
>> https://www1.ietf.org/mailman/listinfo/pwe3
> 
> 
> 




From owner-mpls@UU.NET  Fri Mar 28 03:17:44 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20489
	for <mpls-archive@lists.ietf.org>; Fri, 28 Mar 2003 03:17:44 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohww16083
	for <mpls-archive@lists.ietf.org>; Thu, 27 Mar 2003 23:41:59 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohww14984;
	Thu, 27 Mar 2003 23:41:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohwj19384
	for mpls-outgoing; Thu, 27 Mar 2003 20:16:52 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQohwj19373
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Mar 2003 20:16:49 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohwi02464
	for <mpls@UU.NET>; Thu, 27 Mar 2003 20:12:26 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohwi14152
	for <mpls@UU.NET>; Thu, 27 Mar 2003 20:12:25 GMT
Received: from zcars0m9.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157])
	id QQohwi14055
	for <mpls@UU.NET>; Thu, 27 Mar 2003 20:12:23 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2RKBgY08876;
	Thu, 27 Mar 2003 15:11:42 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <GDF489A1>; Thu, 27 Mar 2003 15:11:42 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D016D2C04@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'Naidu, Venkata'" <Venkata.Naidu@Marconi.com>,
        "'Ferrell, William'"
	 <William.Ferrell@titan.com>,
        "'Shahram Davari'"
	 <Shahram_Davari@pmc-sierra.com>,
        "'curtis@fictitious.org'"
	 <curtis@fictitious.org>
Cc: "'Thomas D. Nadeau'" <tnadeau@lucidvision.com>,
        "'George Swallow'"
	 <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'"
	 <mpls@UU.NET>, tnadeau@cisco.com
Subject: RE: [PWE3] MPLS PID 
Date: Thu, 27 Mar 2003 15:11:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2F49D.1260A3A2"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2F49D.1260A3A2
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Venkata:

> -> Hang on....
> -> Using CRC as a sanity check (ensuring somthing starting 
> -> with 0x04 is actually an IP packet) prior to load balancing 
> -> is the suggestion, an imperfect improvement assuming the 
> -> first nybble cannot be completely trusted as authoritative 
> -> indication of payload type. Suggesting that it is then 
> -> vulnerable to malicious attacks is a non-sequitor. 
> 
>   More than malicious attacks, my strong objection is
>   because of the approximations in the suggestion. If
>   all that we want to achieve is to find the payload type
>   then that should not be *guessed* by some approximations
>   or probabilistic method. Propose something concrete to
>   identify the payload type. In networking all such 
>   approximation algorithms are called hacks. In the history
>   there is such a hack called henk-hack already :-)

See Eric's last post, summarizes the overall situation quite nicely although
some may not agree with the proposed resolution ;-). As to the above, I
agree with you which is why I explicitly said "imperfect solution".

 
> -> The goal is to avoid misordering flows across the network.
> 
>   If that is the goal, why even to bother to find the payload
>   type. Search for and reserve a bit (just a bit) - for example
>   from EXP bits (if not used from Diffserv) - then ask the
>   sender to set the bit as NL (no-load-balance bit). This acts
>   just as good as Don't fragment (DF) bit in IP Header. But,
>   I suppose that won't suffice for your requirement.

It probably would if such a bit were available. T'would have been nice to
have an OAM bit too....

> 
> -> A rogue packet is a flow unto itself and would only
> -> impact its neighbors if load spreading was somehow stateful.
> 
>   If that is the case, we shouldn't have spent so much time 
>   in security. The difficult thing is to find whether the 
>   packet is *real-rogue* packet or *rogue packet relative to IP*

I don't think load spreading cares....

cheers
Dave

------_=_NextPart_001_01C2F49D.1260A3A2
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [PWE3] MPLS PID </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Venkata:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -&gt; Hang on....</FONT>
<BR><FONT SIZE=3D2>&gt; -&gt; Using CRC as a sanity check (ensuring =
somthing starting </FONT>
<BR><FONT SIZE=3D2>&gt; -&gt; with 0x04 is actually an IP packet) prior =
to load balancing </FONT>
<BR><FONT SIZE=3D2>&gt; -&gt; is the suggestion, an imperfect =
improvement assuming the </FONT>
<BR><FONT SIZE=3D2>&gt; -&gt; first nybble cannot be completely trusted =
as authoritative </FONT>
<BR><FONT SIZE=3D2>&gt; -&gt; indication of payload type. Suggesting =
that it is then </FONT>
<BR><FONT SIZE=3D2>&gt; -&gt; vulnerable to malicious attacks is a =
non-sequitor. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; More than malicious attacks, my =
strong objection is</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; because of the approximations in =
the suggestion. If</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; all that we want to achieve is to =
find the payload type</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; then that should not be *guessed* =
by some approximations</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; or probabilistic method. Propose =
something concrete to</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; identify the payload type. In =
networking all such </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; approximation algorithms are called =
hacks. In the history</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; there is such a hack called =
henk-hack already :-)</FONT>
</P>

<P><FONT SIZE=3D2>See Eric's last post, summarizes the overall =
situation quite nicely although some may not agree with the proposed =
resolution ;-). As to the above, I agree with you which is why I =
explicitly said &quot;imperfect solution&quot;.</FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; -&gt; The goal is to avoid misordering flows =
across the network.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; If that is the goal, why even to =
bother to find the payload</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; type. Search for and reserve a bit =
(just a bit) - for example</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; from EXP bits (if not used from =
Diffserv) - then ask the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; sender to set the bit as NL =
(no-load-balance bit). This acts</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; just as good as Don't fragment (DF) =
bit in IP Header. But,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; I suppose that won't suffice for =
your requirement.</FONT>
</P>

<P><FONT SIZE=3D2>It probably would if such a bit were available. =
T'would have been nice to have an OAM bit too....</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -&gt; A rogue packet is a flow unto itself and =
would only</FONT>
<BR><FONT SIZE=3D2>&gt; -&gt; impact its neighbors if load spreading =
was somehow stateful.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; If that is the case, we shouldn't =
have spent so much time </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; in security. The difficult thing is =
to find whether the </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; packet is *real-rogue* packet or =
*rogue packet relative to IP*</FONT>
</P>

<P><FONT SIZE=3D2>I don't think load spreading cares....</FONT>
</P>

<P><FONT SIZE=3D2>cheers</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2F49D.1260A3A2--


From owner-mpls@UU.NET  Fri Mar 28 03:38:29 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20902
	for <mpls-archive@lists.ietf.org>; Fri, 28 Mar 2003 03:38:29 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohyf13463
	for <mpls-archive@lists.ietf.org>; Fri, 28 Mar 2003 08:29:58 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohyf11185;
	Fri, 28 Mar 2003 08:29:15 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohye11987
	for mpls-outgoing; Fri, 28 Mar 2003 08:01:44 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohye10799
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Mar 2003 08:01:35 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohye28335
	for <mpls@uu.net>; Fri, 28 Mar 2003 08:01:12 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohye15259
	for <mpls@uu.net>; Fri, 28 Mar 2003 08:01:09 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohye15209
	for <mpls@uu.net>; Fri, 28 Mar 2003 08:01:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2S813iH014216
	for <mpls@uu.net>; Fri, 28 Mar 2003 03:01:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id DAA24484 for <mpls@uu.net>; Fri, 28 Mar 2003 03:01:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2S812u11066 for mpls@uu.net; Fri, 28 Mar 2003 03:01:02 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohyd05443
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Mar 2003 07:59:42 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohyd01114
	for <mpls@uu.net>; Fri, 28 Mar 2003 07:58:45 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohyd09511
	for <mpls@uu.net>; Fri, 28 Mar 2003 07:58:45 GMT
Received: from gvvckct by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [195.101.168.252])
	id QQohyd09470
	for <mpls@uu.net>; Fri, 28 Mar 2003 07:58:43 GMT
Message-Id: <QQohyd09470.200303280758@cmr0.ash.ops.us.uu.net>
From: Sheridan Shastry <Clementgsgd@ibm.com>
To: <mpls@UU.NET>
Subject: Copy Any DVD
Date: Fri, 28 Mar 2003 01:23:30 -0500
Mime-Version: 1.0
Content-Type: text/html
Content-Transfer-Encoding: base64
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: base64

PEhUTUw+DQo8SEVBRD4NCjx0aXRsZT48L3RpdGxlPg0KIA0KPC9IRUFEPg0KIA0KPEJPRFk+
DQo8dGFibGUgY2VsbFNwYWNpbmc9IjAiIGNlbGxQYWRkaW5nPSIwIiB3aWR0aD0iNTExIiBh
bGlnbj0iY2VudGVyIiBib3JkZXI9IjAiPg0KICA8dHI+DQogICAgPHRkIHdpZHRoPSIxNDUi
IGhlaWdodD0iMTc0IiB2YWxpZ249InRvcCI+DQogICAgPGltZyBzcmM9Imh0dHA6Ly9tcGxz
QHd3dy5hd2Vzb21lYmFyZ2FpbnouY29tL0EvZC8wMS9iLmpwZyIgYm9yZGVyPSIwIiB3aWR0
aD0iMTk4IiBoZWlnaHQ9IjE3NCI+PC9hPjwvdGQ+DQogICAgPHRkIHZBbGlnbj0idG9wIiB3
aWR0aD0iMzk2IiBoZWlnaHQ9IjE5OCI+DQogICAgDQogICAgPGltZyBzcmM9Imh0dHA6Ly9t
cGxzQHd3dy5hd2Vzb21lYmFyZ2FpbnouY29tL0EvZC8wMS9hLmdpZiIgYm9yZGVyPSIwIiB3
aWR0aD0iMzk2IiBoZWlnaHQ9IjI0Ij48L2E+PGJyPg0KICAgIDxicj4NCiAgICA8Zm9udCBm
YWNlPSJBcmlhbCwgSGVsdmV0aWNhIiBjb2xvcj0iIzAwMDAwMCIgc2l6ZT0iMiI+WW91IGRv
IG5vdCBuZWVkIHRvIA0KICAgIHNwZW5kIGh1bmRyZWRzIG9uIGEgRFZEIGJ1cm5lciB0byBj
b3B5IERWRHMhIFdlIHdpbGwgc2hvdyB5b3UgaG93IHRvIHVzZSANCiAgICB5b3VyIENELVIg
V3JpdGVyIHRvIGNyZWF0ZSBiYWNrdXBzIG9mIHlvdXIgRFZEcyB0aGF0IHdpbGwgcGxheSBp
biB5b3VyIGhvbWUgDQogICAgRFZEIHBsYXllci48YnI+DQogICAgPGJyPg0KICAgIEFsbCB5
b3UgbmVlZCBpbiB5b3VyIGNvbXB1dGVyIGlzIGEgRFZEIGRyaXZlIHRoYXQgcGxheXMgRFZE
cyBhbmQgYSBDRC1SIA0KICAgIFdyaXRlci4gWW91IGNhbiBidXJuIG1vdmllcyBvbiBDRC1S
IG9yIENELVJXIGRpc2NzLi4gPC9mb250PjwvdGQ+DQogIDwvdHI+DQogIDx0cj4NCiAgICA8
dGQgd2lkdGg9IjE0NSIgaGVpZ2h0PSIxOTUiPiZuYnNwOzwvdGQ+DQogICAgPHRkIHZBbGln
bj0idG9wIiB3aWR0aD0iMzk2IiBoZWlnaHQ9IjE5NSI+DQogICAgPGJyPg0KICAgIDxicj4N
CiAgICA8Zm9udCBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhIiBjb2xvcj0iIzAwMDAwMCIgc2l6
ZT0iMiI+TGVhcm4gdGhlIHNlY3JldHMgdGhlIA0KICAgIERWRCBjb21wYW5pZXMgZG9uJ3Qg
d2FudCB5b3UgdG8ga25vdyEgWW91IHdpbGwgTkVWRVIgaGF2ZSB0byBidXkgYW5vdGhlciBE
VkQgDQogICAgYWdhaW4hIFRyYWRlIG1vdmllcyB3aXRoIGZyaWVuZHMsIGNvcHkgcmVudGFs
cyBhbmQgbXVjaCBtb3JlITxicj4NCiAgICA8YnI+DQogICAgQ29weSBvbmx5IDIgRFZEIG1v
dmllcyBhbmQgdGhpcyBwcm9ncmFtIGhhcyBwYWlkIGZvciBpdHNlbGYhIFRoaXMgcHJvZ3Jh
bSBpcyANCiAgICBCQU5ORUQgZnJvbSBtYW55IGRvd25sb2FkIHdlYiBzaXRlcyBiZWNhdXNl
IG9mIHRoZSBzZWNyZXRzIHdlIHRlYWNoIHlvdS4gR2V0IA0KICAgIHlvdXIgY29weSB0b2Rh
eSEgPC9mb250PjwvdGQ+DQogIDwvdHI+DQogIDx0cj4NCiAgICA8dGQgYWxpZ249Im1pZGRs
ZSIgd2lkdGg9IjU0MyIgY29sU3Bhbj0iMiIgaGVpZ2h0PSI2MCI+PGI+DQogICAgPGZvbnQg
Y29sb3I9IiNDQzAwMDAiIHNpemU9IjYiPjxhIGhyZWY9Imh0dHA6Ly9tcGxzQHd3dy5hd2Vz
b21lYmFyZ2FpbnouY29tL2QvaW5kZXgwMDExLmh0bWw/bjAzMj1rZW93anN0c250amNjdHRl
d2VnbnJuamNhYW1xa29oeHN2dWZxbyI+PGZvbnQgY29sb3I9IiNDQzAwMDAiIGZhY2U9IkFy
aWFsIj5Eb3dubG9hZCBJdCBJbnN0YW50bHkgSGVyZSE8L2ZvbnQ+PC9hPjwvZm9udD48L2I+
PC90ZD4NCiAgPC90cj4NCjwvdGFibGU+DQo8cD4mbmJzcDs8L3A+DQo8cD4mbmJzcDs8L3A+
DQo8Zm9udCBmYWNlPVZlcmRhbmEgc2l6ZT0xPnRoZSBpbnRlcnZpZXcgcHJvY2Vzcy4uLjwv
Zm9udD4gDQo8L0JPRFk+DQo8L0hUTUw+DQo=



From owner-mpls@UU.NET  Fri Mar 28 09:46:35 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00005
	for <mpls-archive@lists.ietf.org>; Fri, 28 Mar 2003 09:46:35 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohzf29353
	for <mpls-archive@lists.ietf.org>; Fri, 28 Mar 2003 14:48:56 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohzf28256;
	Fri, 28 Mar 2003 14:48:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohzc10773
	for mpls-outgoing; Fri, 28 Mar 2003 14:10:16 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohzc10689
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Mar 2003 14:10:02 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohzc15212
	for <mpls@uu.net>; Fri, 28 Mar 2003 14:09:40 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohzc08113
	for <mpls@uu.net>; Fri, 28 Mar 2003 14:09:39 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQohzc07871
	for <mpls@uu.net>; Fri, 28 Mar 2003 14:09:31 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2SE9SMR029939
	for <mpls@uu.net>; Fri, 28 Mar 2003 09:09:28 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA07705 for <mpls@uu.net>; Fri, 28 Mar 2003 09:09:27 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2SE9R427690 for mpls@uu.net; Fri, 28 Mar 2003 09:09:27 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohza20606
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Mar 2003 13:37:40 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohza19127
	for <mpls@UU.NET>; Fri, 28 Mar 2003 13:37:21 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohza11062
	for <mpls@UU.NET>; Fri, 28 Mar 2003 13:37:21 GMT
Received: from lucidvision.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [206.67.54.196])
	id QQohza11039
	for <mpls@UU.NET>; Fri, 28 Mar 2003 13:37:20 GMT
Received: from tnadeau-w2k.lucidvision.com [24.34.129.103] by lucidvision.com with ESMTP
  (SMTPD32-7.13) id AF5D14C00E2; Fri, 28 Mar 2003 08:34:21 -0500
Message-Id: <5.2.0.9.2.20030327142229.029b1c90@www.lucidvision.com>
X-Sender: tnadeau@www.lucidvision.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 27 Mar 2003 14:28:12 -0500
To: erosen@cisco.com, Shahram Davari <Shahram_Davari@pmc-sierra.com>
From: "Thomas D. Nadeau" <tnadeau@lucidvision.com>
Subject: Re: [PWE3] MPLS PID 
Cc: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "'George Swallow'" <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'" <mpls@UU.NET>, tnadeau@cisco.com
In-Reply-To: <200303271900.h2RJ07iH003717@rtp-core-1.cisco.com>
References: <Your message of Thu, 27 Mar 2003 10:49:58 -0800. <4B6D09F3B826D411A67300D0B706EFDE0115C845@nt-exch-yow.pmc-sierra.bc.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


>Shahram> my proposal superior in terms of probability of false positives,
>
>Only in  the absence of  the control word.   In the presence of  the control
>word, there are no false positives.

         Not to get too off topic, but again, this seems like
another good reason to use the control word and make it
an implementation requirement.

         --Tom

>Shahram> Checksum is easy and is done all the time in routers
>
>For IPv4  packets, but for non-IPv4  packets, this is extra  work that would
>not otherwise need  to be done.  Extra code too (gates  or microcode), as it
>would happen  in a different  forwarding path than  that used for  IPv4, and
>microcoders and hardware designers are not very big on calling subroutines.




From owner-mpls@UU.NET  Fri Mar 28 09:47:01 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00037
	for <mpls-archive@lists.ietf.org>; Fri, 28 Mar 2003 09:47:01 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohzf00379
	for <mpls-archive@lists.ietf.org>; Fri, 28 Mar 2003 14:49:23 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohzf29035;
	Fri, 28 Mar 2003 14:48:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohzc11348
	for mpls-outgoing; Fri, 28 Mar 2003 14:11:19 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQohzc11136
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Mar 2003 14:11:00 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohzc09723
	for <mpls@uu.net>; Fri, 28 Mar 2003 14:09:06 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohzc06789
	for <mpls@uu.net>; Fri, 28 Mar 2003 14:09:05 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohzc06732
	for <mpls@uu.net>; Fri, 28 Mar 2003 14:09:02 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2SE8tiH014480
	for <mpls@uu.net>; Fri, 28 Mar 2003 09:08:59 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA07663 for <mpls@uu.net>; Fri, 28 Mar 2003 09:08:54 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2SE8sb27648 for mpls@uu.net; Fri, 28 Mar 2003 09:08:54 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohxi10640
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Mar 2003 02:41:18 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohxi21307
	for <mpls@uu.net>; Fri, 28 Mar 2003 02:40:35 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohxi00310
	for <mpls@uu.net>; Fri, 28 Mar 2003 02:40:34 GMT
Received: from smtp02.mrf.mail.rcn.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp02.mrf.mail.rcn.net [207.172.4.61])
	id QQohxi00300
	for <mpls@uu.net>; Fri, 28 Mar 2003 02:40:34 GMT
Received: from 209-6-242-89.c3-0.frm-ubr1.sbo-frm.ma.cable.rcn.com ([209.6.242.89] helo=HSHAH700)
	by smtp02.mrf.mail.rcn.net with smtp (Exim 3.35 #4)
	id 18yjnE-00049m-00; Thu, 27 Mar 2003 21:40:32 -0500
Reply-To: <hshah@rcn.com>
From: "himanshu shah" <hshah@rcn.com>
To: <erosen@cisco.com>,
        "'Nurit Sprecher'" <nurit.sprecher@SeabridgeNetworks.com>
Cc: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        "'Alia Atlas'" <aatlas@avici.com>, <mpls@UU.NET>,
        "'Mustapha Aissaoui \(E-mail\)'" <mustapha.aissaoui@alcatel.com>
Subject: RE: Distributing Labels for PWs within an LSP TE Tunnel 
Date: Thu, 27 Mar 2003 21:40:32 -0500
Message-ID: <00e801c2f4d3$67e4cd40$021ea8c0@HSHAH700>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <200303251504.h2PF48iH017431@rtp-core-1.cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Not sure If I have the whole question (because I don't have
the original email).

However, guessing on the question below, I would say that
one can use LDP signaled PW as control plane and use
RSVP-TE signaled tunnel for data plane.

It is a local matter though. As long as both PEs have
established RSVP-TE tunnel based on (LDP) Peer's IP address,
each PE can map the PW on the RSVP-TE tunnel whose endpoint
is remote PE peer (tunnel must be PHP though).
There is no need to notify the other what type of tunnel
he should use, either.

Note that I am not advocating running LDP within RSVP-TE
tunnel. And in this respect, control plane and data plane
could very well be disjoint.

You may want to look at draft-shah-pwe3-control-protocol-extension-00.txt
where I have defined QOS TLV where each PE can optionally
signal what tunnel type other should use.


/himanshu



-----Original Message-----
From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Eric
Rosen
Sent: Tuesday, March 25, 2003 10:04 AM
To: Nurit Sprecher
Cc: 'Shahram Davari'; 'Alia Atlas'; mpls@uu.net; Mustapha Aissaoui
(E-mail)
Subject: Re: Distributing Labels for PWs within an LSP TE Tunnel



Nurit> I do look for  a way to bind the (LDP) signaled  PWs to the (RSVP-TE)
Nurit> signaled transport tunnel LSP, in a way that both PEs know about it.

There is no way to do this using the protocols as currently defined.



From owner-mpls@UU.NET  Fri Mar 28 13:11:11 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10373
	for <mpls-archive@lists.ietf.org>; Fri, 28 Mar 2003 13:11:11 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohzs06689
	for <mpls-archive@lists.ietf.org>; Fri, 28 Mar 2003 18:13:32 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQohzs06238;
	Fri, 28 Mar 2003 18:13:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohzp21220
	for mpls-outgoing; Fri, 28 Mar 2003 17:18:44 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohzp21211
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Mar 2003 17:18:40 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohzp24054
	for <mpls@uu.net>; Fri, 28 Mar 2003 17:17:07 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohzp18449
	for <mpls@uu.net>; Fri, 28 Mar 2003 17:17:06 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohzp18430
	for <mpls@uu.net>; Fri, 28 Mar 2003 17:17:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2SHH2iH001066
	for <mpls@uu.net>; Fri, 28 Mar 2003 12:17:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA23173 for <mpls@uu.net>; Fri, 28 Mar 2003 12:17:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2SHH2U10994 for mpls@uu.net; Fri, 28 Mar 2003 12:17:02 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQohzp20940
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Mar 2003 17:15:40 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQohzp19216
	for <mpls@uu.net>; Fri, 28 Mar 2003 17:15:06 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohzp17868
	for <mpls@uu.net>; Fri, 28 Mar 2003 17:15:04 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQohzp17833
	for <mpls@uu.net>; Fri, 28 Mar 2003 17:15:03 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2SHF2MR013567
	for <mpls@uu.net>; Fri, 28 Mar 2003 12:15:02 -0500 (EST)
Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA23011 for <mpls@uu.net>; Fri, 28 Mar 2003 12:15:01 -0500 (EST)
Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id MAA29422 for <mpls@uu.net>; Fri, 28 Mar 2003 12:15:01 -0500 (EST)
Message-Id: <200303281715.MAA29422@bifocal.cisco.com>
X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs
To: mpls@UU.NET
Subject: Last call on draft-ietf-mpls-mgmt-overview-03.txt
Date: Fri, 28 Mar 2003 12:15:01 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

This message begins a WG last call on 

  Multiprotocol Label Switching (MPLS) Management Overview

    <draft-ietf-mpls-mgmt-overview-03.txt>

The last call ends on April 11, midnight GMT.

...George

======================================================================
George Swallow          Cisco Systems                   (978) 497-8143
                        250 Apollo Drive
                        Chelmsford, Ma 01824





From owner-mpls@UU.NET  Fri Mar 28 15:01:18 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15071
	for <mpls-archive@lists.ietf.org>; Fri, 28 Mar 2003 15:01:17 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoiaa09389
	for <mpls-archive@lists.ietf.org>; Fri, 28 Mar 2003 20:03:39 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoiaa07564;
	Fri, 28 Mar 2003 20:02:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohzx07268
	for mpls-outgoing; Fri, 28 Mar 2003 19:28:27 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQohzx07259
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Mar 2003 19:28:24 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQohzx26434
	for <mpls@uu.net>; Fri, 28 Mar 2003 19:28:05 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohzx00315
	for <mpls@uu.net>; Fri, 28 Mar 2003 19:28:05 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQohzx00298
	for <mpls@uu.net>; Fri, 28 Mar 2003 19:28:04 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2SJS1MR022996
	for <mpls@uu.net>; Fri, 28 Mar 2003 14:28:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA04385 for <mpls@uu.net>; Fri, 28 Mar 2003 14:28:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2SJS1i19476 for mpls@uu.net; Fri, 28 Mar 2003 14:28:01 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohzx07099
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Mar 2003 19:24:23 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohzx01528
	for <mpls@UU.NET>; Fri, 28 Mar 2003 19:22:33 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohzx15163
	for <mpls@UU.NET>; Fri, 28 Mar 2003 19:22:31 GMT
Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQohzx15135
	for <mpls@UU.NET>; Fri, 28 Mar 2003 19:22:30 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id NAA37638;
	Thu, 27 Mar 2003 13:06:56 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303271806.NAA37638@workhorse.fictitious.org>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
cc: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "'Thomas D. Nadeau'" <tnadeau@lucidvision.com>,
        "'George Swallow'" <swallow@cisco.com>,
        "W. Mark Townsley" <townsley@cisco.com>,
        "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>,
        "'mpls@uu.net'" <mpls@UU.NET>, tnadeau@cisco.com
Reply-To: curtis@fictitious.org
Subject: Re: [PWE3] MPLS PID 
In-reply-to: Your message of "Thu, 27 Mar 2003 07:06:49 PST."
             <4B6D09F3B826D411A67300D0B706EFDE0115C839@nt-exch-yow.pmc-sierra.bc.ca> 
Date: Thu, 27 Mar 2003 13:06:56 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <4B6D09F3B826D411A67300D0B706EFDE0115C839@nt-exch-yow.pmc-sierra.bc.
ca>, Shahram Davari writes:
> >I don't feel obligated to answer nonsense questions.  No one has
> >proposed putting a CRC in the PID.
> 
> First of all I meant computing CRC over the first 20 byte of payload header
> and comparing it to the suspected IP CRC in octets 11 and 12 of the payload.
> If they match then it is IPv4, if not it is something else (similar procedure
>  for IPv6)
> 
> Secondly I am proposing it now. Is there a problem? I feel my procedure is fa
> r superior to just checking 4 bits to decide whether the payload is IP or not
> . 


It would be a lot more efficient to just put in a PID that states what
the payload type is rather than CRC the header.  This way if it isn't
IPv4 or IPv6, we know what it is.

I don't think we should jam the PID into 4 bits.  Two or four bytes
would be a lot more reasonable (using ethertype for example).

Curtis



From owner-mpls@UU.NET  Fri Mar 28 19:33:59 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26733
	for <mpls-archive@lists.ietf.org>; Fri, 28 Mar 2003 19:33:59 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoiap03320
	for <mpls-archive@lists.ietf.org>; Fri, 28 Mar 2003 23:45:46 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoiap01564;
	Fri, 28 Mar 2003 23:45:03 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoian06691
	for mpls-outgoing; Fri, 28 Mar 2003 23:18:19 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoian06682
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Mar 2003 23:18:09 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoian08574
	for <mpls@uu.net>; Fri, 28 Mar 2003 23:17:06 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoian05951
	for <mpls@uu.net>; Fri, 28 Mar 2003 23:17:04 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoian05934
	for <mpls@uu.net>; Fri, 28 Mar 2003 23:17:04 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2SNH2MR007627
	for <mpls@uu.net>; Fri, 28 Mar 2003 18:17:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA21825 for <mpls@uu.net>; Fri, 28 Mar 2003 18:17:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2SNH1604724 for mpls@uu.net; Fri, 28 Mar 2003 18:17:01 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoian06468
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Mar 2003 23:15:39 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoiam00425
	for <mpls@uu.net>; Fri, 28 Mar 2003 23:09:25 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoiam22948
	for <mpls@uu.net>; Fri, 28 Mar 2003 23:09:24 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoiam22924
	for <mpls@uu.net>; Fri, 28 Mar 2003 23:09:23 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2SN9MiH016877
	for <mpls@uu.net>; Fri, 28 Mar 2003 18:09:22 -0500 (EST)
Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA21369 for <mpls@uu.net>; Fri, 28 Mar 2003 18:09:22 -0500 (EST)
Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id SAA03264 for <mpls@uu.net>; Fri, 28 Mar 2003 18:09:21 -0500 (EST)
Message-Id: <200303282309.SAA03264@bifocal.cisco.com>
X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs
To: mpls@UU.NET
Subject: Draft MPLS minutes
Date: Fri, 28 Mar 2003 18:09:21 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

MPLS Working Group

WG Chairs: George Swallow <swallow@cisco.com>, Loa Andersson 
<loa.andersson@utfors.se>

George chaired the meeting.  Andy Malis took the minutes.
(Thanks Andy!)

1.  Overview of ISOCORE Interoperability Tests

Rajiv Papneja, rpapneja@isocore.com

Rajiv presented the results of the March MPLS interoperability testing
at ISOCORE.  They tested RSVP-TE with FRR, MPLS LDP signaling, and
MPLS as a transport for L2 VPNs, specifically including VPLS.

Their service provider sponsors provide the list of functionality to
be tested as input to the test plans.  They had ten vendors
participating in the testing, and they built a network with both core
LSRs and edge LERs.  They used ISIS-TE as the IGP for RSVP-TE.

More than 30 interoperability issues were discovered in 7 days of
testing.  More than 15 fast reroute scenarios were tested, and they
achieved <40 ms switch-over in the scenarios.

The found a number of issues in the testing.  Some of the highlights
of these issues were:

* They found issues with reverse compatibility in FRR for the nodes
   that don't support it.  There was an issue with ISIS-TE in that not
   all vendors had implemented the latest drafts, so they recommend
   that all vendors update their code.

* They also suggest that all vendors support ERO in the RSVP-TE Path
   message (they found that some did not).

* In the LDP HELLO message, they found incompatible values in the
   transport address TLV, and an ambiguity in the definition of the LDP
   TLV length definition.  They recommended on how these problems need
   to be corrected in RFC 3036.

* There were also ambiguities in the value of the LSR-ID over targeted
   and basic discovery.  This also needs to be fixed in RFC 3036.

* Some vendors were advertising per-interface label space for targeted
   LDP sessions when they should have been using per-platform labels
   due to an ambiguity in the Martini signaling draft.

* Backward compatibility issues between the different revisions of the
   VPLS draft.

* An ambiguity in the Address List TLV in Address Withdraw messages.

Their upcoming testing will be GMPLS interoperability in April, MPLS
Leading Edge testing in July and August, and the 4th MPLS 2003 Demo
following the MPLS 2003 conference.


2.  TE-related drafts

Reoptimization of explicit loosely routed MPLS TE paths
http://www.ietf.org/internet-drafts/draft-vasseur-mpls-loose-path-reopt-01.txt
Jean-Philippe Vasseur, jpv@cisco.com

This draft proposes a mechanism for the reoptimization of loosely
routed explicit paths. A loosely routed explicit path is as a path
specified as a combination of strict and loose hop(s) that contains at
least one loose hop and zero or more strict hop(s). The path
calculation (ERO expansion) to reach a loose hop is made on the
previous hop defined in the TE LSP path. This draft proposes a
mechanism that allows:

- the TE LSP head-end LSR to trigger a reoptimization on every loose
   hops along the path,

- an LSR to signal to the TE LSP head-end that a better path exists to
   reach a loose than the path in use. A better path is defined as a
   path with a lower cost, where the cost is defined by the metric used
   to compute the path.

This primarily applies to inter-area TE LSPs and inter-AS TE LSPs when
the path is defined as a list of loose hops (generally the loose hops
are the area border routers) but the mechanism is also applicable to
any loosely routed explicit paths within a single routing domain.

If and only if at least a better path exists in an area or AS,
reoptimization is triggered.

The reoptimization can be event-driven or timer-driven, and triggered
from both the head-end and from a mid-point LSR.

Comments have been received from service providers acknowledging their
interest in deploying this technology.

Rahul Aggarwal suggested an improvement in one of the mechanisms in
the draft to simply the operation in some situations.  JP agreed with
the suggestion.

Philip Matthews asked a question about the use of PathErr
notification, since they can be lost in the network.  JP explained how
the draft can compensate for such losses.

JP proposed that this become a working group draft. George said that
the IETF has to decide how it's going to treat the entire set of
inter-area and inter-AS TE drafts before this draft can be accepted.
This topic is going to be discussed later in the week at the sub-IP
Directorate meeting.  Plus, decisions to accept drafts are always made
on the email list.  There may also be working group charter changes
required before taking this on.  A hum 'vote' showed some support for
making this a WG draft in the room.


Definition of an RRO node-id subobject
http://www.ietf.org/internet-drafts/draft-vasseur-mpls-nodeid-subobject-00.txt
Jean-Philippe Vasseur, jpv@cisco.com

In the context of MPLS TE fast reroute, the merge point (MP) address
is required at the point of local repair in order to select a backup
tunnel intersecting a protected TE LSP on a downstream LSR.  However,
existing protocol mechanisms are not sufficient to find the MP address
in multi-area or multi-domain routing networks. As a result, the
current MPLS Fast Reroute mechanism cannot be used to protect
inter-area or inter-AS TE LSPs from a failure of an area border router
or Autonomous System border router. This document specifies the use of
existing RRO IPv4 and IPv6 subobjects (with a new flag defined) to
define the node-id subobject in order to resolve this issue.

Use of MPLS TE FRR bypass has been identified as a key requirement by
service providers.  This draft proposes a simple flag definition to
allow backup tunnel selection of inter-area/inter-AS TE LSPs.

Again, JP asked this draft be adopted as a WG draft.  George said that
this is a very simple point solution, and very straightforward, and
he's in favor of adopting it.  There was widespread support in the
room.  This will be ratified on the list.


MPLS Traffic Engineering Fast reroute: bypass tunnel path computation for
   bandwidth protection
http://www.ietf.org/internet-drafts/draft-vasseur-mpls-backup-computation-02.txt 

Jean-Louis Le Roux, jeanlouis.leroux@francetelecom.com

This draft proposes a model called the "Facility based computation
model" for computing bypass tunnels paths in the context of the MPLS
TE fast reroute, while allowing bandwidth sharing between bypass
tunnels protecting independent resources. Both a centralized and a
distributed path computation scenarios are covered. The required
signaling extensions are also discussed in the draft.

Jean-Louis described how the model can efficiently perform the path
computation.

He showed how the draft fits into section 6 of the current MPLS WG
charter, and presented the history of the drafts that were combined in
order to produce this draft and the changes from -01 to -02.  The
major change was the introduction of the SDLG concept - Shared SRLG
(shared risk link group) Dependency Link Groups.

Conclusion: FRR is now largely implemented and deployed.  BW
protection is a key requirement to protect sensitive traffic on
non-over-provisioned networks.  The facility-based computation model
seems the most efficient approach for bypass tunnel placement.

Vishal Sharma said that he had suggested some improvements to the
draft that removes the need for protocol extensions.  Jean-Louis said
that those comments applied to version 1 of the draft, and not to
version 2.

Jean-Louis asked that this be made a WG draft.  Most of the room had
not yet read it, so George was hesitant to make a determination now.
He said it should be discussed further on the list.


MPLS Traffic Engineering Soft preemption
http://www.ietf.org/internet-drafts/draft-meyer-mpls-soft-preemption-00.txt
Matthew Meyer, mrm@gblx.net

This draft discusses MPLS TE soft preemption, a set of protocol
modifications extending the current concept of preemption with the
goal of reducing or eliminating traffic disruption of preempted TE
LSPs.  Under present RSVP-TE signaling methods, LSPs are immediately
displaced upon preemption.  The introduction of a new preemption
pending flag helps to more gracefully mitigate the re-route process of
displaced LSPs.  For the brief period soft preemption is activated,
reservations (though not necessarily traffic levels) are in effect
overbooked until the LSP can be re-routed.

The problem to be solved is that preemption can be unnecessarily
disruptive to the network, especially in conjunction with Diffserv,
and preemption may occur even when there is excess capacity in the
network.  There is a concrete and operational issue that needs to be
resolved.  This draft proposes RSVP-TE mechanisms that can be used to
treat the lower-priority flows better.

George, as one of the authors of RFC 3209, said that there is a hole
in that RFC and this RFC plugs it, and he supports this as a working
group item.

Rahul said that he's also supportive of this, and he proposed an
improvement to the policing function. Matthew agreed.

Kireeti Kompella said that we need to discuss RRO vs. PathErr on the
list.  JP said that the first drat used PathErr, but it was changed to
RRO in the second draft based on implementation experience.

Adrian Farrel asked that the authors not come up with protocol
solutions to respond to nonstandard deployed versions of the
specification.  Matthew and George both agreed.  The room agreed that
this be made a WG draft, and it will be ratified on the list.


3.  Graceful Restart

LDP DoD Graceful Restart
http://www.ietf.org/internet-drafts/draft-thomas-mpls-ldp-dod-restart-00.txt
Bob Thomas, rhthomas@cisco.com

LDP graceful restart is a mechanism that helps reduce the negative
effects on MPLS traffic caused by the restart of an LSR's control
plane, specifically by the restart of its LDP component on LSRs that
are capable of preserving MPLS forwarding state across the
restart. RFC 3478 defines procedures for LDP graceful restart for
downstream unsolicited label distribution but leaves procedures for
downstream on demand label distribution a subject for future study.
This document defines graceful restart procedures for downstream on
demand label distribution.

Bob gave an overview of how his draft builds upon the mechanisms
already in RFC 3478, and specifies changes to the Label Request and
Label Abort messages.  It also makes changes to the behavior of a
neighbor router immediately following an LDP outage.

Bob asked that the WG accept the completion of LDP restart as a work
item, and this draft as the way to address the issue.

Rahul said that he was one of the authors on RFC 3478, and at the time
that document was done, there was no requirement for DoD.  He asked
what the requirement is for this draft.  Bob said that the motivation
is MPLS over ATM, which uses DoD.  There are MPLS over ATM deployments
that could take advantage of this.  Rahul also had some technical
suggestions that he will take offline with Bob.

There was widespread support for making this a WG document.  It will
be ratified on the list.


4.  OAM

OAM Requirements for MPLS Networks
http://www.ietf.org/internet-drafts/draft-nadeau-ietf-oam-requirements-01.txt
Tom Nadeau, tnadeau@cisco.com

As transport of diverse traffic types such as voice, frame relay, and
ATM over MPLS become more common, the ability to detect, handle and
diagnose control and data plane defects becomes critical. Detection
and specification of how to handle the defects is important, because
such defects may not only affect the fundamental operation of an MPLS
network, but also because they may impact SLA commitments for end
customers of that network.

This draft describes requirements for user and data plane MPLS
operations and management. These requirements have been gathered from
network operators who have extensive experience deploying MPLS
networks, and some of these requirements have appeared in other
documents, including Y.1710.  This draft specifies OAM requirements
for MPLS, as well as for applications of MPLS such as pseudowire voice
and VPN services.

At the last meeting, the authors were directed to combine their
separate drafts into a single OAM requirements draft.  This draft is
the result of that process.  Tom would like to see it accepted as a WG
document.

Dave Allen, the co-author, said that other Standards Develop
Organizations are using this document as a stake in the group for IETF
MPLS OAM requirements.  The group showed support.


Y.1711 and LSP-PING
http://www.ietf.org/internet-drafts/draft-allan-y1711-and-lsp-ping-00.txt
Dave Allen, dallan@nortelnetworks.com

Y.1711 and LSP-PING are products of ITU-T SG13/Q3 and the IETF MPLS WG
respectively. Each is reflective of the design philosophies of the
communities of their origin.

The purpose of this draft is to compare and contrast design elements
of the two approaches. The conclusion drawn is that the approaches are
complementary and comprehensive instrumentation of MPLS is ultimately
possible using both.

Dave gave an overview of Y.1711.  In Nov. 2002 it was recommended for
publication.  It focuses on point-to-point LSPs, without penultimate
hop pop (PHP).

There has been ongoing new work in order to support
multipoint-to-point LDP networks using PHP.  It uses a "bloom filter"
to encode the FEC information as a 128-bit string.  The initial focus
is mis-branching detection, and current proposals relate to LDP
availability.

He compared Y.1711 to LSP-PING, which is based on the ping/traceroute
paradigm.  It has good diagnostic capabilities, but is difficult to
scale for proactive detection.

Dave's conclusion is that the two protocols are complementary in
philosophy and design.  Y.1711 has utility as a detection tool, and
then you use LSP-PING and traceroute from a CLI to find out what's
going wrong.

Dave concluded his talk by inviting people to read his Y.1711 FEC-CV
tutorial, available at
http://standards.nortelnetworks.com/y.1711_fec_cv_public.ppt

Kireeti said that this is a good comparison of the two approaches, and
the fact they are not competing, but are complementary.  He would like
to help with some of the wording for the LSP-PING part.  He also had
some comments on the definition of "transaction" in the draft - he
would like to see that improved.  He also pointed out that LSP-PING
can be run periodically to use it as a detection mechanism.  The CLI
part is mostly for traceroute, rather than ping.  He compared LSP-PING
to the Frame Relay local management interface, which polls for status
every 10 seconds.  The difference between Y.1711 and running LSP-PING
periodically is that you are notified of outages in seconds rather
than milliseconds, but you are still notified.

Tom Nadeau said that he things the scalability concerns with LSP-PING
are unnecessarily harsh in the document, and that the document is
tilted more towards Y.1711 than it should be.

Shahram Davari said LSP-PING has become more complicated as the work
on it has progressed, and that it now really isn't that much simpler
than Y.1711.


Detecting MPLS Data Plane Liveness
http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-02.txt
Kireeti Kompella, kireeti@juniper.net

This document describes LSP-PING, which can be used to detect data
plane failures in MPLS Label Switched Paths.  There are two parts to
the draft: information carried in an MPLS "echo request" and "echo
reply" for the purposes of fault detection and isolation; and
mechanisms for reliably sending the echo reply.

Kireeti discussed the recent changes in the draft.  Many
clarifications were added, ECMP support was added, and the router
alert option is a MUST in echo requests.

There are still issues to be fixed, so there will be at least one more
revision.  The current text on the MPLS TTL is broken, and it will be
fixed.  Sections 5 and 11 will be removed.  The label stack in
downstream mapping with clarified.  Downstream mappings still need
clarification.  ECMP address selection needs to be expanded upon.  The
timestamp will be changed to NTP format.

Next steps: New revision in the next couple of weeks, and reissue the
WG last call.

Rahul said that there is a lot of value in LSP-PING in L3 VPNs.
Kireeti said that just IP ping works fine for this application.  Rahul
talked about why LSP-PING is valuable in this situation.  George said
that a good place to discuss this issue is in the framework document
(which doesn't exist) or in the requirements document.  George is
going to propose in the sub-IP meeting that such a document be
developed in this WG.

Marco Carugi proposed that existing technologies should be examined to
see how it can be used in PPVPN troubleshooting.  George agreed.
Kireeti said that Tom Nadeau is working on how to use LSP-PING
primitives with other protocols than MPLS, such as L2TPv3.  There was
general agreement that we need a document that discusses the total set
of tools that can be used in this context.


5.  MIBs

Multiprotocol Label Switching (MPLS) Traffic Engineering Management
   Information Base for Fast Reroute
http://www.ietf.org/internet-drafts/draft-ietf-mpls-fastreroute-mib-01.txt
Tom Nadeau

This draft defines a MIB module with managed objects for MPLS fast
rerouting.

Tom reported that the current status is that we've gained a lot of
experience and the MIB has been updated based on that, and is almost
ready for working group last call.  The major changes were adding full
support for both Facility and One-to-One backup.  The conformance
statement was updated to require either, but there is a common section
that is mandatory.  There are two implementations, and a third one is
on the way.  Tom is pretty confident that the MIB works and after the
next revision will be ready for working group last call.  Please send
comments to the mailing list.


Multiprotocol Label Switching (MPLS) Label-Controlled ATM and
   Frame-Relay Management Interface Definition
http://www.ietf.org/internet-drafts/draft-nadeau-mpls-lc-if-mib-00.txt
Tom Nadeau

This MIB module completes the picture for the base MPLS MIBs by
managing label-controlled Frame Relay and ATM MPLS interfaces (this
function was left out of the base MIBs).

It's been updated based upon MIB review and comments on the list.
Implementations have started, and feedback is coming in on that as
well.  He said that this should be progressed as a separate document
from the base MIBs, and be accepted as a WG document.

Very few people in the room have read the draft.  George asked for
more people to read it and comment.


Multiprotocol Label Switching (MPLS) Management Overview
http://www.ietf.org/internet-drafts/draft-ietf-mpls-mgmt-overview-03.txt

Tom also gave an update on the Management Overview document.  The
authors agree that the document is ready to progress because it
reflects all pending updates to the MPLS MIBs, including the TE MIB.
There will be a quick re-spin and Tom would like it go to last call at
that time.

George said that a last call will be issued shortly after the meeting.


6.  Explicitly routed Multicast

Requirements for Point-to-Multipoint capability extension
http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-p2mp-requirement-00.txt 

Seisho Yasukawa, yasukawa.seisho@lab.ntt.co.jp

This document presents a set of requirements for adding
Point-to-Multipoint (P2MP) traffic engineering to MPLS. It identifies
the functional and performance extensions required to realize
MPLS-based Content Distribution Networks. It also identifies
functional extensions required to implement CDN/VoIP/VPN service
convergence networks. These extensions can be used to provide high
performance and scalable broadband service network with MPLS.

Yasukawa-san discussed the requirements in terms of market trends in
the explosive growth of broadband subscribers, especially in Japan.
Service providers much create a new broadband service infrastructure
to meet this demand.  It must accommodate not only IP, but current
voice traffic as well.  Among applications for these services include
VoIP, VPNs, and content distribution, including IPTV, live
distribution, video conferencing, and VPN multicast.

There are a number of technical challenges to this sort of a service
network.  A primary challenge is that current MPLS mechanisms are not
optimized for multipoint distribution due to its point-to-point
nature.

The requirements in the draft include the coexistence of P2P and P2MP
LSP tunnels, P2MP path computation in the IGPs, P2MP LSP management
based on tree-based RRO, QoS control mechanism (SE/FF) for P2MP LSPs,
IPv4 and IPv6 support, interworking with IP multicast, and VPN
multicast support.

A number of possible broadband applications for this technology are
discussed in the draft.

Conclusion: P2MP MPLS is attractive technology for next generation
broadband IP service convergence network.  He proposed defining a P2MP
MPLS signaling protocol extension based on conventional RSVP-TE.

George said that this general topic is in the WG's overall charter,
but there needs to be a revision to the charter before this can become
a working group draft since there's no specific work task for this at
this time.

Philip Matthew remarked that there should be cross-pollination with
the MBONE-TE folks, since that is where many of these requirements are
being discussed.


Extended RSVP-TE for Point-to-Multipoint LSP Tunnels
http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-rsvp-p2mp-01.txt
Alan Kullberg, akullber@netplane.com

Point-to-multipoint technology will become increasingly important with
the dissemination of new, real-time applications, such as content
delivery services and video conferences, which require P2MP real-time
transmission capability with much more bandwidth and stricter QoS than
non-real-time applications.

This draft defines protocol extensions to RSVP-TE in order to
establish, maintain, and teardown a P2MP LSP. These extensions allow
service providers to offer services that utilize P2P and P2MP LSPs in
the same service network.

Alan talked about the changes in the draft from the first revision.
The point is to extend RFCs 2205, which supports multicast but not TE,
and 3209, which supports TE but not multicast, to support both
multicast and TE.

Alan asked for more feedback on the WG list, and he would like to make
it a WG draft.  Scott Bradner (SubIP Area Director) said that the IESG
needs to approve a charter change in order to add this as a new work
item for the WG.  It's premature to ask the WG to make this a WG
draft.


7.  Header Compression

George said by way of introduction that this set of drafts cannot be
accepted as MPLS working group items yet until after the Sub-IP
Directorate meeting later in the week, because these don't very
clearly sit in any particular working group or area at this time.
This work was first presented in the Adelaide meeting three years ago,
and its status has been very much unclear since then.


Requirements for End-to-End VoIP Header Compression
http://www.ietf.org/internet-drafts/draft-ash-e2e-voip-hdr-comp-rqmts-00.txt
Jerry Ash, gash@att.com

VoIP typically uses the encapsulation voice/RTP/UDP/IP.  When MPLS
labels are added, this becomes voice/RTP/UDP/IP/MPLS.  For an MPLS
VPN, the packet header is at least 48 bytes, while the voice payload
is typically no more than 30 bytes. VoIP header compression can
significantly reduce the VoIP overhead through various compression
mechanisms.  This is important on access links where bandwidth is
scarce, and can be important on backbone facilities, especially where
costs are high (e.g., some global cross-sections).  This draft gives a
problem statement and requirements for end-to-end VoIP header
compression, possibly over MPLS.

Jerry gave an overview of the list of requirements from the draft,
from providing efficient voice transport to robustness to packet loss
and delay minimization.  He discussed the background of the work
over the last three years, and then described the two proposed
solution drafts, using cRTP (RFC 2508) and end-to-end header
compression.


End-to-End VoIP Header Compression Using cRTP
http://www.ietf.org/internet-drafts/draft-ash-e2e-crtp-hdr-compress-01.txt

This draft proposes to re-use the methods in cRTP to determine the
header compression context and to use the cRTP session context ID to
route a compressed packet between the ingress and egress routers.


End-to-End VoIP over MPLS Header Compression
http://www.ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-01.txt

This draft proposes to use RSVP extensions to signal the header
compression context and other control messages between the ingress and
egress LSR.  It provides two approaches to determining the header
compression context: a) re-use the methods in cRTP to determine the
context, and b) re-use the methods in George Swallow's and Lou
Berger's "simple" approach to determine the context.

Scott is nervous about application-dependent solutions, and wanted
clarification on what "end-to-end" meant.  This means from voice
gateway to voice gateway, rather than true end station to end station.

The main issue is finding the right home for this work - some people
believe that the MPLS WG is the right place, and the authors would
like to propose that this is the right place.

Scott wanted to make sure that the authors were aware of the robust
header compression work ongoing in the transport area.  The answer is
yes.  In fact, the primary author of that work (Steve Casner) also
thinks this work belongs in the MPLS WG.

George and Scott agreed that this will be brought up in the Sub-IP
Directorate meeting.


8.  Draft Status Update

George Swallow

New RFCs
RFC 3443, TTL Processing in MPLS Networks (PS)
RFC 3469, Framework for MPLS-based Recovery (INF)
RFC 3477, Signaling Unnumbered Links in RSVP-TE (PS)
RFC 3478, Graceful Restart Mechanism for LDP (PS)
RFC 3479, Fault Tolerance for LDP and CR-LDP (PS)
RFC 3480, Signaling Unnumbered Links in CR-LDP (PS)

RFCs (On RFC Editor's Queue)
LSP Hierarchy with Generalized MPLS TE (PS)
http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-hierarchy-08.txt

George said this has been on the editor's queue for a long time.
Scott said that it's waiting for normative references.

Link Bundling in MPLS Traffic Engineering
http://www.ietf.org/internet-drafts/draft-ietf-mpls-bundle-04.txt

Including these two, there are now a total of 27 MPLS RFCs, so the WG
has been prolific.

IESG Last Call
MPLS LDP Query Message Description
http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-query-06.txt
Fast Reroute Extensions to RSVP-TE for LSP Tunnels
http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt 


IESG Evaluation
Improving Topology Data Base Accuracy with LSP Feedback
http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-05.txt

This is on the IESG agenda for the next teleconference, in two weeks.

Awaiting action on BGP Restart
Graceful Restart Mechanism for BGP with MPLS
http://www.ietf.org/internet-drafts/draft-ietf-mpls-bgp-mpls-restart-02.txt
Note: Last call in IDR working group - ends 11/29

Yakov Rekhter said that this is implemented by several vendors and
interoperable.  It is on hold in IDR until BGP is published.

Awaiting updates from Authors
MTU Signaling Extensions for LDP
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-mtu-extensions-00.txt

George asked Kireeti for the status.  Kireeti said that further
clarifications are needed, but he's been unable to contact his
coauthor.  He promised an update in the next month.  The last call
will need to be redone.

Multiprotocol Label Switching (MPLS) Traffic Engineering Management 
Information Base
http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-mib-09.txt
Multiprotocol Label Switching (MPLS) FEC-To-NHLFE (FTN) Management 
Information Base
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ftn-mib-05.txt

Bert Wijnen said that if we don't have the final versions of these
documents by the next IETF, they will all be put in the waste bin.
Tom is planning to send updated revisions soon.

Nearing completion
Detecting Data Plane Liveliness in MPLS
http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-02.txt

Other Drafts
Encapsulating MPLS in IP or GRE
http://www.ietf.org/internet-drafts/draft-ietf-mpls-in-ip-or-gre-00.txt

This is ready for working group last call.  A last call will be issued
after the meeting.

Applicability Statement for Restart Mechanisms for LDP
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-restart-applic-00.txt

Adrian said that he's waiting on what happens with the DoD restart
document, because it should be included in this document.  George
might rather get this out there first, since it will be an
informational RFC. There will be a WG last call after the meeting.


9. Charter Discussion

There will be a spin on the WG charter between now and the next
meeting.  If there are additions that people would like to be added to
the work plan, please put them on the list.

George is currently leaning towards adding an OAM framework document,
multi-area/multi-AS TE, soft preemption, and the point-to-multipoint
TE extensions.















From owner-mpls@UU.NET  Sat Mar 29 02:19:54 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15604
	for <mpls-archive@lists.ietf.org>; Sat, 29 Mar 2003 02:19:54 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoiaa14066
	for <mpls-archive@lists.ietf.org>; Fri, 28 Mar 2003 20:00:56 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoiaa13038;
	Fri, 28 Mar 2003 20:00:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQohzx07147
	for mpls-outgoing; Fri, 28 Mar 2003 19:25:31 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohzx07138
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Mar 2003 19:25:28 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohzx06268
	for <mpls@uu.net>; Fri, 28 Mar 2003 19:24:18 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohzx18145
	for <mpls@uu.net>; Fri, 28 Mar 2003 19:24:16 GMT
Received: from rtp-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQohzx17897
	for <mpls@uu.net>; Fri, 28 Mar 2003 19:24:08 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2SJO5iH000093
	for <mpls@uu.net>; Fri, 28 Mar 2003 14:24:06 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA04028 for <mpls@uu.net>; Fri, 28 Mar 2003 14:24:05 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2SJO5j19301 for mpls@uu.net; Fri, 28 Mar 2003 14:24:05 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQohzx07077
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Mar 2003 19:22:59 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQohzx01480
	for <mpls@UU.NET>; Fri, 28 Mar 2003 19:22:31 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQohzx15134
	for <mpls@UU.NET>; Fri, 28 Mar 2003 19:22:30 GMT
Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQohzx15085
	for <mpls@UU.NET>; Fri, 28 Mar 2003 19:22:29 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id NAA37922;
	Thu, 27 Mar 2003 13:39:10 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200303271839.NAA37922@workhorse.fictitious.org>
To: erosen@cisco.com
cc: jeremy.de_clercq@alcatel.be, David Allan <dallan@nortelnetworks.com>,
        "'Scott W Brim'" <sbrim@cisco.com>, pwe3@ietf.org, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: [PWE3] MPLS PID 
In-reply-to: Your message of "Thu, 27 Mar 2003 11:13:23 EST."
             <200303271613.h2RGDOiH028923@rtp-core-1.cisco.com> 
Date: Thu, 27 Mar 2003 13:39:10 -0500
From: Curtis Villamizar <curtis@fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <200303271613.h2RGDOiH028923@rtp-core-1.cisco.com>, Eric Rosen write
s:
> 
> Let's try to focus a little. 
> 
> 1. The  only  reason for  a  PID  field in  MPLS  and/or  PWE3  is to  allow
>    intermediate routers to determine whether a particular MPLS payload is an
>    IP packet or not. 
> 
>    There are a number  of reasons why this is useful, and  no one has argued
>    that this is not useful. 
> 
>    No one  has provided  a reason  why it might  be useful  for intermediate
>    routers to know, if the payload is not IP, what kind of packet it is.  
> 
> 2. The reason there is  no PID field in the MPLS header  is that there was a
>    consensus to keep the header as short as possible.
> 
> 3. The reason the PWE3 control word is optional is that there is a consensus
>    (apparently a continuing one) to  allow service providers to specify that
>    the header be kept as short as possible. 
> 
> 4. My conclusion from 2 and 3 is that there isn't much hope for any solution
>    which includes both a PWE3 control word AND a 4-byte MPLS PID field. 
> 
> 5. There is anyway  no way for the IETF to change  the basic MPLS forwarding
>    logic, at least  not in the time  frame over which one would  like to see
>    PWE3 deployments.
> 
> 5. My further  conclusion is that, as Mark has  suggested, the only possible
>    outcome  of a  discussion in  the MPLS  WG is  a recommendation  that any
>    non-IP application using  MPLS specify a control word  whose first nibble
>    is as Stewart has proposed for PWE3. 
> 
> 6. No one has given  a reason why the first nibble of  any such control word
>    should not be as Stewart has proposed.
> 
> 7. The PWE3 control word can be specified as a mandatory-to-implement option
>    which a SP  can disable if his environment is such  he doesn't care about
>    the absence of the PID. 
> 
> So I really think there is only one possible outcome.  The only issue is how
> much time  and breath we want  to waste until we  get there.  A  SP is faced
> with the choice of either:
> 
> a. Requiring the use of a Martini-style PID, or 
> 
> b. Ensuring that his pseudowires only carry non-order-sensitive traffic, or
> 
> c. Ensuring that  his PWE3 packets do not pass  through any MPLS environment
>    in which load balancing is done. 
> 
> Encapsulations which do not use the Martini-style control word are therefore
> at a  disadvantage.  We  should make sure  therefore that  any encapsulation
> which actually solves a problem for the industry has a control word with the
> first nibble as Stewart has proposed. 



Eric,

Nice summary.

What we can do is actually use the L3PID in MPLS and specify a value
for traffic with the packet type specified in the nibble, and a value
in this nibble to indicate that an ethertype is in the rest of the
first 32 byte entry rather than a PWE3 encapsulation to allow plain IP
mixed in and/or specify a value of L3PID indicating that a
Martini-style PID will be found.

The problems that we've run into in the past is what to put in L3PID
for hierarchical tunnels that have more than one L3PID in the tunnels
that go inside them.  This solves it.  If we go with the a scheme that
allows the per packet L3PID, then the hierarchical tunnels is the new
kind of "L3PID in the payload" encaps (or an abbreviated form) and
insert the L3PID of the payload if it isn't already there (which it
gets from the LSP it is putting inside the hierarchical tunnel.

We still have the case where a hierarchical tunnel has a setup request
with the L3PID of type MPLS (essentially saying "unknown") and all
that can be done for that type is the L3PID MPLS is put in the payload
so LSR along the way can see this packet as "unknown" type but others
as known types.

If you go with a short (nibble, or 2 byte) PID, or any PID which is
not based on ethertype like L3PID, then you complicate the algorithm
for determining what to put in the encaps at a hierarchical tunnel.

This feature would not have to be available on all LSR in a network,
but the more LSR with this at ingress or at the ingress to a
hierarchical LSP, the better.  The more midpoint LSR trying to do ECMP
that were aware of the new L3PID values, also the better.

Curtis



From owner-mpls@UU.NET  Sun Mar 30 06:04:43 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25184
	for <mpls-archive@lists.ietf.org>; Sun, 30 Mar 2003 06:04:43 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoiga13305
	for <mpls-archive@lists.ietf.org>; Sun, 30 Mar 2003 11:07:06 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoiga12018;
	Sun, 30 Mar 2003 11:06:33 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoify21973
	for mpls-outgoing; Sun, 30 Mar 2003 10:39:49 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoify21968
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 30 Mar 2003 10:39:40 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoify22705
	for <mpls@uu.net>; Sun, 30 Mar 2003 10:37:07 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoify07697
	for <mpls@uu.net>; Sun, 30 Mar 2003 10:37:06 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoify07684
	for <mpls@uu.net>; Sun, 30 Mar 2003 10:37:06 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2UAb3MR004510
	for <mpls@uu.net>; Sun, 30 Mar 2003 05:37:04 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id FAA06737 for <mpls@uu.net>; Sun, 30 Mar 2003 05:37:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2UAb3s01735 for mpls@uu.net; Sun, 30 Mar 2003 05:37:03 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoify21898
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 30 Mar 2003 10:36:20 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoify27403
	for <mpls@uu.net>; Sun, 30 Mar 2003 10:36:09 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoify13102
	for <mpls@uu.net>; Sun, 30 Mar 2003 10:36:08 GMT
Received: from bhcsciw by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [213.29.86.12])
	id QQoify12727
	for <mpls@uu.net>; Sun, 30 Mar 2003 10:36:01 GMT
Message-Id: <QQoify12727.200303301036@cmr2.ash.ops.us.uu.net>
From: Terminate Your DEBT <Terminatejrdj@ibm.com>
To: <mpls@UU.NET>
Subject: Stop harassing credit calls vg
Date: Sat, 29 Mar 2003 21:35:06 -0500
Mime-Version: 1.0
Content-Type: text/html
Content-Transfer-Encoding: base64
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5wZWNiam5jcnhlanduYWt4eGNsYXdobnFxY21tbHh5
YmVkY3BxZ2hybHNvYnRiYXRkbHRhdmpxbW1leTwvdGl0bGU+DQo8L2hlYWQ+DQo8Ym9keSBi
Z2NvbG9yPSIjRkZGRkZGIj4NCjxwPjxhIGhyZWY9Imh0dHA6Ly93d3cubXBsc0B2bGluZy1i
dXkuY29tL2NsZWFyZGVidC8/ZT1tcGxzQHV1Lm5ldCI+PGltZyBzcmM9Imh0dHA6Ly9tcGxz
QDY2LjE1MS41OS4xNTMvb25sb2FkLzQyNXg1MDBfYWRzLmpwZyIgYm9yZGVyPTAgd2lkdGg9
NDI1IGhlaWdodD01MDA+PC9hPg0KPHA+PGEgaHJlZj0iaHR0cDovL3d3dy5wZWNiam5jcnhl
anduYWt4eGNsYXdobnFxY21tbHh5YmVkY3BxZ2hybHNvYnRiYXRkbHRhdmpxbW1leUB2bGlu
Zy1idXkuY29tL2RlYnQvcmVtb3ZlLmh0bWwiPjxpbWcgc3JjPSJodHRwOi8vNjYuMTUxLjU5
LjE1My9vbmxvYWQvcmUuZ2lmIiBib3JkZXI9MCB3aWR0aD0yMDkgaGVpZ2h0PTIwPjwvYT4N
CjxwPiZuYnNwOzwvcD4NCjxwPiZuYnNwOzwvcD4NCjxmb250IGZhY2U9VmVyZGFuYSBzaXpl
PTE+YFZlcnkgZGVlcCwnIHNhaWQgQXJ0aHVyLCBgeW91IHNob3VsZCBzZW5kIHRoYXQgaW4g
dG8gdGhlICJSZWFkZXIncyBEaWdlc3QiLiBUaGV5J3ZlIGdvdCBhIHBhZ2UgZm9yIHBlb3Bs
ZSBsaWtlIHlvdS4nIjwvZm9udD4NCjwvYm9keT4NCjwvaHRtbD4NCg==



From owner-mpls@UU.NET  Sun Mar 30 13:13:56 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02073
	for <mpls-archive@lists.ietf.org>; Sun, 30 Mar 2003 13:13:56 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoihd16514
	for <mpls-archive@lists.ietf.org>; Sun, 30 Mar 2003 18:16:20 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoihc11896;
	Sun, 30 Mar 2003 18:14:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoihb01578
	for mpls-outgoing; Sun, 30 Mar 2003 17:48:33 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoihb01568
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 30 Mar 2003 17:48:25 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoihb24265
	for <mpls@uu.net>; Sun, 30 Mar 2003 17:47:12 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoihb10264
	for <mpls@uu.net>; Sun, 30 Mar 2003 17:47:10 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoihb10123
	for <mpls@uu.net>; Sun, 30 Mar 2003 17:47:04 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2UHl2MR007356
	for <mpls@uu.net>; Sun, 30 Mar 2003 12:47:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA17998 for <mpls@uu.net>; Sun, 30 Mar 2003 12:47:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2UHl1l20496 for mpls@uu.net; Sun, 30 Mar 2003 12:47:01 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoihb01287
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 30 Mar 2003 17:45:45 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoihb18207
	for <mpls@uu.net>; Sun, 30 Mar 2003 17:45:43 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoihb06719
	for <mpls@uu.net>; Sun, 30 Mar 2003 17:45:39 GMT
Received: from jpsphxt by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [211.248.60.131])
	id QQoihb06507
	for <mpls@uu.net>; Sun, 30 Mar 2003 17:45:34 GMT
Message-Id: <QQoihb06507.200303301745@cmr0.ash.ops.us.uu.net>
From: Viola Solomon <Jessiefsby@ibm.com>
To: <mpls@UU.NET>
Subject: Consolidate bills into one compact payment a
Date: Sun, 30 Mar 2003 12:50:04 -0500
Mime-Version: 1.0
Content-Type: text/html
Content-Transfer-Encoding: base64
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: base64

PGh0bWw+DQo8Ym9keT4NCjxwPjxhIGhyZWY9ICJodHRwOi8vd3d3Lm1wbHNAdmxpbmctYnV5
LmNvbS9jbGVhcmRlYnQvaW5kZXgyLnBocD9lPWhhYWNseWJsY3dkZHV2bWdyZmhod3V2cmci
PjxpbWcgc3JjPSAiaHR0cDovLzIxMC4yMi4xNDEuOTAvYy9jbzEuanBnIiBib3JkZXI9IjAi
IHdpZHRoPSI2MTIiIGhlaWdodD0iNDMwIj48L2E+IA0KPHA+VG8gb3B0LW91dCwgcGxlYXNl
IDxhIGhyZWY9Imh0dHA6Ly93d3cubXBsc0B2bGluZy1idXkuY29tL2RlYnQvcmVtb3ZlLmh0
bWwiPmNsaWNrIGhlcmUuPC9hPg0KPHA+Jm5ic3A7PC9wPg0KPHA+Jm5ic3A7PC9wPg0KPGZv
bnQgZmFjZT1WZXJkYW5hIHNpemU9MT4NCiJXaWxsIHRoZSBjb21wYW55IHBheSB0byByZWxv
Y2F0ZSBteSBob3JzZT8iDQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo=



From owner-mpls@UU.NET  Mon Mar 31 01:45:56 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15612
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 01:45:56 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoijb24284
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 06:48:18 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoijb20832;
	Mon, 31 Mar 2003 06:46:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoiiz25316
	for mpls-outgoing; Mon, 31 Mar 2003 06:17:09 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoiiz25307
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 06:16:59 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoiiz23853
	for <mpls@uu.net>; Mon, 31 Mar 2003 06:16:08 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoiiz13548
	for <mpls@uu.net>; Mon, 31 Mar 2003 06:16:08 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoiiz13501
	for <mpls@uu.net>; Mon, 31 Mar 2003 06:16:07 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2V6G3iH012468
	for <mpls@uu.net>; Mon, 31 Mar 2003 01:16:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id BAA12279 for <mpls@uu.net>; Mon, 31 Mar 2003 01:16:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2V6G3921453 for mpls@uu.net; Mon, 31 Mar 2003 01:16:03 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoiiy24839
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 06:14:59 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoiiy29774
	for <mpls@uu.net>; Mon, 31 Mar 2003 06:13:27 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoiiy00772
	for <mpls@uu.net>; Mon, 31 Mar 2003 06:13:26 GMT
Received: from dmz1.procket.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dmz1.procket.com [65.174.124.36])
	id QQoiiy00743
	for <mpls@uu.net>; Mon, 31 Mar 2003 06:13:25 GMT
Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60])
	by dmz1.procket.com (Postfix) with ESMTP
	id 14E1323C24; Sun, 30 Mar 2003 22:03:16 -0800 (PST)
Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7])
	by miata.procket.com (8.12.1/8.12.1) with ESMTP id h2V6DMYB018190;
	Sun, 30 Mar 2003 22:13:23 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2F74C.A1FCF630"
Subject: RE: VPLS and martini Ethernet encapsulation via MPLS and control word
Date: Sun, 30 Mar 2003 22:13:22 -0800
Message-ID: <D2EC481073504E498A8DB9C0687E8CAF06938AC1@EXCHANGE0-0.na.procket.com>
Thread-Topic: VPLS and martini Ethernet encapsulation via MPLS and control word
Thread-Index: AcLjdFgoYXG9U5zqSV2s23VQOIqEPAT15M5g
From: "Renwei Li" <renwei@procket.com>
To: "Per Hansen" <perflemming@hansen.mail.dk>, <zinin@psg.com>,
        <ppvpn@nortelnetworks.com>, <sob@harvard.edu>, <mpls@UU.NET>
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01C2F74C.A1FCF630
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Just for your information, Martini draft didn't specify the MPLS tunnel
label, although it suggests that an MPLS tunnel label may be used. As a
matter of fact, it can perfectly be transported over a L2TP tunnel. With
respect to the VC label, the draft is clear enough and it doesn't need
to specify anything about being different in an VPLS/MPLS swith with a
flat MPLS room. The VC label is only end-to-end significant.
=20
Renwei
-----Original Message-----
From: Per Hansen [mailto:perflemming@hansen.mail.dk]=20
Sent: Wednesday, March 05, 2003 3:26 PM
To: zinin@psg.com; ppvpn@nortelnetworks.com; sob@harvard.edu;
mpls@uu.net
Subject: VPLS and martini Ethernet encapsulation via MPLS and control
word


There seem to be a need for a technical check of whether the following
will fly
Together:
=20
    1) VPLS    (virtual Ethernet switching via MPLS)
    2) Martini Encapsulation of Ethernet packets via MPLS as
pseudo-wire.
    3) Flat MPLS room in an MPLS switch and MPLS/VPLS switch.=20
         (label room per switch, instead of per port).
=20
Do any have comments on this ?.
=20
Argument:
Martini Encapsulation specify both a tunnel MPLS label and a VC MPLS
label, where
The VC label default value is 5 for Ethernet packets. The last 5 value
(or more correct that
If the VC label value is the same for different martini tunnels), seem
potential to be
an implementation issue for martini tunnels if many of them needs to be
terminated
in a VPLS/MPLS switch with a flat MPLS room. =20
=20
Should it be stated somewhere, that the martiny VC label needs to be
different in an VPLS/MPLS
Switch with a flat MPLS room, or is this already clear enough ?.
=20
Furthermore martini encapsulation of Ethernet packets over MPLS also
introduce an control word, which is optional, and which is not a label.
Should it be stated somewhere, that remote ends,
Should be able not to send this to a VPLS/MPLS switch which terminate
the martini tunnel - or
Should it be stated that it is a requirement that a VPLS/MPLS switch
shall be configurable on
Each pseudo-wire with whether a  control word in the martini
encapsulation is included or not ?
=20
=20
------_=_NextPart_001_01C2F74C.A1FCF630--


From owner-mpls@UU.NET  Mon Mar 31 10:20:22 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10830
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 10:20:21 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoikj16853
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 15:22:46 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoikj16053;
	Mon, 31 Mar 2003 15:22:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoikh03225
	for mpls-outgoing; Mon, 31 Mar 2003 14:52:11 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoikh03199
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 14:52:04 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoikh29294
	for <mpls@uu.net>; Mon, 31 Mar 2003 14:51:05 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoikh28952
	for <mpls@uu.net>; Mon, 31 Mar 2003 14:51:04 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoikh28787
	for <mpls@uu.net>; Mon, 31 Mar 2003 14:51:00 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2VEotiH026815
	for <mpls@uu.net>; Mon, 31 Mar 2003 09:50:56 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA05623 for <mpls@uu.net>; Mon, 31 Mar 2003 09:50:55 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2VEotZ14737 for mpls@uu.net; Mon, 31 Mar 2003 09:50:55 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoihw15493
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 30 Mar 2003 23:13:02 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoihw23505
	for <mpls@uu.net>; Sun, 30 Mar 2003 23:11:39 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoihw21454
	for <mpls@uu.net>; Sun, 30 Mar 2003 23:11:38 GMT
Received: from prue.eim.surrey.ac.uk by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: prue.eim.surrey.ac.uk [131.227.76.5])
	id QQoihw21417
	for <mpls@uu.net>; Sun, 30 Mar 2003 23:11:38 GMT
Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw)
	by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4)
	id 18zlwv-0000CB-00; Mon, 31 Mar 2003 00:10:49 +0100
Date: Mon, 31 Mar 2003 00:10:46 +0100 (BST)
From: Lloyd Wood <l.wood@eim.surrey.ac.uk>
X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk
Reply-To: Lloyd Wood <L.Wood@eim.surrey.ac.uk>
To: Eric Rosen <erosen@cisco.com>
cc: jeremy.de_clercq@alcatel.be, David Allan <dallan@nortelnetworks.com>,
        "'Scott W Brim'" <sbrim@cisco.com>, "" <pwe3@ietf.org>,
        "" <mpls@UU.NET>
Subject: Re: [PWE3] MPLS PID 
In-Reply-To: <200303271613.h2RGDOiH028923@rtp-core-1.cisco.com>
Message-ID: <Pine.GSO.4.50.0303310006290.15438-100000@artemis.ee.surrey.ac.uk>
References: <200303271613.h2RGDOiH028923@rtp-core-1.cisco.com>
Organization: speaking for none
X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/
X-no-archive: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Status: No, hits=-131.4 required=5.5
	tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,
	      REPLY_WITH_QUOTES,USER_AGENT_PINE,USER_IN_WHITELIST
	autolearn=ham	version=2.50
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-Scanner: exiscan *18zlwv-0000CB-00*1W50cWxTJ/o* (SECM, UniS)
Sender: owner-mpls@UU.NET
Precedence: bulk

On Thu, 27 Mar 2003, Eric Rosen wrote:

> 1. The  only  reason for  a  PID  field in  MPLS  and/or  PWE3  is to  allow
>    intermediate routers to determine whether a particular MPLS payload is an
>    IP packet or not.

which is a layer violation, and shouldn't be done.

>    There are a number  of reasons why this is useful, and  no one has argued
>    that this is not useful.

not appropriate, more like.

if you're going to sniff for an IP packet (so you can sniff TCP/UDP or
higher) you might want to ask why you even have any form of mpls
label stack in there in the first place.

if you're not separating out your ip flows via explicit mpls label,
why not?

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood@ee.surrey.ac.uk>



From owner-mpls@UU.NET  Mon Mar 31 15:54:10 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23912
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 15:54:10 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilf02850
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 20:56:34 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoilf02066;
	Mon, 31 Mar 2003 20:56:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoiky24253
	for mpls-outgoing; Mon, 31 Mar 2003 19:09:06 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoiky24216
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 19:08:55 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoiky18553
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:07:06 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoiky22982
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:07:05 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoiky22967
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:07:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2VJ72iH022134
	for <mpls@uu.net>; Mon, 31 Mar 2003 14:07:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA00354 for <mpls@uu.net>; Mon, 31 Mar 2003 14:07:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2VJ72J29061 for mpls@uu.net; Mon, 31 Mar 2003 14:07:02 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoiky23761
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 19:05:29 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoiky10231
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:05:16 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoiky10552
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:05:16 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoiky10545
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:05:15 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2VJ5DMR002516
	for <mpls@uu.net>; Mon, 31 Mar 2003 14:05:14 -0500 (EST)
Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA00133 for <mpls@uu.net>; Mon, 31 Mar 2003 14:05:13 -0500 (EST)
Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA05296 for <mpls@uu.net>; Mon, 31 Mar 2003 14:05:13 -0500 (EST)
Message-Id: <200303311905.OAA05296@bifocal.cisco.com>
X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs
To: mpls@UU.NET
Reply-To: mpls@UU.NET
Subject: Check MPLS WG Consensus
Date: Mon, 31 Mar 2003 14:05:13 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

In San Francisco the workgroup showed support for making

  Definition of an RRO node-id subobject
    draft-vasseur-mpls-nodeid-subobject-00.txt

an MPLS WG Document.  This message is to solicit any further comments
prior to making a final determination.

Please reply by 4/7 24:00 GMT.

...George

======================================================================
George Swallow          Cisco Systems                   (978) 936-1398
                        250 Apollo Drive
                        Chelmsford, Ma 01824





From owner-mpls@UU.NET  Mon Mar 31 15:54:10 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23922
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 15:54:10 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilf02868
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 20:56:35 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoilf01961;
	Mon, 31 Mar 2003 20:56:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoiky24237
	for mpls-outgoing; Mon, 31 Mar 2003 19:09:01 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoiky24213
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 19:08:55 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoiky20316
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:08:05 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoiky23851
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:08:05 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoiky23847
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:08:04 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2VJ82iH022589
	for <mpls@uu.net>; Mon, 31 Mar 2003 14:08:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA00447 for <mpls@uu.net>; Mon, 31 Mar 2003 14:08:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2VJ81W29118 for mpls@uu.net; Mon, 31 Mar 2003 14:08:01 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoiky24047
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 19:06:40 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoiky28515
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:06:31 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoiky12654
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:06:30 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoiky12625
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:06:29 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2VJ6RMR002924
	for <mpls@uu.net>; Mon, 31 Mar 2003 14:06:28 -0500 (EST)
Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA00268 for <mpls@uu.net>; Mon, 31 Mar 2003 14:06:27 -0500 (EST)
Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA05305 for <mpls@uu.net>; Mon, 31 Mar 2003 14:06:27 -0500 (EST)
Message-Id: <200303311906.OAA05305@bifocal.cisco.com>
X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs
To: mpls@UU.NET
Reply-To: mpls@UU.NET
Subject: Check MPLS WG Consensus
Date: Mon, 31 Mar 2003 14:06:27 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

In San Francisco the workgroup showed support for making

  MPLS Traffic Engineering Soft preemption
    draft-meyer-mpls-soft-preemption-00.txt

an MPLS WG Document.  This message is to solicit any further comments
prior to making a final determination.

Please reply by 4/7 24:00 GMT.

...George

======================================================================
George Swallow          Cisco Systems                   (978) 936-1398
                        250 Apollo Drive
                        Chelmsford, Ma 01824





From owner-mpls@UU.NET  Mon Mar 31 15:57:35 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24034
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 15:57:35 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilf00769
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 20:59:59 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoilf29804;
	Mon, 31 Mar 2003 20:59:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoiky25010
	for mpls-outgoing; Mon, 31 Mar 2003 19:11:54 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoiky24996
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 19:11:34 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoiky24367
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:11:10 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoiky21266
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:11:09 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoiky21238
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:11:08 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2VJB5MR003940
	for <mpls@uu.net>; Mon, 31 Mar 2003 14:11:05 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA00833 for <mpls@uu.net>; Mon, 31 Mar 2003 14:11:05 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2VJB5E29263 for mpls@uu.net; Mon, 31 Mar 2003 14:11:05 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoiky24547
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 19:10:21 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoiky26828
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:09:31 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoiky25146
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:09:30 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoiky25138
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:09:30 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2VJ9SiH023074
	for <mpls@uu.net>; Mon, 31 Mar 2003 14:09:29 -0500 (EST)
Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA00674 for <mpls@uu.net>; Mon, 31 Mar 2003 14:09:28 -0500 (EST)
Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA05325 for <mpls@uu.net>; Mon, 31 Mar 2003 14:09:28 -0500 (EST)
Message-Id: <200303311909.OAA05325@bifocal.cisco.com>
X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs
To: mpls@UU.NET
Reply-To: mpls@UU.NET
Subject: Checking MPLS WG Consensus
Date: Mon, 31 Mar 2003 14:09:28 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

In San Francisco the workgroup showed support for making

  OAM Requirements for MPLS Networks
    draft-nadeau-ietf-oam-requirements-01.txt

an MPLS WG Document.  This message is to solicit any further comments
prior to making a final determination.

Please reply by 4/7 24:00 GMT.

...George

======================================================================
George Swallow          Cisco Systems                   (978) 936-1398
                        250 Apollo Drive
                        Chelmsford, Ma 01824





From owner-mpls@UU.NET  Mon Mar 31 16:02:47 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24375
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 16:02:47 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilg15993
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 21:05:12 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoilg15274;
	Mon, 31 Mar 2003 21:04:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoikz26004
	for mpls-outgoing; Mon, 31 Mar 2003 19:18:34 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoikz25996
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 19:18:23 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoikz02600
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:15:10 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoikz29346
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:15:09 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoikz29334
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:15:09 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2VJF6MR004604
	for <mpls@uu.net>; Mon, 31 Mar 2003 14:15:07 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA01254 for <mpls@uu.net>; Mon, 31 Mar 2003 14:15:06 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2VJF6f29624 for mpls@uu.net; Mon, 31 Mar 2003 14:15:06 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoiky25422
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 19:13:51 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoiky29791
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:13:16 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoiky01695
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:13:16 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoiky01686
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:13:15 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2VJDEiH025031
	for <mpls@uu.net>; Mon, 31 Mar 2003 14:13:14 -0500 (EST)
Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA01071 for <mpls@uu.net>; Mon, 31 Mar 2003 14:13:13 -0500 (EST)
Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA05418 for <mpls@uu.net>; Mon, 31 Mar 2003 14:13:13 -0500 (EST)
Message-Id: <200303311913.OAA05418@bifocal.cisco.com>
X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs
To: mpls@UU.NET
Reply-To: mpls@UU.NET
Subject: MPLS WG Last Call on
Date: Mon, 31 Mar 2003 14:13:13 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

This message begins an MPLS Workgroup last call on 

  Encapsulating MPLS in IP or GRE
    draft-ietf-mpls-in-ip-or-gre-00.txt

The last call closes 4/14 24:00 GMT.

...George

======================================================================
George Swallow          Cisco Systems                   (978) 936-1398
                        250 Apollo Drive
                        Chelmsford, Ma 01824





From owner-mpls@UU.NET  Mon Mar 31 16:02:51 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24398
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 16:02:51 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilg16110
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 21:05:17 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoilg15333;
	Mon, 31 Mar 2003 21:04:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoikz26007
	for mpls-outgoing; Mon, 31 Mar 2003 19:18:37 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoikz25998
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 19:18:28 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoikz16286
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:17:11 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoikz06383
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:17:10 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoikz06374
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:17:10 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2VJH7iH026671
	for <mpls@uu.net>; Mon, 31 Mar 2003 14:17:07 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA01488 for <mpls@uu.net>; Mon, 31 Mar 2003 14:17:05 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2VJH5g29853 for mpls@uu.net; Mon, 31 Mar 2003 14:17:05 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoiky25461
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 19:14:56 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoiky02486
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:14:19 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoiky02896
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:14:18 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoiky02887
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:14:18 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2VJEHiH025442
	for <mpls@uu.net>; Mon, 31 Mar 2003 14:14:17 -0500 (EST)
Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA01168 for <mpls@uu.net>; Mon, 31 Mar 2003 14:14:16 -0500 (EST)
Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA05427 for <mpls@uu.net>; Mon, 31 Mar 2003 14:14:16 -0500 (EST)
Message-Id: <200303311914.OAA05427@bifocal.cisco.com>
X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs
To: mpls@UU.NET
Reply-To: mpls@UU.NET
Subject: MPLS WG Last Call on
Date: Mon, 31 Mar 2003 14:14:16 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

This message begins an MPLS Workgroup last call on 

  Applicability Statement for Restart Mechanisms for LDP
    draft-ietf-mpls-ldp-restart-applic-00.txt

The last call closes 4/14 24:00 GMT.

...George

======================================================================
George Swallow          Cisco Systems                   (978) 936-1398
                        250 Apollo Drive
                        Chelmsford, Ma 01824





From owner-mpls@UU.NET  Mon Mar 31 16:02:51 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24403
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 16:02:51 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilg16115
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 21:05:17 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoilg15397;
	Mon, 31 Mar 2003 21:04:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoikz26013
	for mpls-outgoing; Mon, 31 Mar 2003 19:18:40 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoikz25999
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 19:18:33 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoikz02589
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:15:10 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoikz03598
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:15:09 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoikz03579
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:15:09 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2VJF6iH025740
	for <mpls@uu.net>; Mon, 31 Mar 2003 14:15:07 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA01252 for <mpls@uu.net>; Mon, 31 Mar 2003 14:15:06 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2VJF6J29619 for mpls@uu.net; Mon, 31 Mar 2003 14:15:06 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoiky25419
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 19:13:37 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoiky00636
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:08:20 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoiky15474
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:08:19 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoiky15452
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:08:18 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2VJ8HMR003292
	for <mpls@uu.net>; Mon, 31 Mar 2003 14:08:17 -0500 (EST)
Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA00505 for <mpls@uu.net>; Mon, 31 Mar 2003 14:08:16 -0500 (EST)
Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA05316 for <mpls@uu.net>; Mon, 31 Mar 2003 14:08:16 -0500 (EST)
Message-Id: <200303311908.OAA05316@bifocal.cisco.com>
X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs
To: mpls@UU.NET
Reply-To: mpls@UU.NET
Subject: Checking MPLS WG Consensus
Date: Mon, 31 Mar 2003 14:08:16 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

In San Francisco the workgroup showed support for making

  LDP DoD Graceful Restart
    draft-thomas-mpls-ldp-dod-restart-00.txt

an MPLS WG Document.  This message is to solicit any further comments
prior to making a final determination.

Please reply by 4/7 24:00 GMT.

...George

======================================================================
George Swallow          Cisco Systems                   (978) 936-1398
                        250 Apollo Drive
                        Chelmsford, Ma 01824





From owner-mpls@UU.NET  Mon Mar 31 16:04:02 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24477
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 16:04:02 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilg10634
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 21:06:28 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoilg10107;
	Mon, 31 Mar 2003 21:06:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoikz26457
	for mpls-outgoing; Mon, 31 Mar 2003 19:24:15 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoikz26448
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 19:24:11 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoikz17555
	for <mpls@UU.NET>; Mon, 31 Mar 2003 19:20:44 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoikz11401
	for <mpls@UU.NET>; Mon, 31 Mar 2003 19:20:43 GMT
Received: from zcars0m9.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157])
	id QQoikz11343
	for <mpls@UU.NET>; Mon, 31 Mar 2003 19:20:41 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2VJKSI03331;
	Mon, 31 Mar 2003 14:20:28 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <GDF40SL6>; Mon, 31 Mar 2003 14:20:28 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D016D2C32@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'George Swallow'" <swallow@cisco.com>, mpls@UU.NET
Subject: RE: Draft MPLS minutes
Date: Mon, 31 Mar 2003 14:20:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2F7BA.95766FE0"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2F7BA.95766FE0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi George:

Couple of comments on the minutes:

1) last name AllAn not AllEn
                ^

2) My comment on the requirements drafts was that it would be useful to have
an IETF stake in the ground w.r.t. requirements to help other SDOs, not that
the document was already in use.

cheers
Dave














------_=_NextPart_001_01C2F7BA.95766FE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: Draft MPLS minutes</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi George:</FONT>
</P>

<P><FONT SIZE=3D2>Couple of comments on the minutes:</FONT>
</P>

<P><FONT SIZE=3D2>1) last name AllAn not AllEn</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; ^</FONT>
</P>

<P><FONT SIZE=3D2>2) My comment on the requirements drafts was that it =
would be useful to have an IETF stake in the ground w.r.t. requirements =
to help other SDOs, not that the document was already in =
use.</FONT></P>

<P><FONT SIZE=3D2>cheers</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C2F7BA.95766FE0--


From owner-mpls@UU.NET  Mon Mar 31 16:05:46 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24549
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 16:05:46 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilg17243
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 21:08:12 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoilg16386;
	Mon, 31 Mar 2003 21:07:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoikz26765
	for mpls-outgoing; Mon, 31 Mar 2003 19:27:22 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoikz26722
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 19:27:13 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoikz18427
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:25:06 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoikz16125
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:25:06 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoikz16112
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:25:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2VJP2iH029569
	for <mpls@uu.net>; Mon, 31 Mar 2003 14:25:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA02390 for <mpls@uu.net>; Mon, 31 Mar 2003 14:25:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2VJP2P01346 for mpls@uu.net; Mon, 31 Mar 2003 14:25:02 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoikz26378
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 19:22:47 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoikz26748
	for <mpls@UU.NET>; Mon, 31 Mar 2003 19:21:36 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoikz18599
	for <mpls@UU.NET>; Mon, 31 Mar 2003 19:21:36 GMT
Received: from father.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: father.pmc-sierra.com [216.241.224.13])
	id QQoikz18585
	for <mpls@UU.NET>; Mon, 31 Mar 2003 19:21:35 GMT
Received: (qmail 15952 invoked by uid 104); 31 Mar 2003 19:21:24 -0000
Received: from Shahram_Davari@pmc-sierra.com by father by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4254.  Clear:. 
 Processed in 0.46933 secs); 31 Mar 2003 19:21:24 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by father.pmc-sierra.com with SMTP; 31 Mar 2003 19:21:23 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h2VJLN906457;
	Mon, 31 Mar 2003 11:21:23 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <H6VC0VTG>; Mon, 31 Mar 2003 11:21:23 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115C85E@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'George Swallow'" <swallow@cisco.com>, mpls@UU.NET
Subject: RE: Draft MPLS minutes
Date: Mon, 31 Mar 2003 11:21:20 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

>Shahram Davari said LSP-PING has become more complicated as the work
>on it has progressed, and that it now really isn't that much simpler
>than Y.1711.


It seems that I have been misquoted. A more accurate quote is:

"Shahram Davari said LSP-PING has become more complicated as the work
on it has progressed, and that it now neither simple nor efficient. This
fact has been recognized by the authors, and in fact an earlier text that
suggested LSP-PING is a simple and efficient protocol has been taken out of
the draft"


Thanks,
-Shahram



From owner-mpls@UU.NET  Mon Mar 31 16:09:48 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24683
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 16:09:48 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilg26428
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 21:12:13 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoilg26102;
	Mon, 31 Mar 2003 21:12:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoilb29368
	for mpls-outgoing; Mon, 31 Mar 2003 19:55:05 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoilb29332
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 19:54:52 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoilb20357
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:53:13 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilb25222
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:53:12 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoilb25215
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:53:12 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2VJr9iH009526
	for <mpls@uu.net>; Mon, 31 Mar 2003 14:53:10 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA05681 for <mpls@uu.net>; Mon, 31 Mar 2003 14:53:09 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2VJr9g06278 for mpls@uu.net; Mon, 31 Mar 2003 14:53:09 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoilb29197
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 19:52:08 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoilb01311
	for <mpls@UU.NET>; Mon, 31 Mar 2003 19:49:22 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilb07787
	for <mpls@UU.NET>; Mon, 31 Mar 2003 19:49:22 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoilb07776
	for <mpls@UU.NET>; Mon, 31 Mar 2003 19:49:21 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2VJnFMR008764;
	Mon, 31 Mar 2003 14:49:16 -0500 (EST)
Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA05202; Mon, 31 Mar 2003 14:49:15 -0500 (EST)
Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA05626; Mon, 31 Mar 2003 14:49:14 -0500 (EST)
Message-Id: <200303311949.OAA05626@bifocal.cisco.com>
X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs
To: "David Allan" <dallan@nortelnetworks.com>
cc: "'George Swallow'" <swallow@cisco.com>, mpls@UU.NET, swallow@cisco.com
Subject: Re: Draft MPLS minutes 
In-reply-to: Your message of "Mon, 31 Mar 2003 14:20:26 EST."
             <FFFC48AEAA5F7447929F4F0D93FCC12D016D2C32@zcard031.ca.nortel.com> 
Date: Mon, 31 Mar 2003 14:49:14 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Dave -

> Hi George:
> 
> Couple of comments on the minutes:
> 
> 1) last name AllAn not AllEn

My appologies!

> 2) My comment on the requirements drafts was that it would be useful to have
> an IETF stake in the ground w.r.t. requirements to help other SDOs, not that
> the document was already in use.

Noted and changed.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 936-1398
                     250 Apollo Drive
                     Chelmsford, Ma 01824



From owner-mpls@UU.NET  Mon Mar 31 16:54:24 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26860
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 16:54:23 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilj23760
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 21:56:49 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoilj23455;
	Mon, 31 Mar 2003 21:56:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoilh14558
	for mpls-outgoing; Mon, 31 Mar 2003 21:17:47 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoilh14553
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 21:17:46 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoilh27649
	for <mpls@uu.net>; Mon, 31 Mar 2003 21:17:07 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilh05349
	for <mpls@uu.net>; Mon, 31 Mar 2003 21:17:07 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoilh05332
	for <mpls@uu.net>; Mon, 31 Mar 2003 21:17:06 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2VLH3iH011227
	for <mpls@uu.net>; Mon, 31 Mar 2003 16:17:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA14401 for <mpls@uu.net>; Mon, 31 Mar 2003 16:17:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2VLH2s26791 for mpls@uu.net; Mon, 31 Mar 2003 16:17:02 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoilh14226
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 21:15:32 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoilg21781
	for <mpls@UU.NET>; Mon, 31 Mar 2003 21:13:24 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilg27158
	for <mpls@UU.NET>; Mon, 31 Mar 2003 21:13:24 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoilg27149
	for <mpls@UU.NET>; Mon, 31 Mar 2003 21:13:23 GMT
Received: from bucket.cisco.com (IDENT:mirapoint@bucket.cisco.com [161.44.167.72])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2VLDLMR017656
	for <mpls@UU.NET>; Mon, 31 Mar 2003 16:13:22 -0500 (EST)
Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-2-21.cisco.com [10.86.242.21])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ACV90747;
	Mon, 31 Mar 2003 16:13:20 -0500 (EST)
Message-Id: <5.2.0.9.2.20030331161300.04d36190@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 31 Mar 2003 16:13:11 -0500
To: mpls@UU.NET, mpls@UU.NET
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: Checking MPLS WG Consensus
In-Reply-To: <200303311908.OAA05316@bifocal.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


         In favor.

         --Tom

>In San Francisco the workgroup showed support for making
>
>   LDP DoD Graceful Restart
>     draft-thomas-mpls-ldp-dod-restart-00.txt
>
>an MPLS WG Document.  This message is to solicit any further comments
>prior to making a final determination.
>
>Please reply by 4/7 24:00 GMT.
>
>...George
>
>======================================================================
>George Swallow          Cisco Systems                   (978) 936-1398
>                         250 Apollo Drive
>                         Chelmsford, Ma 01824


http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X




From owner-mpls@UU.NET  Mon Mar 31 16:55:59 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26926
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 16:55:59 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilj25878
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 21:58:25 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoilj25491;
	Mon, 31 Mar 2003 21:58:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoilh14653
	for mpls-outgoing; Mon, 31 Mar 2003 21:19:27 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoilh14646
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 21:19:23 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoilh11099
	for <mpls@uu.net>; Mon, 31 Mar 2003 21:19:07 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilh09919
	for <mpls@uu.net>; Mon, 31 Mar 2003 21:19:06 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoilh09896
	for <mpls@uu.net>; Mon, 31 Mar 2003 21:19:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2VLJ3iH011911
	for <mpls@uu.net>; Mon, 31 Mar 2003 16:19:03 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA14556 for <mpls@uu.net>; Mon, 31 Mar 2003 16:19:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2VLJ2O26984 for mpls@uu.net; Mon, 31 Mar 2003 16:19:02 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoilh14546
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 21:17:31 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoilh21643
	for <mpls@UU.NET>; Mon, 31 Mar 2003 21:15:55 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilh29626
	for <mpls@UU.NET>; Mon, 31 Mar 2003 21:15:54 GMT
Received: from rtp-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoilh29618
	for <mpls@UU.NET>; Mon, 31 Mar 2003 21:15:54 GMT
Received: from bucket.cisco.com (IDENT:mirapoint@bucket.cisco.com [161.44.167.72])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2VLFqMR017880
	for <mpls@UU.NET>; Mon, 31 Mar 2003 16:15:52 -0500 (EST)
Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-2-21.cisco.com [10.86.242.21])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ACV90801;
	Mon, 31 Mar 2003 16:15:51 -0500 (EST)
Message-Id: <5.2.0.9.2.20030331161533.04e57898@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 31 Mar 2003 16:15:44 -0500
To: mpls@UU.NET
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: Check MPLS WG Consensus
In-Reply-To: <200303311905.OAA05296@bifocal.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


         In favor.

         --Tom

>In San Francisco the workgroup showed support for making
>
>   Definition of an RRO node-id subobject
>     draft-vasseur-mpls-nodeid-subobject-00.txt
>
>an MPLS WG Document.  This message is to solicit any further comments
>prior to making a final determination.
>
>Please reply by 4/7 24:00 GMT.
>
>...George
>
>======================================================================
>George Swallow          Cisco Systems                   (978) 936-1398
>                         250 Apollo Drive
>                         Chelmsford, Ma 01824


http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X




From owner-mpls@UU.NET  Mon Mar 31 16:59:15 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27002
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 16:59:15 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilk07084
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 22:01:41 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoilk06495;
	Mon, 31 Mar 2003 22:01:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoilh15089
	for mpls-outgoing; Mon, 31 Mar 2003 21:25:48 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoilh15074
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 21:25:41 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoilh05250
	for <mpls@uu.net>; Mon, 31 Mar 2003 21:21:08 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilh15118
	for <mpls@uu.net>; Mon, 31 Mar 2003 21:21:08 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoilh15092
	for <mpls@uu.net>; Mon, 31 Mar 2003 21:21:07 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2VLL5iH012748
	for <mpls@uu.net>; Mon, 31 Mar 2003 16:21:05 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA14791 for <mpls@uu.net>; Mon, 31 Mar 2003 16:21:04 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2VLL4g27157 for mpls@uu.net; Mon, 31 Mar 2003 16:21:04 -0500 (EST)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoilh14667
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 21:20:00 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoilh25240
	for <mpls@UU.NET>; Mon, 31 Mar 2003 21:19:09 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilh10033
	for <mpls@UU.NET>; Mon, 31 Mar 2003 21:19:08 GMT
Received: from rtp-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoilh09999
	for <mpls@UU.NET>; Mon, 31 Mar 2003 21:19:08 GMT
Received: from bucket.cisco.com (IDENT:mirapoint@bucket.cisco.com [161.44.167.72])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2VLHEiH011277
	for <mpls@UU.NET>; Mon, 31 Mar 2003 16:17:15 -0500 (EST)
Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-2-21.cisco.com [10.86.242.21])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ACV90839;
	Mon, 31 Mar 2003 16:17:11 -0500 (EST)
Message-Id: <5.2.0.9.2.20030331161642.03039f20@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 31 Mar 2003 16:17:06 -0500
To: mpls@UU.NET
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: Check MPLS WG Consensus
In-Reply-To: <200303311906.OAA05305@bifocal.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


         In favor.

         --Tom

>In San Francisco the workgroup showed support for making
>
>   MPLS Traffic Engineering Soft preemption
>     draft-meyer-mpls-soft-preemption-00.txt
>
>an MPLS WG Document.  This message is to solicit any further comments
>prior to making a final determination.
>
>Please reply by 4/7 24:00 GMT.
>
>...George
>
>======================================================================
>George Swallow          Cisco Systems                   (978) 936-1398
>                         250 Apollo Drive
>                         Chelmsford, Ma 01824


http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X




From owner-mpls@UU.NET  Mon Mar 31 18:19:39 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01992
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 18:19:39 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilp19627
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 23:22:00 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoilp18920;
	Mon, 31 Mar 2003 23:21:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoill09200
	for mpls-outgoing; Mon, 31 Mar 2003 22:27:28 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoill09193
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 22:27:21 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoill16197
	for <mpls@uu.net>; Mon, 31 Mar 2003 22:27:11 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoill27844
	for <mpls@uu.net>; Mon, 31 Mar 2003 22:27:10 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoill27839
	for <mpls@uu.net>; Mon, 31 Mar 2003 22:27:10 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2VMR7MR026726
	for <mpls@uu.net>; Mon, 31 Mar 2003 17:27:08 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA20463 for <mpls@uu.net>; Mon, 31 Mar 2003 17:27:07 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2VMR7h07791 for mpls@uu.net; Mon, 31 Mar 2003 17:27:07 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoill09176
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 22:26:18 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoill10738
	for <mpls@UU.NET>; Mon, 31 Mar 2003 22:24:57 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoill25743
	for <mpls@UU.NET>; Mon, 31 Mar 2003 22:24:57 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoill25728
	for <mpls@UU.NET>; Mon, 31 Mar 2003 22:24:56 GMT
Received: from zaliw2k01 (che-vpn-cluster-2-80.cisco.com [10.86.242.80])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2VMOsiH006544
	for <mpls@UU.NET>; Mon, 31 Mar 2003 17:24:54 -0500 (EST)
From: "zafar ali" <zali@cisco.com>
To: <mpls@UU.NET>
Subject: RE: Check MPLS WG Consensus
Date: Mon, 31 Mar 2003 17:24:53 -0500
Message-ID: <000301c2f7d4$5af37fb0$91053918@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <200303311906.OAA05305@bifocal.cisco.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



Thanks
 
Regards... Zafar


> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf 
> Of George Swallow
> Sent: Monday, March 31, 2003 2:06 PM
> To: mpls@UU.NET
> Subject: Check MPLS WG Consensus
> 
> 
> In San Francisco the workgroup showed support for making
> 
>   MPLS Traffic Engineering Soft preemption
>     draft-meyer-mpls-soft-preemption-00.txt
> 
> an MPLS WG Document. 

Hi, 

I agree with the WG for support of this draft. 

Thanks
 
Regards... Zafar

> This message is to solicit any further 
> comments prior to making a final determination.
> 
> Please reply by 4/7 24:00 GMT.
> 
> ...George
> 
> ======================================================================
> George Swallow          Cisco Systems                   (978) 936-1398
>                         250 Apollo Drive
>                         Chelmsford, Ma 01824
> 
> 
> 
> 



From owner-mpls@UU.NET  Mon Mar 31 18:19:46 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02007
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 18:19:46 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilp22804
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 23:22:10 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoilp22160;
	Mon, 31 Mar 2003 23:21:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoill09209
	for mpls-outgoing; Mon, 31 Mar 2003 22:27:48 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoill09202
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 22:27:32 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoill23133
	for <mpls@uu.net>; Mon, 31 Mar 2003 22:26:16 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoill27121
	for <mpls@uu.net>; Mon, 31 Mar 2003 22:26:16 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoill27116
	for <mpls@uu.net>; Mon, 31 Mar 2003 22:26:16 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2VMQDMR026648
	for <mpls@uu.net>; Mon, 31 Mar 2003 17:26:13 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA20381 for <mpls@uu.net>; Mon, 31 Mar 2003 17:26:12 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2VMQCP07720 for mpls@uu.net; Mon, 31 Mar 2003 17:26:12 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoill08968
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 22:24:51 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoill18450
	for <mpls@UU.NET>; Mon, 31 Mar 2003 22:24:12 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoill25171
	for <mpls@UU.NET>; Mon, 31 Mar 2003 22:24:12 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoill25166
	for <mpls@UU.NET>; Mon, 31 Mar 2003 22:24:11 GMT
Received: from zaliw2k01 (che-vpn-cluster-2-80.cisco.com [10.86.242.80])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2VMO8iH006340
	for <mpls@UU.NET>; Mon, 31 Mar 2003 17:24:09 -0500 (EST)
From: "zafar ali" <zali@cisco.com>
To: <mpls@UU.NET>
Subject: RE: Checking MPLS WG Consensus
Date: Mon, 31 Mar 2003 17:24:08 -0500
Message-ID: <000201c2f7d4$40126530$91053918@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <200303311909.OAA05325@bifocal.cisco.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf 
> Of George Swallow
> Sent: Monday, March 31, 2003 2:09 PM
> To: mpls@UU.NET
> Subject: Checking MPLS WG Consensus
> 
> 
> In San Francisco the workgroup showed support for making
> 
>   OAM Requirements for MPLS Networks
>     draft-nadeau-ietf-oam-requirements-01.txt
> 
> an MPLS WG Document.  

Hi, 

I agree with the WG for the support of this draft. 

Thanks
 
Regards... Zafar

> This message is to solicit any further 
> comments prior to making a final determination.
> 
> Please reply by 4/7 24:00 GMT.
> 
> ...George
> 
> ======================================================================
> George Swallow          Cisco Systems                   (978) 936-1398
>                         250 Apollo Drive
>                         Chelmsford, Ma 01824
> 
> 
> 
> 



From owner-mpls@UU.NET  Mon Mar 31 18:20:58 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02034
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 18:20:58 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilp28621
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 23:23:23 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoilp28224;
	Mon, 31 Mar 2003 23:23:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoill09299
	for mpls-outgoing; Mon, 31 Mar 2003 22:29:44 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoill09288
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 22:29:38 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoill01592
	for <mpls@uu.net>; Mon, 31 Mar 2003 22:29:08 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoill00303
	for <mpls@uu.net>; Mon, 31 Mar 2003 22:29:08 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoill00295
	for <mpls@uu.net>; Mon, 31 Mar 2003 22:29:08 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2VMT5MR026905
	for <mpls@uu.net>; Mon, 31 Mar 2003 17:29:05 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA20589 for <mpls@uu.net>; Mon, 31 Mar 2003 17:29:04 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2VMT4Q07877 for mpls@uu.net; Mon, 31 Mar 2003 17:29:04 -0500 (EST)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoill09228
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 22:28:17 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoill22665
	for <mpls@UU.NET>; Mon, 31 Mar 2003 22:23:44 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoill24631
	for <mpls@UU.NET>; Mon, 31 Mar 2003 22:23:44 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoill24623
	for <mpls@UU.NET>; Mon, 31 Mar 2003 22:23:44 GMT
Received: from zaliw2k01 (che-vpn-cluster-2-80.cisco.com [10.86.242.80])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2VMNfiH006223
	for <mpls@UU.NET>; Mon, 31 Mar 2003 17:23:42 -0500 (EST)
From: "zafar ali" <zali@cisco.com>
To: <mpls@UU.NET>
Subject: RE: Checking MPLS WG Consensus
Date: Mon, 31 Mar 2003 17:23:40 -0500
Message-ID: <000101c2f7d4$2f9ed120$91053918@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <200303311908.OAA05316@bifocal.cisco.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf 
> Of George Swallow
> Sent: Monday, March 31, 2003 2:08 PM
> To: mpls@UU.NET
> Subject: Checking MPLS WG Consensus
> 
> 
> In San Francisco the workgroup showed support for making
> 
>   LDP DoD Graceful Restart
>     draft-thomas-mpls-ldp-dod-restart-00.txt
> 
> an MPLS WG Document.  

Hi, 

I agree with the WG for the support of this draft. 

Thanks
 
Regards... Zafar

> This message is to solicit any further 
> comments prior to making a final determination.
> 
> Please reply by 4/7 24:00 GMT.
> 
> ...George
> 
> ======================================================================
> George Swallow          Cisco Systems                   (978) 936-1398
>                         250 Apollo Drive
>                         Chelmsford, Ma 01824
> 
> 
> 
> 



From owner-mpls@UU.NET  Mon Mar 31 18:26:58 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02189
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 18:26:58 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilp08536
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 23:29:22 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoilp08028;
	Mon, 31 Mar 2003 23:29:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoilm10363
	for mpls-outgoing; Mon, 31 Mar 2003 22:42:48 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoilm10350
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 22:42:42 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoilm02281
	for <mpls@uu.net>; Mon, 31 Mar 2003 22:42:16 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilm18617
	for <mpls@uu.net>; Mon, 31 Mar 2003 22:42:15 GMT
Received: from rtp-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoilm18608
	for <mpls@uu.net>; Mon, 31 Mar 2003 22:42:15 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2VMgCMR028129
	for <mpls@uu.net>; Mon, 31 Mar 2003 17:42:12 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA21527 for <mpls@uu.net>; Mon, 31 Mar 2003 17:42:12 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h2VMg8v09598 for mpls@uu.net; Mon, 31 Mar 2003 17:42:08 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoilm10128
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 31 Mar 2003 22:40:53 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQoilm28625
	for <mpls@UU.NET>; Mon, 31 Mar 2003 22:40:48 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilm16934
	for <mpls@UU.NET>; Mon, 31 Mar 2003 22:40:47 GMT
Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [216.241.224.12])
	id QQoilm16839
	for <mpls@UU.NET>; Mon, 31 Mar 2003 22:40:42 GMT
Received: (qmail 4919 invoked by uid 104); 31 Mar 2003 22:40:41 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4254.  Clear:. 
 Processed in 0.481232 secs); 31 Mar 2003 22:40:41 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by mother.pmc-sierra.com with SMTP; 31 Mar 2003 22:40:40 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h2VMee922905;
	Mon, 31 Mar 2003 14:40:40 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <H6VC05Q7>; Mon, 31 Mar 2003 14:40:39 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115C867@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Lloyd Wood'" <L.Wood@eim.surrey.ac.uk>
Cc: pwe3@ietf.org, mpls@UU.NET
Subject: RE: [PWE3] MPLS PID 
Date: Mon, 31 Mar 2003 14:40:29 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

I agree with Lloyd. Sniffing IP packets in the middle of an MPLS network is fundamentally wrong, and is impossible to do for all ECMP implementations such as the one that I described
in earlier emails in which both the first nibble and the CRC are used to detect IP.

The best way to solve this problem is to do ECMP only based on label stack. Doing so should be
easier than introducing new standard.

-Shahram


>-----Original Message-----
>From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk]
>Sent: Sunday, March 30, 2003 6:11 PM
>To: Eric Rosen
>Cc: jeremy.de_clercq@alcatel.be; David Allan; 'Scott W Brim';
>pwe3@ietf.org; mpls@UU.NET
>Subject: Re: [PWE3] MPLS PID 
>
>
>On Thu, 27 Mar 2003, Eric Rosen wrote:
>
>> 1. The  only  reason for  a  PID  field in  MPLS  and/or  
>PWE3  is to  allow
>>    intermediate routers to determine whether a particular 
>MPLS payload is an
>>    IP packet or not.
>
>which is a layer violation, and shouldn't be done.
>
>>    There are a number  of reasons why this is useful, and  
>no one has argued
>>    that this is not useful.
>
>not appropriate, more like.
>
>if you're going to sniff for an IP packet (so you can sniff TCP/UDP or
>higher) you might want to ask why you even have any form of mpls
>label stack in there in the first place.
>
>if you're not separating out your ip flows via explicit mpls label,
>why not?
>
>L.
>
><http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood@ee.surrey.ac.uk>
>_______________________________________________
>pwe3 mailing list
>pwe3@ietf.org
>https://www1.ietf.org/mailman/listinfo/pwe3
>



From owner-mpls@UU.NET  Mon Mar 31 20:15:39 2003
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05628
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 20:15:39 -0500 (EST)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilx26534
	for <mpls-archive@lists.ietf.org>; Tue, 1 Apr 2003 01:18:04 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoilx26088;
	Tue, 1 Apr 2003 01:17:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoilv28049
	for mpls-outgoing; Tue, 1 Apr 2003 00:46:51 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQoilv28023
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 1 Apr 2003 00:46:33 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQoilv14830
	for <mpls@uu.net>; Tue, 1 Apr 2003 00:45:05 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilv25159
	for <mpls@uu.net>; Tue, 1 Apr 2003 00:45:05 GMT
Received: from rtp-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-1.cisco.com [64.102.124.12])
	id QQoilv25151
	for <mpls@uu.net>; Tue, 1 Apr 2003 00:45:05 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h310j2iH029292
	for <mpls@uu.net>; Mon, 31 Mar 2003 19:45:02 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA28724 for <mpls@uu.net>; Mon, 31 Mar 2003 19:45:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h310j1I23809 for mpls@uu.net; Mon, 31 Mar 2003 19:45:01 -0500 (EST)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoilu27281
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 1 Apr 2003 00:42:38 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoilu20075
	for <mpls@UU.NET>; Tue, 1 Apr 2003 00:42:20 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilu07139
	for <mpls@UU.NET>; Tue, 1 Apr 2003 00:42:19 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoilu07132
	for <mpls@UU.NET>; Tue, 1 Apr 2003 00:42:19 GMT
Received: from pilgrim.cisco.com (pilgrim.cisco.com [161.44.168.94])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h310fZMR007718;
	Mon, 31 Mar 2003 19:41:35 -0500 (EST)
Received: from tappan-w2k01.cisco.com (tappan-frame1.cisco.com [10.83.99.138])
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA13558;
	Mon, 31 Mar 2003 19:41:34 -0500 (EST)
Message-Id: <4.3.2.7.2.20030331183613.02ae4608@pilgrim.cisco.com>
X-Sender: tappan@pilgrim.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 31 Mar 2003 19:41:33 -0500
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
From: Dan Tappan <tappan@cisco.com>
Subject: RE: [PWE3] MPLS PID 
Cc: "'Lloyd Wood'" <L.Wood@eim.surrey.ac.uk>, pwe3@ietf.org, mpls@UU.NET
In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C867@nt-exch-yow.pmc-s
 ierra.bc.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 02:40 PM 3/31/2003 -0800, Shahram Davari wrote:
>I agree with Lloyd. Sniffing IP packets in the middle of an MPLS network 
>is fundamentally wrong, and is impossible to do for all ECMP 
>implementations such as the one that I described
>in earlier emails in which both the first nibble and the CRC are used to 
>detect IP.
>
>The best way to solve this problem is to do ECMP only based on label stack.

You keep talking about using the label stack. Consider the case:
- at the end of an LSP, where the forwarding operation is "pop and forward"
- and where the packets being carried are IP
- and there is ECMP on the output paths

How is one supposed to make the ECMP decision in that case? There's only 
one label, so hashing on the label stack will only choose a single path.

And don't say "well, it's ok to look at the IP packet in that case". If 
it's "fundamentally wrong" to look at the data, as opposed to the label(s), 
in the packet to make an ECMP decision in the middle of the LSP, then it's 
"fundamentally wrong" at the end.

Or is that case acceptable, because the particular pre-standard 
implementation that you're trying to protect won't encounter it?

Is it a layer violation for an IP ECMP implementation to look at the 
TCP/UDP ports when spreading the traffic over paths? Or to look under an 
IPinIP tunnel header? Or for a WFQ implementation to look at any packet 
fields? Maybe, but there can be practical value in doing so.

For that matter, if we're worrying about layer violations, why is it ok to 
look below the top label (as in "hash the label stack"). Isn't that also a 
layer violation?

If your answer is "you know what the labels are, but you don't know that 
what the encapsulated data is" then that's the whole point of this PID 
discussion.

IMO, if you want to make an argument based on architectural purity and 
"layering" then you need to stick with the top label. In any other case 
we've decided what we are,  we're just arguing over the price.

But, in fact I don't accept that any of these are layer violations. In all 
these cases, the fundamental forwarding decision is on the outermost 
header. Any examination of underlying data is simply selecting finer 
granularity of flows.  In most of these discussions "layer violation" is 
simply a debating trick, holding out for OSI architectural purity as when 
all else fails.

As I see it there are two possible approaches:

1. Require that an LSP set up for an IP L3PID or IP FEC carry IP packets.
2. Allow non-IP packets on such an LSP, but require that they be 
distinguishable.

The simple facts are:
- it turns out that [2] has value operationally, otherwise we wouldn't be 
having this discussion
-  there is a proposal on the table which provides a backward compatible 
way to achieve [2], without affecting any fielded, standardized, 
implementations.
-  the only negative impact of the proposal is on existing implementations 
of pre-standard drafts. And we all know the risks of implementing prior to 
standardization. Even there, an operator can deploy the pre-standard 
implementation, as long as they avoid [2].

Why isn't this a no-brainer?





From owner-mpls@UU.NET  Mon Mar 31 20:35:22 2003
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06334
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 20:35:22 -0500 (EST)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoily26614
	for <mpls-archive@lists.ietf.org>; Tue, 1 Apr 2003 01:37:47 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoily26416;
	Tue, 1 Apr 2003 01:37:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoilw17350
	for mpls-outgoing; Tue, 1 Apr 2003 01:06:05 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQoilw17164
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 1 Apr 2003 01:05:56 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoilw13562
	for <mpls@uu.net>; Tue, 1 Apr 2003 01:05:15 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilw06426
	for <mpls@uu.net>; Tue, 1 Apr 2003 01:05:14 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoilw06412
	for <mpls@uu.net>; Tue, 1 Apr 2003 01:05:14 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3115BMR009192
	for <mpls@uu.net>; Mon, 31 Mar 2003 20:05:11 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA29699 for <mpls@uu.net>; Mon, 31 Mar 2003 20:05:11 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h3115Bo26307 for mpls@uu.net; Mon, 31 Mar 2003 20:05:11 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoilw16606
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 1 Apr 2003 01:04:15 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoilw07479
	for <mpls@UU.NET>; Tue, 1 Apr 2003 01:04:08 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilw05169
	for <mpls@UU.NET>; Tue, 1 Apr 2003 01:04:07 GMT
Received: from ams-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ams-msg-core-1.cisco.com [144.254.74.60])
	id QQoilw05157
	for <mpls@UU.NET>; Tue, 1 Apr 2003 01:04:06 GMT
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h3112KiX000738
	for <mpls@UU.NET>; Tue, 1 Apr 2003 03:02:20 +0200 (MET DST)
Received: from JVASSEUR-W2K.cisco.com (sjc-vpn3-624.cisco.com [10.21.66.112])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id DAA24081;
	Tue, 1 Apr 2003 03:04:04 +0200 (MET DST)
Message-Id: <4.3.2.7.2.20030331200353.06f3a248@paris.cisco.com>
X-Sender: jvasseur@paris.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 31 Mar 2003 20:04:02 -0500
To: mpls@UU.NET
From: Jean Philippe Vasseur <jvasseur@cisco.com>
Subject: Re: Checking MPLS WG Consensus
Cc: mpls@UU.NET
In-Reply-To: <200303311909.OAA05325@bifocal.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

in favor

JP.

At 14:09 31/03/2003 -0500, George Swallow wrote:
>In San Francisco the workgroup showed support for making
>
>   OAM Requirements for MPLS Networks
>     draft-nadeau-ietf-oam-requirements-01.txt
>
>an MPLS WG Document.  This message is to solicit any further comments
>prior to making a final determination.
>
>Please reply by 4/7 24:00 GMT.
>
>...George
>
>======================================================================
>George Swallow          Cisco Systems                   (978) 936-1398
>                         250 Apollo Drive
>                         Chelmsford, Ma 01824



From owner-mpls@UU.NET  Mon Mar 31 22:39:11 2003
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09082
	for <mpls-archive@lists.ietf.org>; Mon, 31 Mar 2003 22:39:10 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoily03730
	for <mpls-archive@lists.ietf.org>; Tue, 1 Apr 2003 01:40:02 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQoily03451;
	Tue, 1 Apr 2003 01:39:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQoilw17553
	for mpls-outgoing; Tue, 1 Apr 2003 01:08:26 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQoilw17545
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 1 Apr 2003 01:08:22 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoilw28306
	for <mpls@uu.net>; Tue, 1 Apr 2003 01:05:11 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilw06340
	for <mpls@uu.net>; Tue, 1 Apr 2003 01:05:11 GMT
Received: from rtp-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-core-2.cisco.com [64.102.124.13])
	id QQoilw06323
	for <mpls@uu.net>; Tue, 1 Apr 2003 01:05:10 GMT
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79])
	by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h31157MR009177
	for <mpls@uu.net>; Mon, 31 Mar 2003 20:05:08 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA29695 for <mpls@uu.net>; Mon, 31 Mar 2003 20:05:07 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id h31157U26220 for mpls@uu.net; Mon, 31 Mar 2003 20:05:07 -0500 (EST)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQoilw16556
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 1 Apr 2003 01:04:02 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQoilw06764
	for <mpls@UU.NET>; Tue, 1 Apr 2003 01:03:52 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQoilw04872
	for <mpls@UU.NET>; Tue, 1 Apr 2003 01:03:51 GMT
Received: from ams-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ams-msg-core-1.cisco.com [144.254.74.60])
	id QQoilw04851
	for <mpls@UU.NET>; Tue, 1 Apr 2003 01:03:50 GMT
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h31123as000729
	for <mpls@UU.NET>; Tue, 1 Apr 2003 03:02:04 +0200 (MET DST)
Received: from JVASSEUR-W2K.cisco.com (sjc-vpn3-624.cisco.com [10.21.66.112])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id DAA24071;
	Tue, 1 Apr 2003 03:03:48 +0200 (MET DST)
Message-Id: <4.3.2.7.2.20030331200336.06e0ca88@paris.cisco.com>
X-Sender: jvasseur@paris.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 31 Mar 2003 20:03:46 -0500
To: mpls@UU.NET
From: Jean Philippe Vasseur <jvasseur@cisco.com>
Subject: Re: Checking MPLS WG Consensus
Cc: mpls@UU.NET
In-Reply-To: <200303311908.OAA05316@bifocal.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

in favor

JP.

At 14:08 31/03/2003 -0500, George Swallow wrote:
>In San Francisco the workgroup showed support for making
>
>   LDP DoD Graceful Restart
>     draft-thomas-mpls-ldp-dod-restart-00.txt
>
>an MPLS WG Document.  This message is to solicit any further comments
>prior to making a final determination.
>
>Please reply by 4/7 24:00 GMT.
>
>...George
>
>======================================================================
>George Swallow          Cisco Systems                   (978) 936-1398
>                         250 Apollo Drive
>                         Chelmsford, Ma 01824