From owner-mpls@UU.NET  Sun Nov  2 03:11: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 DAA10324
	for <mpls-archive@lists.ietf.org>; Sun, 2 Nov 2003 03:11: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 QQpnau05077
	for <mpls-archive@lists.ietf.org>; Sun, 2 Nov 2003 08:11: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 QQpnau04558;
	Sun, 2 Nov 2003 08:10:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpnat21244
	for mpls-outgoing; Sun, 2 Nov 2003 07:49: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 QQpnat21239
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 2 Nov 2003 07:49: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 QQpnat04130
	for <mpls@UU.NET>; Sun, 2 Nov 2003 07:46: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 QQpnat13960
	for <mpls@UU.NET>; Sun, 2 Nov 2003 07:46:56 GMT
Received: from tiger.seabridge.co.il by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [212.25.127.226])
	id QQpnat13954
	for <mpls@UU.NET>; Sun, 2 Nov 2003 07:46:55 GMT
Received: by tiger.seabridge.co.il with Internet Mail Service (5.5.2653.19)
	id <V1ZDD08F>; Sun, 2 Nov 2003 09:47:08 +0200
Message-ID: <C87E5A01714C7840B92CDED9E79329CA0117D0BD@leopard.seabridge.co.il>
From: Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        Nurit Sprecher
	 <nurit.sprecher@SeabridgeNetworks.com>
Cc: "'Adrian Farrel'" <adrian@olddog.co.uk>, "'mpls@uu.net'" <mpls@UU.NET>,
        "'ccamp@ops.ietf.org'" <ccamp@ops.ietf.org>
Subject: RE: RSVP Graceful Restart 
Date: Sun, 2 Nov 2003 09:47:05 +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,
I fully agree that it is satisfactory that the Ingress LER send traps on
protection status changes. But such a trap should be defined.
Thanks, Nurit.


-----Original Message-----
From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org]
Sent: Thursday, October 30, 2003 3:40 PM
To: Nurit Sprecher
Cc: 'Adrian Farrel'; 'mpls@uu.net'; ccamp@ops.ietf.org
Subject: Re: RSVP Graceful Restart 


In message
<C87E5A01714C7840B92CDED9E79329CA0117D0A7@leopard.seabridge.co.il>,
Nurit Sprecher writes:
>
> Hi,
> I have a question on notifications when FRR is activated.
> If an LSP has been established with the 'one-to-one local protection
> desired' and a detour has been established at each PLR --> all hops along
> the LSP are considered FRR protected.
> Is for example, a problem occurs on one of these detours and the hop
becomes
> to be unprotected, the consequent Resv message will indicate that the
> relevant node is not protected any more and the ARHop table will be
updated
> with the information. However, a management station has no idea of the
> event, unless it keeps polling the ARHop table, which is not a reasonable
> operation. I think that an appropriate notification/trap should be sent to
> the management station indicating the protection status has been changed
to
> trigger the management station polling the ARHop table and verifying which
> node is not protected any more, or which node that has not been protected
is
> now protected.
> Is it possible to add such a kind of trap to the TE MIB?
> Thanks in advance, Nurit.

The local_protect_available bit should be set by each node and if the
backup fails at a node the bit should be cleared.  The ingress then
knows the primary LSP is not fully protected and can then optionally
set a timer and reroute the primary LSP if for some reason the backup
LSP cannot be reestablished during that time.

Since the TE MIB reports status of the ingress, it might be better for
the ingress to send traps on protection status changes rather than
each midpoint sending status (ie: {is|not} fully-protected, {is|not}
protection-inuse).  If the management station need to know which node
transitioned to not protected or inuse then it can poll the midpoints.

Curtis


From owner-mpls@UU.NET  Sun Nov  2 19:40:43 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 TAA01428
	for <mpls-archive@lists.ietf.org>; Sun, 2 Nov 2003 19:40: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 QQpndi07911
	for <mpls-archive@lists.ietf.org>; Mon, 3 Nov 2003 00:40: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 QQpndi07609;
	Mon, 3 Nov 2003 00:40:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpndh07696
	for mpls-outgoing; Mon, 3 Nov 2003 00:25: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 QQpndh07691
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Nov 2003 00:25:46 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 QQpndh00308
	for <mpls@UU.NET>; Mon, 3 Nov 2003 00:24: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 QQpndh09636
	for <mpls@UU.NET>; Mon, 3 Nov 2003 00:24:50 GMT
Received: from relay0.netfirms.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: m0.netfirms.com [209.171.43.51])
	id QQpndh09620
	for <mpls@UU.NET>; Mon, 3 Nov 2003 00:24:50 GMT
Received: (qmail 44514 invoked from network); 3 Nov 2003 00:24:48 -0000
Received: from du-069-0146.access.clara.net (HELO Puppy) (217.158.132.146)
  by 0 with SMTP; 3 Nov 2003 00:24:48 -0000
Message-ID: <068e01c3a1a0$f3f8e440$f9919ed9@Puppy>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <iesg@ietf.org>, <ietf@ietf.org>
Cc: <ben@layer8.net>, "'Kireeti Kompella'" <kireeti@juniper.net>,
        "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: Last Call: 'Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol' to Proposed Standard 
Date: Mon, 3 Nov 2003 00:12:54 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0676_01C3A19F.3A5BC2B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0676_01C3A19F.3A5BC2B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

2.4. MTU TLV

   The MTU TLV encodes information on the maximum transmission unit for
   an LSP, from the advertising LSR to the egress(es) over all valid
   paths.

   The encoding for the MTU TLV is:

       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|1|      MTU TLV (0x0XXX)     |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              MTU              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   MTU

   This is a 16-bit unsigned integer that represents the MTU in octets
   for an LSP or segment of an LSP.


Is this unnecessarily limiting? Shouldn't we support MPLS over L2 =
technologies that support larger than 64k MTUs?

Cheers,
Adrian
 
------=_NextPart_000_0676_01C3A19F.3A5BC2B0
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=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff background=3D"">
<DIV><FONT face=3DArial size=3D2>Hi,<BR><BR><FONT face=3DCourier>2.4. =
MTU=20
TLV<BR><BR>&nbsp;&nbsp; The MTU TLV encodes information on the maximum=20
transmission unit for<BR>&nbsp;&nbsp; an LSP, from the advertising LSR =
to the=20
egress(es) over all valid<BR>&nbsp;&nbsp; paths.<BR><BR>&nbsp;&nbsp; The =

encoding for the MTU TLV is:<BR><BR>&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;=20
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
3<BR>&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=20
9 0 1 2 3 4 5 6 7 8 9 0 1<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
|1|1|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MTU TLV =
(0x0XXX)&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
MTU&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR><BR>&nbsp;&nbsp; =
MTU<BR><BR>&nbsp;&nbsp;=20
This is a 16-bit unsigned integer that represents the MTU in=20
octets<BR>&nbsp;&nbsp; for an LSP or segment of an =
LSP.<BR></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT =
face=3DCourier></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Is this unnecessarily limiting? =
Shouldn't we=20
support MPLS over L2 technologies that support&nbsp;larger than 64k=20
MTUs?<BR><BR>Cheers,<BR>Adrian<BR>&nbsp;</FONT></DIV></BODY></HTML>

------=_NextPart_000_0676_01C3A19F.3A5BC2B0--



From owner-mpls@UU.NET  Tue Nov  4 15:33: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 PAA04153
	for <mpls-archive@lists.ietf.org>; Tue, 4 Nov 2003 15:33:30 -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 QQpnkc08048
	for <mpls-archive@lists.ietf.org>; Tue, 4 Nov 2003 20:33:40 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 QQpnkc07473;
	Tue, 4 Nov 2003 20:33:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpnka18862
	for mpls-outgoing; Tue, 4 Nov 2003 20:13:14 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 QQpnka18857
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Nov 2003 20:13: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 QQpnka08981
	for <mpls@UU.NET>; Tue, 4 Nov 2003 20:10: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 QQpnka02732
	for <mpls@UU.NET>; Tue, 4 Nov 2003 20:10:36 GMT
Received: from kummer.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint2.juniper.net [207.17.136.150])
	id QQpnka02710
	for <mpls@UU.NET>; Tue, 4 Nov 2003 20:10:35 GMT
Received: from kummer.juniper.net (localhost [127.0.0.1])
	by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id hA4K9ada000380;
	Tue, 4 Nov 2003 12:09:36 -0800 (PST)
	(envelope-from kireeti@juniper.net)
Received: from localhost (kireeti@localhost)
	by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id hA4K9X5D000377;
	Tue, 4 Nov 2003 12:09:33 -0800 (PST)
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
Date: Tue, 4 Nov 2003 12:09:33 -0800 (PST)
From: Kireeti Kompella <kireeti@juniper.net>
To: Adrian Farrel <adrian@olddog.co.uk>
cc: iesg@ietf.org, ietf@ietf.org, ben@layer8.net,
        "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: Last Call: 'Maximum Transmission Unit Signalling Extensions for
 the Label Distribution Protocol' to Proposed Standard 
In-Reply-To: <068e01c3a1a0$f3f8e440$f9919ed9@Puppy>
Message-ID: <20031104120734.X361@kummer.juniper.net>
References: <068e01c3a1a0$f3f8e440$f9919ed9@Puppy>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Adrian,

On Mon, 3 Nov 2003, Adrian Farrel wrote:

>    MTU
>
>    This is a 16-bit unsigned integer that represents the MTU in octets
>    for an LSP or segment of an LSP.
>
>
> Is this unnecessarily limiting? Shouldn't we support MPLS over L2 technologies that support larger than 64k MTUs?

I'm happy to do so, but I'm not aware of any L2 technology that
supports MTUs greater than 64K.  But if no one objects, this field can
be made 32 bits, assuming that that's big enough :-)

Kireeti.
-------


From owner-mpls@UU.NET  Tue Nov  4 17:00:03 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 RAA07693
	for <mpls-archive@lists.ietf.org>; Tue, 4 Nov 2003 17:00:03 -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 QQpnki12749
	for <mpls-archive@lists.ietf.org>; Tue, 4 Nov 2003 22:00: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 QQpnki12348;
	Tue, 4 Nov 2003 22:00:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpnkg14946
	for mpls-outgoing; Tue, 4 Nov 2003 21:40: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 QQpnkg14939
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Nov 2003 21:40: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 QQpnkg27150
	for <mpls@UU.NET>; Tue, 4 Nov 2003 21:40:02 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 QQpnkg23647
	for <mpls@UU.NET>; Tue, 4 Nov 2003 21:40:01 GMT
Received: from psg.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: psg.com [147.28.0.62])
	id QQpnkg23632
	for <mpls@UU.NET>; Tue, 4 Nov 2003 21:40:00 GMT
Received: from psg.com ([147.28.0.62] helo=[127.0.0.1])
	by psg.com with esmtp (Exim 4.24; FreeBSD 4.9)
	id 1AH8u7-000LO1-4e; Tue, 04 Nov 2003 21:39:59 +0000
Date: Tue, 4 Nov 2003 13:39:43 -0800
From: Alex Zinin <zinin@psg.com>
Reply-To: Alex Zinin <zinin@psg.com>
X-Priority: 3 (Normal)
Message-ID: <6182056841.20031104133943@psg.com>
To: Kireeti Kompella <kireeti@juniper.net>
CC: Adrian Farrel <adrian@olddog.co.uk>, iesg@ietf.org, ietf@ietf.org,
        ben@layer8.net, "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: Last Call: 'Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol' to Proposed Standard
In-Reply-To: <20031104120734.X361@kummer.juniper.net>
References: <068e01c3a1a0$f3f8e440$f9919ed9@Puppy>
 <20031104120734.X361@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

Kireeti,

  What about existing implementations?

-- 
Alex
http://www.psg.com/~zinin/

Tuesday, November 4, 2003, 12:09:33 PM, Kireeti Kompella wrote:
> Hi Adrian,

> On Mon, 3 Nov 2003, Adrian Farrel wrote:

>>    MTU
>>
>>    This is a 16-bit unsigned integer that represents the MTU in octets
>>    for an LSP or segment of an LSP.
>>
>>
>> Is this unnecessarily limiting? Shouldn't we support MPLS over
>> L2 technologies that support larger than 64k MTUs?

> I'm happy to do so, but I'm not aware of any L2 technology that
> supports MTUs greater than 64K.  But if no one objects, this field can
> be made 32 bits, assuming that that's big enough :-)

> Kireeti.
> -------



From owner-mpls@UU.NET  Wed Nov  5 10:04: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 KAA07966
	for <mpls-archive@lists.ietf.org>; Wed, 5 Nov 2003 10:04: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 QQpnmy10842
	for <mpls-archive@lists.ietf.org>; Wed, 5 Nov 2003 15:04: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 QQpnmy10382;
	Wed, 5 Nov 2003 15:04:03 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpnmw03435
	for mpls-outgoing; Wed, 5 Nov 2003 14:32: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 QQpnmw03429
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Nov 2003 14:32:41 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 QQpnmv16351
	for <mpls@uu.net>; Wed, 5 Nov 2003 14:29: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 QQpnmv22030
	for <mpls@uu.net>; Wed, 5 Nov 2003 14:28:59 GMT
Received: from sj-iport-3.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72])
	id QQpnmv21993
	for <mpls@uu.net>; Wed, 5 Nov 2003 14:28:58 GMT
Received: from cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 05 Nov 2003 06:33:23 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hA5ESrmU017966
	for <mpls@uu.net>; Wed, 5 Nov 2003 06:28:54 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADS85784;
	Wed, 5 Nov 2003 09:28:52 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hA5ESqk22487 for mpls@uu.net; Wed, 5 Nov 2003 09:28: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 QQpnlp21026
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Nov 2003 06:29: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 QQpnlp15837
	for <mpls@uu.net>; Wed, 5 Nov 2003 06:28:54 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 QQpnlp22611
	for <mpls@uu.net>; Wed, 5 Nov 2003 06:28:53 GMT
Received: from web9503.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web9503.mail.yahoo.com [216.136.129.133])
	id QQpnlp22602
	for <mpls@uu.net>; Wed, 5 Nov 2003 06:28:53 GMT
Message-ID: <20031105062852.71904.qmail@web9503.mail.yahoo.com>
Received: from [65.241.132.36] by web9503.mail.yahoo.com via HTTP; Tue, 04 Nov 2003 22:28:52 PST
Date: Tue, 4 Nov 2003 22:28:52 -0800 (PST)
From: Gopalkrishna Panicker <gopanicker@yahoo.com>
Subject: RSVP Fastreroute.
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hello,

I have question on rsvp-fastreroute(03.txt).

Consider the following network

  A-----B-----C-----E---F
  |           |
  |-----D-----|

I have a protected LSP via ABCEF. A has a detour
via D to protect against the failure of B.

At C, the detour is merged and the path message of
the protected LSP is refreshed.
This path message contains session attributes
and TSPEC of the protected LSP and a Fast Reroute
object.


Now if B fails and C's path state expires, Will
the path message being refreshed downstream from
C, be that of the detour LSP? That is  will
it carry a detour object ?
 
Now if Path Specific Method is being used, E will have
two path messages with same sender template and
incoming interface, but one of them has a FRR the
other Detour. Also, the Session attribute object and
TSPEC will be different.


Is this correct ? 

Thanks in advance,

Regards
Gopal 



__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree



From owner-mpls@UU.NET  Wed Nov  5 10:48: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 KAA10789
	for <mpls-archive@lists.ietf.org>; Wed, 5 Nov 2003 10:48: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 QQpnnb21808
	for <mpls-archive@lists.ietf.org>; Wed, 5 Nov 2003 15:48:32 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 QQpnnb21250;
	Wed, 5 Nov 2003 15:48:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpnna28087
	for mpls-outgoing; Wed, 5 Nov 2003 15:32: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 QQpnna28082
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Nov 2003 15:31:57 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 QQpnmz09169
	for <mpls@UU.NET>; Wed, 5 Nov 2003 15:29: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 QQpnmz08123
	for <mpls@UU.NET>; Wed, 5 Nov 2003 15:29:20 GMT
Received: from mail.avici.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [12.38.212.174])
	id QQpnmz08106
	for <mpls@UU.NET>; Wed, 5 Nov 2003 15:29:19 GMT
Received: from avici.com (pbeeram-pc.avici.com [10.2.20.32])
	by mail.avici.com (8.12.8/8.12.8) with ESMTP id hA5FTFGS031381;
	Wed, 5 Nov 2003 10:29:15 -0500
Message-ID: <3FA918AE.90609@avici.com>
Date: Wed, 05 Nov 2003 10:35:10 -0500
From: Pavan Beeram <pbeeram@avici.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Gopalkrishna Panicker <gopanicker@yahoo.com>
CC: mpls@UU.NET
Subject: Re: RSVP Fastreroute.
References: <20031105062852.71904.qmail@web9503.mail.yahoo.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

>
>
>Consider the following network
>
>  A-----B-----C-----E---F
>  |           |
>  |-----D-----|
>
>I have a protected LSP via ABCEF. A has a detour
>via D to protect against the failure of B.
>
>At C, the detour is merged and the path message of
>the protected LSP is refreshed.
>This path message contains session attributes
>and TSPEC of the protected LSP and a Fast Reroute
>object.
>
>
>Now if B fails and C's path state expires, Will
>the path message being refreshed downstream from
>C, be that of the detour LSP? That is  will
>it carry a detour object ?
>
If B fails, the primary path/resv state on C must not expire as long
as there is atleast one backup merging into C.
E should continue receiving primary path refreshes as if nothing has
happened upstream.

-Pavan




From owner-mpls@UU.NET  Fri Nov  7 00:05: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 AAA16936
	for <mpls-archive@lists.ietf.org>; Fri, 7 Nov 2003 00:05:28 -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 QQpnsu03877
	for <mpls-archive@lists.ietf.org>; Fri, 7 Nov 2003 05:05: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 QQpnsu03598;
	Fri, 7 Nov 2003 05:05:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpnst20997
	for mpls-outgoing; Fri, 7 Nov 2003 04:45: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 QQpnst20957
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 7 Nov 2003 04:45:17 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 QQpnss14541
	for <mpls@UU.NET>; Fri, 7 Nov 2003 04:40: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 QQpnss28314
	for <mpls@UU.NET>; Fri, 7 Nov 2003 04:40:59 GMT
Received: from kummer.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint2.juniper.net [207.17.136.150])
	id QQpnss28291
	for <mpls@UU.NET>; Fri, 7 Nov 2003 04:40:58 GMT
Received: from kummer.juniper.net (localhost [127.0.0.1])
	by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id hA74dtda010467;
	Thu, 6 Nov 2003 20:39:55 -0800 (PST)
	(envelope-from kireeti@juniper.net)
Received: from localhost (kireeti@localhost)
	by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id hA74dreH010464;
	Thu, 6 Nov 2003 20:39:53 -0800 (PST)
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
Date: Thu, 6 Nov 2003 20:39:53 -0800 (PST)
From: Kireeti Kompella <kireeti@juniper.net>
To: Alex Zinin <zinin@psg.com>
cc: Adrian Farrel <adrian@olddog.co.uk>, iesg@ietf.org, ietf@ietf.org,
        ben@layer8.net, "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: Last Call: 'Maximum Transmission Unit Signalling Extensions for
 the Label Distribution Protocol' to Proposed Standard
In-Reply-To: <6182056841.20031104133943@psg.com>
Message-ID: <20031106203905.X10439@kummer.juniper.net>
References: <068e01c3a1a0$f3f8e440$f9919ed9@Puppy> <20031104120734.X361@kummer.juniper.net>
 <6182056841.20031104133943@psg.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Tue, 4 Nov 2003, Alex Zinin wrote:

>   What about existing implementations?

There are none that I know of.  If there are any, I would urge them to
speak up!

Kireeti.
-------


From owner-mpls@UU.NET  Fri Nov  7 13:39: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 NAA28436
	for <mpls-archive@lists.ietf.org>; Fri, 7 Nov 2003 13:39:24 -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 QQpnuw17909
	for <mpls-archive@lists.ietf.org>; Fri, 7 Nov 2003 18:39: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 QQpnuw17617;
	Fri, 7 Nov 2003 18:39:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpnuv26887
	for mpls-outgoing; Fri, 7 Nov 2003 18:19: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 QQpnuv26879
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 7 Nov 2003 18:19:50 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 QQpnuv05532
	for <mpls@uu.net>; Fri, 7 Nov 2003 18:19: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 QQpnuv04791
	for <mpls@uu.net>; Fri, 7 Nov 2003 18:19:22 GMT
Received: from sj-iport-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70])
	id QQpnuv04745
	for <mpls@uu.net>; Fri, 7 Nov 2003 18:19:21 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA7IJFAv012433
	for <mpls@uu.net>; Fri, 7 Nov 2003 10:19:18 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADU95596;
	Fri, 7 Nov 2003 13:19:14 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hA7IJEe15607 for mpls@uu.net; Fri, 7 Nov 2003 13:19:14 -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 QQpnuv26826
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 7 Nov 2003 18:18:02 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 QQpnuu00235
	for <mpls@uu.net>; Fri, 7 Nov 2003 18: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 QQpnuu12889
	for <mpls@uu.net>; Fri, 7 Nov 2003 18:14:19 GMT
Received: from sj-iport-5.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-5.cisco.com [171.68.10.87])
	id QQpnuu12864
	for <mpls@uu.net>; Fri, 7 Nov 2003 18:14:18 GMT
Received: from cisco.com (64.102.124.12)
  by sj-iport-5.cisco.com with ESMTP; 07 Nov 2003 10:16:40 -0800
Received: from cisco.com (frondo.cisco.com [161.44.172.154])
	by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA7IEGxg005361
	for <mpls@uu.net>; Fri, 7 Nov 2003 13:14:16 -0500 (EST)
Message-Id: <200311071814.hA7IEGxg005361@rtp-core-1.cisco.com>
To: mpls@UU.NET
Subject: MPLS Agenda
Date: Fri, 07 Nov 2003 13:14:16 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

...George

======= Cut Here =======================================================



November 11, 2003             MPLS Agenda           IETF58 - Minneapolis

Agenda bashing                                                         5

WG Status - new charter                                               10


RSVP

Encoding of Attributes for LSP Establishment Using RSVP-TE             5
  <draft-farrel-mpls-rsvpte-attributes-00.txt>            
Adrian Farrel

RSVP Graceful Restart Extension                                       10
  <draft-rahman-rsvp-restart-extensions-00.txt> 
Reshad Rahman


LDP

TTL-Based Security Option for LDP Hello Message                       10
  <draft-chen-ldp-ttl-00.txt>                    
Albert Tian

LDP signaled LSPs for external prefixes                               10
  <draft-minei-mpls-ldp-external-00.txt> 
Ina Minei


Multicast

Requirements for Point to Multipoint extension to RSVP-TE             10
  <draft-yasukawa-mpls-p2mp-requirement-00.txt>              
Seisho Yasukawa

Extended RSVP-TE for Point-to-Multipoint LSP Tunnels                   5
  <draft-yasukawa-mpls-rsvp-p2mp-03.txt>
Seisho Yasukawa

IP Multicast With PIM-SM Over a MPLS Traffic Engineered Core          10
  <draft-raggarwa-pim-sm-mpls-te-00.txt>                      
Rahul Aggarawal

Requirements for multicast service using a group label over MPLS      10
  <draft-choi-mpls-grouplabel-requirement-01.txt>                   
Min Suk Sung


Encaps

MPLS over Layer 2 Tunneling Protocol (Version 3)                      10
  <draft-townsley-l2tpv3-mpls-00.txt>               
Mark Townsley




November 11, 2003             MPLS Agenda           IETF58 - Minneapolis


Operations & Maintenance

A Framework for MPLS Data Plane OAM                                   10
  <draft-allan-mpls-oam-frmwk-05.txt> 
Don Fedyk

Detecting MPLS Data Plane Failures                                     5
  <draft-ietf-mpls-lsp-ping-04.txt>
Kireeti Kompella / George Swallow

LSR Self Test                                                         10
  <draft-ietf-mpls-lsr-self-test-01.txt>
George Swallow

BFD For MPLS LSPs                                                      5
  <draft-raggarwa-mpls-bfd-00.txt>
Rahul Aggarawal


MIBs

A Supplementary History Module for the MPLS LDP-MIB                   10
  <draft-lai-mpls-ldp-hist-mib-00.txt>                  
Wai Sum Lai


Forwarding

Hybrid data forwarding for Economy Class Services in MPLS             10
  <draft-hpark-hybrid-forwarding-00.txt>     
Hyeon Park 


Meeting Concludes







From owner-mpls@UU.NET  Sun Nov  9 12:33: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 MAA04475
	for <mpls-archive@lists.ietf.org>; Sun, 9 Nov 2003 12:33: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 QQpocc07680
	for <mpls-archive@lists.ietf.org>; Sun, 9 Nov 2003 17:34: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 QQpocc07423;
	Sun, 9 Nov 2003 17:33:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoca10825
	for mpls-outgoing; Sun, 9 Nov 2003 17:11:18 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 QQpoca10816
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 9 Nov 2003 17:11:07 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 QQpoca09686
	for <mpls@uu.net>; Sun, 9 Nov 2003 17:10:27 GMT
From: jcucchiara@mindspring.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 QQpoca10922
	for <mpls@uu.net>; Sun, 9 Nov 2003 17:10:27 GMT
Received: from smtp10.atl.mindspring.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp10.atl.mindspring.net [207.69.200.246])
	id QQpoca10876
	for <mpls@uu.net>; Sun, 9 Nov 2003 17:10:25 GMT
Received: from h-68-166-234-70.cmbrmaor.dynamic.covad.net ([68.166.234.70] helo=jluciani-laptop)
	by smtp10.atl.mindspring.net with smtp (Exim 3.33 #1)
	id 1AIt4l-0007lf-00; Sun, 09 Nov 2003 12:10:11 -0500
Message-Id: <3.0.1.32.20031109121255.006ec068@pop.mindspring.com>
X-Sender: jcucchiara@pop.mindspring.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 09 Nov 2003 12:12:55 -0500
To: wlai@att.com
Subject: Re: I-D ACTION:draft-lai-mpls-ldp-hist-mib-00.txt
Cc: mpls@UU.NET
In-Reply-To: <200310222229.SAA01983@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi Wai Sum,

I have read this draft several times and was confused by it.
The requirements are very broad areas (i.e. Performance Management
Requirement,
Fault Management Requirement), however, the proposed solution of adding 5 new
objects so as to lessen the burden on the SNMP manager (NMS),
did not follow.

The objects being proposed are also confusing to me.  The Attempted
Session counter is already in the MPLS-LDP-STD-MIB and the 
other 2 are totals don't provide relevant information in my opinion.
Why does an operator care about an Entity which is a MIB constuct
and not really important to LDP performance?

Also, the packet counters are not going to be useful unless you
are utilizing an NMS to monitor every node, and every LDP-LSP from
start to end.  You say you do not want to "burden" the network with
additional NMS traffic or increase polling on nodes, 
but that would be the only way to make these counters useful 
as far as I can tell.

I would like to hear from other operators on this draft.

  thanks, Joan


At 06:29 PM 10/22/03 -0400, Internet-Drafts@ietf.org wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
>	Title		: A Supplementary History Module for the MPLS LDP-MIB
>	Author(s)	: W. Lai
>	Filename	: draft-lai-mpls-ldp-hist-mib-00.txt
>	Pages		: 8
>	Date		: 2003-10-22
>	
>In this document, requirements for supplementing the MPLS LDP-MIB 
>are presented for the support of specific network management needs 
>for fault and performance management.  Based on these requirements, 
>it describes managed objects in a supplementary history module for 
>use with the LDP-MIB.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-lai-mpls-ldp-hist-mib-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-lai-mpls-ldp-hist-mib-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-lai-mpls-ldp-hist-mib-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.
>
><ftp://ftp.ietf.org/internet-drafts/draft-lai-mpls-ldp-hist-mib-00.txt>
>



From owner-mpls@UU.NET  Sun Nov  9 21:50: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 VAA22747
	for <mpls-archive@lists.ietf.org>; Sun, 9 Nov 2003 21:50: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 QQpodn17575
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 02:51: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 QQpodn17187;
	Mon, 10 Nov 2003 02:50:39 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpodl02401
	for mpls-outgoing; Mon, 10 Nov 2003 02:28: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 QQpodl02391
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Nov 2003 02:27: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 QQpodl07122
	for <mpls@uu.net>; Mon, 10 Nov 2003 02:27: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 QQpodl10666
	for <mpls@uu.net>; Mon, 10 Nov 2003 02:27:42 GMT
Received: from imo-d01.mx.aol.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imo-d01.mx.aol.com [205.188.157.33])
	id QQpodl10651
	for <mpls@uu.net>; Mon, 10 Nov 2003 02:27:41 GMT
Received: from NtscpUsrLoa@netscape.net
	by imo-d01.mx.aol.com (mail_out_v36_r1.1.) id 1.ef.b39d4f0 (16239);
	Sun, 9 Nov 2003 21:27:39 -0500 (EST)
Received: from  netscape.net ([130.129.131.229]) by air-in03.mx.aol.com (v97.8) with ESMTP id MAILININ33-3f6f3faef79abc; Sun, 09 Nov 2003 21:27:39 -0500
Message-ID: <3FAEF78A.6050201@netscape.net>
Date: Mon, 10 Nov 2003 03:27:22 +0100
From: Loa Andersson <NtscpUsrLoa@netscape.net>
Reply-To: loa@pi.se
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MPLS wg <mpls@UU.NET>
CC: George Swallow <swallow@cisco.com>, Alex Zinin <zinin@psg.com>
Subject: on the mpls oam framework
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-AOL-IP: 130.129.131.229
X-Mailer: Unknown (No Version)
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

All,

I read the mpls oam framework as it has been suggested in
Dave Allans draft (draft-allan-mpls-oam-frmwrk) and also
re-read the the mpls architecture document. I've the architecture
authors to review the oam framework and received some feedback
from them.

It is my understanding that there is a serious disconnect
between the architecture and oam framework, and I therefore
want to restart the oam framework in a fresh document,
with the undertanding that this document shall be aligned
with the architecture.

I asked David Allan and Tom Nadeau to take on the editorship
for this new document, and hope to have positive answers from
both of them before the mpls wg meeting in Minneapolis.

/Loa



From owner-mpls@UU.NET  Mon Nov 10 03:39: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 DAA12981
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 03:39: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 QQpoek18956
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 08:39: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 QQpoek18708;
	Mon, 10 Nov 2003 08:39:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoej20311
	for mpls-outgoing; Mon, 10 Nov 2003 08:20: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 QQpoej20306
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Nov 2003 08:20: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 QQpoej15098
	for <mpls@UU.NET>; Mon, 10 Nov 2003 08:18: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 QQpoej09110
	for <mpls@UU.NET>; Mon, 10 Nov 2003 08:18:35 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 QQpoej09097
	for <mpls@UU.NET>; Mon, 10 Nov 2003 08:18:34 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAA8IUS28289;
	Mon, 10 Nov 2003 03:18:30 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <W3H850JY>; Mon, 10 Nov 2003 03:18:31 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D02B9276F@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'loa@pi.se'" <loa@pi.se>, MPLS wg <mpls@UU.NET>
Cc: George Swallow <swallow@cisco.com>, Alex Zinin <zinin@psg.com>
Subject: RE: on the mpls oam framework
Date: Mon, 10 Nov 2003 03:18:29 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-mpls@UU.NET
Precedence: bulk

Loa 

I have no small problem with the proposal to start over as I feel like I'm
being asked to set aside my and my colleagues convictions in the interest of
producing what I would consider to be a document of diminshed significance.

Given that the draft basically says you cannot do everything with all
connectivity structures as they stand and why (e.g. Mp2P and PHP) and need
to overlay P2P LSPs when certain functionality is required, I'm not too sure
where the disconnect is. It discusses how you can use aspects of the
architecture to create a framework whereby any style of instrumentation and
consequent measurability can be achieved.

I'd prefer if those reviewing the document provided feedback as to where
specific unresolvable disconnects existed. I'm not sure they are
unresolvable or innacurate.

rgds
Dave

> -----Original Message-----
> From: Loa Andersson [mailto:NtscpUsrLoa@netscape.net] 
> Sent: Sunday, November 09, 2003 9:27 PM
> To: MPLS wg
> Cc: George Swallow; Alex Zinin
> Subject: on the mpls oam framework
> 
> 
> All,
> 
> I read the mpls oam framework as it has been suggested in
> Dave Allans draft (draft-allan-mpls-oam-frmwrk) and also 
> re-read the the mpls architecture document. I've the 
> architecture authors to review the oam framework and received 
> some feedback from them.
> 
> It is my understanding that there is a serious disconnect 
> between the architecture and oam framework, and I therefore 
> want to restart the oam framework in a fresh document, with 
> the undertanding that this document shall be aligned with the 
> architecture.
> 
> I asked David Allan and Tom Nadeau to take on the editorship 
> for this new document, and hope to have positive answers from 
> both of them before the mpls wg meeting in Minneapolis.
> 
> /Loa
> 
> 


From owner-mpls@UU.NET  Mon Nov 10 03:42:40 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 DAA13058
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 03:42:40 -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 QQpoek14545
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 08:42: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 QQpoek14343;
	Mon, 10 Nov 2003 08:42:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoej20545
	for mpls-outgoing; Mon, 10 Nov 2003 08:23: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 QQpoej20539
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Nov 2003 08:23:02 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 QQpoej28634
	for <mpls@UU.NET>; Mon, 10 Nov 2003 08:22:51 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 QQpoej23184
	for <mpls@UU.NET>; Mon, 10 Nov 2003 08:22:51 GMT
Received: from i2kc01-ukbr.domain1.systemhost.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp1.smtp.bt.com [217.32.164.137])
	id QQpoej23175
	for <mpls@UU.NET>; Mon, 10 Nov 2003 08:22:50 GMT
Received: from i2km96-ukbr.domain1.systemhost.net ([193.113.197.84]) by i2kc01-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 10 Nov 2003 08:22:49 +0000
Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km96-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 10 Nov 2003 08:22:49 +0000
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"
Content-Transfer-Encoding: quoted-printable
Subject: RE: on the mpls oam framework
Date: Mon, 10 Nov 2003 08:22:48 -0000
Message-ID: <0536FC9B908BEC4597EE721BE6A3538904EF2DDB@i2km07-ukbr.domain1.systemhost.net>
Thread-Topic: on the mpls oam framework
thread-index: AcOnNWShrolFU4NfTZ6TBpoUksUnzQAHFzyQ
To: <loa@pi.se>, <mpls@UU.NET>
Cc: <swallow@cisco.com>, <zinin@psg.com>
X-OriginalArrivalTime: 10 Nov 2003 08:22:49.0731 (UTC) FILETIME=[D4069D30:01C3A763]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Loa,

I agree there is a serious disconnect between the 'architecture' and =
what is being done in some places in IETF, eg PWE3.  Whether some people =
like them or not, G.805 and G.809 respresent the functional architecture =
of all technologies.....the former covers the co-cs and co-ps modes and =
the latter the cnls mode, and all technologies map to one of these =
modes.

One must respect the architectural principles of the networking mode in =
question or else problems arise later.....the 'OAM problems' are one =
symptom of this.  The classic example that springs to mind is a =
link-connection (ie label) swapping co-ps forwarding mode (eg MPLS) that =
violates the allowed topological constructs of that mode (which in this =
case are p2p or p2mp) and terminates the trail 1 hop too soon (ie PHP).  =
There should also be layer independence in a simple client/server =
relationship, ie do not modify the client PDU.

Keep the network architecture clean and the problems will not =
exist.......Dave (Allan's) paper is, in general, simply a survey of what =
has been 'done'.

So please be very clear when identifying *where* the disconnects =
exist.....and they are not in Dave's paper.

regards, Neil

> -----Original Message-----
> From: Loa Andersson [mailto:NtscpUsrLoa@netscape.net]
> Sent: 10 November 2003 02:27
> To: MPLS wg
> Cc: George Swallow; Alex Zinin
> Subject: on the mpls oam framework
>=20
>=20
> All,
>=20
> I read the mpls oam framework as it has been suggested in
> Dave Allans draft (draft-allan-mpls-oam-frmwrk) and also
> re-read the the mpls architecture document. I've the architecture
> authors to review the oam framework and received some feedback
> from them.
>=20
> It is my understanding that there is a serious disconnect
> between the architecture and oam framework, and I therefore
> want to restart the oam framework in a fresh document,
> with the undertanding that this document shall be aligned
> with the architecture.
>=20
> I asked David Allan and Tom Nadeau to take on the editorship
> for this new document, and hope to have positive answers from
> both of them before the mpls wg meeting in Minneapolis.
>=20
> /Loa
>=20
>=20


From owner-mpls@UU.NET  Mon Nov 10 05:11: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 FAA14691
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 05:11: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 QQpoeq10060
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 10:11: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 QQpoeq09697;
	Mon, 10 Nov 2003 10:11:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoep17233
	for mpls-outgoing; Mon, 10 Nov 2003 09:52: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 QQpoep17217
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Nov 2003 09:51:50 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 QQpoep28370
	for <mpls@UU.NET>; Mon, 10 Nov 2003 09:49: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 QQpoep19196
	for <mpls@UU.NET>; Mon, 10 Nov 2003 09:49:20 GMT
Received: from wiprom2mx1.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41])
	id QQpoep19146
	for <mpls@UU.NET>; Mon, 10 Nov 2003 09:49:19 GMT
Received: from m2vwall5.wipro.com ([10.115.50.5])
	by wiprom2mx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id hAA9lsOB028867;
	Mon, 10 Nov 2003 15:17:59 +0530 (IST)
Received: from blr-m3-msg.wipro.com ([10.114.50.99]) by blr-m1-bh4.wipro.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 10 Nov 2003 15:17:07 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPartTM-000-8e96758d-d0c5-4a31-bb9f-1b329d3542dc"
Subject: Setup of PW extending multiple tunnels
Date: Mon, 10 Nov 2003 15:17:07 +0530
Message-ID: <7F396B9772328640B7593FA817EEEDAD89E6A9@blr-m3-msg.wipro.com>
Thread-Topic: Setup of PW extending multiple tunnels
Thread-Index: AcOnb5qITsHcDJNARTCxQiW+Nb08VA==
From: "Narendrakumar Limbani" <narendrakumar.limbani@wipro.com>
To: <pwe3@ietf.org>
Cc: <mpls@UU.NET>
X-OriginalArrivalTime: 10 Nov 2003 09:47:07.0702 (UTC) FILETIME=[9ACFBD60:01C3A76F]
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPartTM-000-8e96758d-d0c5-4a31-bb9f-1b329d3542dc
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3A76F.9A820D30"

------_=_NextPart_001_01C3A76F.9A820D30
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
I want to know whether it is possible to setup a PW extending multiple
tunnels.
=20
for instance, I have setup like this
=20
  A  ----p---------p--------   B    ------p----------p----------- C
=20
I have one tunnel between A & B.
I have one more tunnel between B & C.
=20
Now is it possible to setup PW between A & B ?
I am referring draft-ietf-pwe3-control-protocol-04.txt.
=20
=20
Regds,
Narendrakumar Limbani
=20
=20
=20

=20


------_=_NextPart_001_01C3A76F.9A820D30
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE>BODY {
	BACKGROUND-COLOR: #ffffff; COLOR: #000000; FONT-FAMILY: Arial; =
FONT-SIZE: 10pt; MARGIN-LEFT: 25px; MARGIN-TOP: 25px
}
P.msoNormal {
	COLOR: #ffffcc; FONT-FAMILY: Helvetica, "Times New Roman"; FONT-SIZE: =
10pt; MARGIN-LEFT: 0px; MARGIN-TOP: 0px
}
LI.msoNormal {
	COLOR: #ffffcc; FONT-FAMILY: Helvetica, "Times New Roman"; FONT-SIZE: =
10pt; MARGIN-LEFT: 0px; MARGIN-TOP: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.2462.0" name=3DGENERATOR></HEAD>
<BODY=20
style=3D"FONT-SIZE: 10pt; COLOR: #000000; FONT-FAMILY: Arial; =
BACKGROUND-COLOR: #ffffff"=20
bgColor=3D#ffffff background=3D"">
<DIV><SPAN class=3D365572209-10112003>Hi,</SPAN></DIV>
<DIV><SPAN class=3D365572209-10112003></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D365572209-10112003>I want to know whether it is =
possible to=20
setup a PW extending multiple tunnels.</SPAN></DIV>
<DIV><SPAN class=3D365572209-10112003></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D365572209-10112003>for instance, I have setup like=20
this</SPAN></DIV>
<DIV><SPAN class=3D365572209-10112003></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D365572209-10112003>&nbsp; A&nbsp; =
----p---------p--------&nbsp;=20
&nbsp;B&nbsp; &nbsp; ------p----------p----------- C</SPAN></DIV>
<DIV><SPAN class=3D365572209-10112003></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D365572209-10112003>I have one tunnel between A &amp;=20
B.</SPAN></DIV>
<DIV><SPAN class=3D365572209-10112003>I have one more =
tunnel&nbsp;between B=20
&amp;&nbsp;C.</SPAN></DIV>
<DIV><SPAN class=3D365572209-10112003></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D365572209-10112003>Now is it possible to setup PW =
between A=20
&amp; B ?</SPAN></DIV>
<DIV><SPAN class=3D365572209-10112003>I am referring=20
draft-ietf-pwe3-control-protocol-04.txt.</SPAN></DIV>
<DIV><SPAN class=3D365572209-10112003></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D365572209-10112003></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D365572209-10112003>Regds,</SPAN></DIV>
<DIV><SPAN class=3D365572209-10112003>Narendrakumar Limbani</SPAN></DIV>
<DIV><SPAN class=3D365572209-10112003>&nbsp;</SPAN></DIV>
<DIV><SPAN class=3D365572209-10112003></SPAN>&nbsp;</DIV>
<DIV align=3Dleft>&nbsp;</DIV>
<P>&nbsp;</P></BODY></HTML>
=00
------_=_NextPart_001_01C3A76F.9A820D30--

------=_NextPartTM-000-8e96758d-d0c5-4a31-bb9f-1b329d3542dc--



From owner-mpls@UU.NET  Mon Nov 10 07:28: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 HAA17429
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 07:28: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 QQpoez15389
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 12:28: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 QQpoez15252;
	Mon, 10 Nov 2003 12:28:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoey24951
	for mpls-outgoing; Mon, 10 Nov 2003 12:10: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 QQpoey24927
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Nov 2003 12:10:37 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 QQpoey25805
	for <mpls@UU.NET>; Mon, 10 Nov 2003 12:08: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 QQpoey07549
	for <mpls@UU.NET>; Mon, 10 Nov 2003 12:08:37 GMT
Received: from wiprom2mx1.wipro.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41])
	id QQpoey07520
	for <mpls@UU.NET>; Mon, 10 Nov 2003 12:08:35 GMT
Received: from m2vwall5.wipro.com ([10.115.50.5])
	by wiprom2mx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id hAAC7BOB001080;
	Mon, 10 Nov 2003 17:37:16 +0530 (IST)
Received: from blr-m3-msg.wipro.com ([10.114.50.99]) by blr-m1-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 10 Nov 2003 17:37:55 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPartTM-000-15f03a6c-1231-41e7-880e-7e1d7e5b9b85"
Subject: RE: [PWE3] Setup of PW extending multiple tunnels
Date: Mon, 10 Nov 2003 17:36:23 +0530
Message-ID: <7F396B9772328640B7593FA817EEEDAD89EB44@blr-m3-msg.wipro.com>
Thread-Topic: [PWE3] Setup of PW extending multiple tunnels
Thread-Index: AcOnb5qITsHcDJNARTCxQiW+Nb08VAAEwt3g
From: "Narendrakumar Limbani" <narendrakumar.limbani@wipro.com>
To: <pwe3@ietf.org>
Cc: <mpls@UU.NET>
X-OriginalArrivalTime: 10 Nov 2003 12:07:55.0867 (UTC) FILETIME=[464F6AB0:01C3A783]
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPartTM-000-15f03a6c-1231-41e7-880e-7e1d7e5b9b85
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3A783.0F7D62D8"

------_=_NextPart_001_01C3A783.0F7D62D8
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All,
=20
By mistake I asked for between A & B.
Actually I want to know whether it is possible setup PW beetween A & C.
=20
--Narendra
=20

	-----Original Message-----
	From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf
Of Narendrakumar Limbani
	Sent: Monday, November 10, 2003 3:17 PM
	To: pwe3@ietf.org
	Cc: mpls@UU.NET
	Subject: [PWE3] Setup of PW extending multiple tunnels
=09
=09
	Hi,
	=20
	I want to know whether it is possible to setup a PW extending
multiple tunnels.
	=20
	for instance, I have setup like this
	=20
	  A  ----p---------p--------   B
------p----------p----------- C
	=20
	I have one tunnel between A & B.
	I have one more tunnel between B & C.
	=20
	Now is it possible to setup PW between A & B ?
	I am referring draft-ietf-pwe3-control-protocol-04.txt.
	=20
	=20
	Regds,
	Narendrakumar Limbani
	=20
	=20
	=20

	=20


------_=_NextPart_001_01C3A783.0F7D62D8
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE>BODY {
	BACKGROUND-COLOR: #ffffff; COLOR: #000000; FONT-FAMILY: Arial; =
FONT-SIZE: 10pt; MARGIN-LEFT: 25px; MARGIN-TOP: 25px
}
P.msoNormal {
	COLOR: #ffffcc; FONT-FAMILY: Helvetica, "Times New Roman"; FONT-SIZE: =
10pt; MARGIN-LEFT: 0px; MARGIN-TOP: 0px
}
LI.msoNormal {
	COLOR: #ffffcc; FONT-FAMILY: Helvetica, "Times New Roman"; FONT-SIZE: =
10pt; MARGIN-LEFT: 0px; MARGIN-TOP: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.2462.0" name=3DGENERATOR></HEAD>
<BODY=20
style=3D"FONT-SIZE: 10pt; COLOR: #000000; FONT-FAMILY: Arial; =
BACKGROUND-COLOR: #ffffff"=20
bgColor=3D#ffffff background=3D"">
<DIV><SPAN class=3D365572209-10112003><SPAN =
class=3D913260312-10112003>Hi=20
All,</SPAN></SPAN></DIV>
<DIV><SPAN class=3D365572209-10112003></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D365572209-10112003><SPAN =
class=3D913260312-10112003>By mistake I=20
asked for between A &amp; B.</SPAN></SPAN></DIV>
<DIV><SPAN class=3D365572209-10112003><SPAN =
class=3D913260312-10112003>Actually I=20
want to know whether it is possible setup PW beetween A &amp;=20
C.</SPAN></SPAN></DIV>
<DIV><SPAN class=3D365572209-10112003><SPAN=20
class=3D913260312-10112003></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D365572209-10112003><SPAN=20
class=3D913260312-10112003>--Narendra</SPAN></SPAN></DIV>
<DIV align=3Dleft>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma>-----Original Message-----<BR><B>From:</B> =
pwe3-admin@ietf.org=20
  [mailto:pwe3-admin@ietf.org] <B>On Behalf Of </B>Narendrakumar=20
  Limbani<BR><B>Sent:</B> Monday, November 10, 2003 3:17 =
PM<BR><B>To:</B>=20
  pwe3@ietf.org<BR><B>Cc:</B> mpls@UU.NET<BR><B>Subject:</B> [PWE3] =
Setup of PW=20
  extending multiple tunnels<BR><BR></FONT></DIV>
  <DIV><SPAN class=3D365572209-10112003>Hi,</SPAN></DIV>
  <DIV><SPAN class=3D365572209-10112003></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D365572209-10112003>I want to know whether it is =
possible to=20
  setup a PW extending multiple tunnels.</SPAN></DIV>
  <DIV><SPAN class=3D365572209-10112003></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D365572209-10112003>for instance, I have setup like=20
  this</SPAN></DIV>
  <DIV><SPAN class=3D365572209-10112003></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D365572209-10112003>&nbsp; A&nbsp;=20
  ----p---------p--------&nbsp; &nbsp;B&nbsp; &nbsp;=20
  ------p----------p----------- C</SPAN></DIV>
  <DIV><SPAN class=3D365572209-10112003></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D365572209-10112003>I have one tunnel between A =
&amp;=20
  B.</SPAN></DIV>
  <DIV><SPAN class=3D365572209-10112003>I have one more =
tunnel&nbsp;between B=20
  &amp;&nbsp;C.</SPAN></DIV>
  <DIV><SPAN class=3D365572209-10112003></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D365572209-10112003>Now is it possible to setup PW =
between A=20
  &amp; B ?</SPAN></DIV>
  <DIV><SPAN class=3D365572209-10112003>I am referring=20
  draft-ietf-pwe3-control-protocol-04.txt.</SPAN></DIV>
  <DIV><SPAN class=3D365572209-10112003></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D365572209-10112003></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D365572209-10112003>Regds,</SPAN></DIV>
  <DIV><SPAN class=3D365572209-10112003>Narendrakumar =
Limbani</SPAN></DIV>
  <DIV><SPAN class=3D365572209-10112003></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D365572209-10112003></SPAN>&nbsp;</DIV>
  <DIV align=3Dleft>&nbsp;</DIV>
  <P>&nbsp;</P></BLOCKQUOTE></BODY></HTML>
=00
------_=_NextPart_001_01C3A783.0F7D62D8--

------=_NextPartTM-000-15f03a6c-1231-41e7-880e-7e1d7e5b9b85--



From owner-mpls@UU.NET  Mon Nov 10 11:02: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 LAA26872
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 11:02: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 QQpofo19663
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 16:02: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 QQpofo19039;
	Mon, 10 Nov 2003 16:02:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpofm15590
	for mpls-outgoing; Mon, 10 Nov 2003 15:39: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 QQpofm15585
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Nov 2003 15:39: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 QQpofm07912
	for <mpls@uu.net>; Mon, 10 Nov 2003 15:38:54 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 QQpofm06063
	for <mpls@uu.net>; Mon, 10 Nov 2003 15:38:53 GMT
Received: from imo-d01.mx.aol.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imo-d01.mx.aol.com [205.188.157.33])
	id QQpofm06056
	for <mpls@uu.net>; Mon, 10 Nov 2003 15:38:53 GMT
Received: from NtscpUsrLoa@netscape.net
	by imo-d01.mx.aol.com (mail_out_v36_r1.1.) id p.19.b33b884 (16239);
	Mon, 10 Nov 2003 10:38:49 -0500 (EST)
Received: from  netscape.net (tla-loa.ietf58.ietf.org [130.129.131.229]) by air-in03.mx.aol.com (v97.8) with ESMTP id MAILININ33-3f6f3fafb107361; Mon, 10 Nov 2003 10:38:49 -0500
Message-ID: <3FAFB0F6.3020307@netscape.net>
Date: Mon, 10 Nov 2003 16:38:30 +0100
From: Loa Andersson <NtscpUsrLoa@netscape.net>
Reply-To: loa@pi.se
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: neil.2.harrison@bt.com
CC: loa@pi.se, mpls@UU.NET, swallow@cisco.com, zinin@psg.com
Subject: Re: on the mpls oam framework
References: <0536FC9B908BEC4597EE721BE6A3538904EF2DDB@i2km07-ukbr.domain1.systemhost.net>
In-Reply-To: <0536FC9B908BEC4597EE721BE6A3538904EF2DDB@i2km07-ukbr.domain1.systemhost.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-AOL-IP: 130.129.131.229
X-Mailer: Unknown (No Version)
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Neil,

I'm glad that you agree on the situation, and surprised on your
attitude towards the guiding documents in MPLS development.

We have the MPLS architecture and it is the starting point all
other mpls documents, and should be so for the mpls om framework
as well. To qoute you "Whether some people like it or not..."

/Loa

neil.2.harrison@bt.com wrote:

>Loa,
>
>I agree there is a serious disconnect between the 'architecture' and what is being done in some places in IETF, eg PWE3.  Whether some people like them or not, G.805 and G.809 respresent the functional architecture of all technologies.....the former covers the co-cs and co-ps modes and the latter the cnls mode, and all technologies map to one of these modes.
>
>One must respect the architectural principles of the networking mode in question or else problems arise later.....the 'OAM problems' are one symptom of this.  The classic example that springs to mind is a link-connection (ie label) swapping co-ps forwarding mode (eg MPLS) that violates the allowed topological constructs of that mode (which in this case are p2p or p2mp) and terminates the trail 1 hop too soon (ie PHP).  There should also be layer independence in a simple client/server relationship, ie do not modify the client PDU.
>
>Keep the network architecture clean and the problems will not exist.......Dave (Allan's) paper is, in general, simply a survey of what has been 'done'.
>
>So please be very clear when identifying *where* the disconnects exist.....and they are not in Dave's paper.
>
>regards, Neil
>
>  
>
>>-----Original Message-----
>>From: Loa Andersson [mailto:NtscpUsrLoa@netscape.net]
>>Sent: 10 November 2003 02:27
>>To: MPLS wg
>>Cc: George Swallow; Alex Zinin
>>Subject: on the mpls oam framework
>>
>>
>>All,
>>
>>I read the mpls oam framework as it has been suggested in
>>Dave Allans draft (draft-allan-mpls-oam-frmwrk) and also
>>re-read the the mpls architecture document. I've the architecture
>>authors to review the oam framework and received some feedback
>>from them.
>>
>>It is my understanding that there is a serious disconnect
>>between the architecture and oam framework, and I therefore
>>want to restart the oam framework in a fresh document,
>>with the undertanding that this document shall be aligned
>>with the architecture.
>>
>>I asked David Allan and Tom Nadeau to take on the editorship
>>for this new document, and hope to have positive answers from
>>both of them before the mpls wg meeting in Minneapolis.
>>
>>/Loa
>>
>>    
>>
>
>  
>



From owner-mpls@UU.NET  Mon Nov 10 11:24: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 LAA28136
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 11:24: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 QQpofp24986
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 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 QQpofp24508;
	Mon, 10 Nov 2003 16:24:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpofo02324
	for mpls-outgoing; Mon, 10 Nov 2003 16:03: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 QQpofo01369
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Nov 2003 16:03: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 QQpofo14936
	for <mpls@uu.net>; Mon, 10 Nov 2003 16:02:18 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 QQpofo13045
	for <mpls@uu.net>; Mon, 10 Nov 2003 16:02:18 GMT
Received: from sj-iport-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71])
	id QQpofo13029
	for <mpls@uu.net>; Mon, 10 Nov 2003 16:02:17 GMT
Received: from cisco.com (171.71.177.254)
  by sj-iport-2.cisco.com with ESMTP; 10 Nov 2003 08:04:00 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAAG2Ew5001286
	for <mpls@uu.net>; Mon, 10 Nov 2003 08:02:14 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADW07055;
	Mon, 10 Nov 2003 11:02:13 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAAG2Dj12327 for mpls@uu.net; Mon, 10 Nov 2003 11:02:13 -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 QQpofo23444
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Nov 2003 16:00: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 QQpofn16888
	for <mpls@uu.net>; Mon, 10 Nov 2003 15:58: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 QQpofn13752
	for <mpls@uu.net>; Mon, 10 Nov 2003 15:58:58 GMT
Received: from asgard.ietf.org by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: asgard.ietf.org [132.151.6.40])
	id QQpofn13740
	for <mpls@uu.net>; Mon, 10 Nov 2003 15:58:58 GMT
Received: from apache by asgard.ietf.org with local (Exim 4.14)
	id 1AJEIW-0008HE-Eg; Mon, 10 Nov 2003 10:49:48 -0500
X-test-idtracker: no
To: IETF-Announce:;
Cc: mpls@UU.NET
From: The IESG <iesg-secretary@ietf.org>
Subject: Last Call: 'Encapsulating MPLS in IP or Generic Routing 
         Encapsulation (GRE)' to Proposed Standard 
Reply-to: iesg@ietf.org
Message-Id: <E1AJEIW-0008HE-Eg@asgard.ietf.org>
Date: Mon, 10 Nov 2003 10:49:48 -0500
Sender: owner-mpls@UU.NET
Precedence: bulk

The IESG has received a request from the Multiprotocol Label Switching WG to
consider the following document:

- 'Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) '
   <draft-ietf-mpls-in-ip-or-gre-03.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-11-24.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-mpls-in-ip-or-gre-03.txt



From owner-mpls@UU.NET  Mon Nov 10 12:40: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 MAA02608
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 12:40: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 QQpofu28467
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 17: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 QQpofu27967;
	Mon, 10 Nov 2003 17:40:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoft02057
	for mpls-outgoing; Mon, 10 Nov 2003 17:19:24 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 QQpoft02048
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Nov 2003 17:19:16 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 QQpoft16414
	for <mpls@uu.net>; Mon, 10 Nov 2003 17:18: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 QQpoft04074
	for <mpls@uu.net>; Mon, 10 Nov 2003 17:18:27 GMT
Received: from imo-d02.mx.aol.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imo-d02.mx.aol.com [205.188.157.34])
	id QQpoft04062
	for <mpls@uu.net>; Mon, 10 Nov 2003 17:18:27 GMT
Received: from NtscpUsrLoa@netscape.net
	by imo-d02.mx.aol.com (mail_out_v36_r1.1.) id d.1b0.87df970 (16237);
	Mon, 10 Nov 2003 12:18:14 -0500 (EST)
Received: from  netscape.net (dyn136-235.ietf58.ietf.org [130.129.136.235]) by air-in03.mx.aol.com (v97.8) with ESMTP id MAILININ31-3f6d3fafc85519e; Mon, 10 Nov 2003 12:18:14 -0500
Message-ID: <3FAFC83A.5040808@netscape.net>
Date: Mon, 10 Nov 2003 18:17:46 +0100
From: Loa Andersson <NtscpUsrLoa@netscape.net>
Reply-To: loa@pi.se
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dallan@nortelnetworks.com, MPLS wg <mpls@UU.NET>
Subject: Re: on the mpls oam framework
References: <FFFC48AEAA5F7447929F4F0D93FCC12D02B9276F@zcard031.ca.nortel.com>
In-Reply-To: <FFFC48AEAA5F7447929F4F0D93FCC12D02B9276F@zcard031.ca.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AOL-IP: 130.129.136.235
X-Mailer: Unknown (No Version)
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dave,

I hope the "small problem" should not be taken in a rethorical
sense, and hope you are willing to work with Tom on this.

My interest in this is that we create a non-broken foundaiton
for mpls, rather than having work going of in different incompatible
directions. Hope you will see this a a chance to contribute to
this unified foundation.

I am a bit concerned with the view that alignmentti to the mpls
architecture  would diminish the value of the document.

/Loa

dallan@nortelnetworks.com wrote:

>Loa 
>
>I have no small problem with the proposal to start over as I feel like I'm
>being asked to set aside my and my colleagues convictions in the interest of
>producing what I would consider to be a document of diminshed significance.
>
>Given that the draft basically says you cannot do everything with all
>connectivity structures as they stand and why (e.g. Mp2P and PHP) and need
>to overlay P2P LSPs when certain functionality is required, I'm not too sure
>where the disconnect is. It discusses how you can use aspects of the
>architecture to create a framework whereby any style of instrumentation and
>consequent measurability can be achieved.
>
>I'd prefer if those reviewing the document provided feedback as to where
>specific unresolvable disconnects existed. I'm not sure they are
>unresolvable or innacurate.
>
>rgds
>Dave
>
>  
>
>>-----Original Message-----
>>From: Loa Andersson [mailto:NtscpUsrLoa@netscape.net] 
>>Sent: Sunday, November 09, 2003 9:27 PM
>>To: MPLS wg
>>Cc: George Swallow; Alex Zinin
>>Subject: on the mpls oam framework
>>
>>
>>All,
>>
>>I read the mpls oam framework as it has been suggested in
>>Dave Allans draft (draft-allan-mpls-oam-frmwrk) and also 
>>re-read the the mpls architecture document. I've the 
>>architecture authors to review the oam framework and received 
>>some feedback from them.
>>
>>It is my understanding that there is a serious disconnect 
>>between the architecture and oam framework, and I therefore 
>>want to restart the oam framework in a fresh document, with 
>>the undertanding that this document shall be aligned with the 
>>architecture.
>>
>>I asked David Allan and Tom Nadeau to take on the editorship 
>>for this new document, and hope to have positive answers from 
>>both of them before the mpls wg meeting in Minneapolis.
>>
>>/Loa
>>
>>
>>    
>>



From owner-mpls@UU.NET  Mon Nov 10 12:41: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 MAA02696
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 12:41: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 QQpofu07731
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 17:42: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 QQpofu07264;
	Mon, 10 Nov 2003 17:41:59 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoft02324
	for mpls-outgoing; Mon, 10 Nov 2003 17:22: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 QQpoft02319
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Nov 2003 17:22:49 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 QQpoft19994
	for <mpls@uu.net>; Mon, 10 Nov 2003 17:21: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 QQpoft21148
	for <mpls@uu.net>; Mon, 10 Nov 2003 17:21:06 GMT
Received: from tm1.ca.alcatel.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: kanfw1.ottawa.alcatel.ca [192.75.23.69])
	id QQpoft21139
	for <mpls@uu.net>; Mon, 10 Nov 2003 17:21:05 GMT
Received: from alcatel.com (localhost [127.0.0.1])
	by tm1.ca.alcatel.com (8.12.10/8.12.10) with ESMTP id hAAHKvx5021303;
	Mon, 10 Nov 2003 12:21:02 -0500 (EST)
Message-ID: <3FAFC7E9.3010103@alcatel.com>
Date: Mon, 10 Nov 2003 12:16:25 -0500
From: jason rusmisel <jason.rusmisel@alcatel.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ina Minei <ina@juniper.net>, mpls@UU.NET
Subject: Re: I-D ACTION:draft-minei-mpls-ldp-external-00.txt (fwd)
References: <20031013100945.T88214@garnet.juniper.net>
In-Reply-To: <20031013100945.T88214@garnet.juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

A question for you:

If I understand correctly, the motivation for this draft is to allow LDP 
to be the single mechanism to distribute reachability rather than 
counting on a 2547bis-like mechanism.
The overall approach of carrying the External FEC in the FEC TLV 
guarantees that these label mappings will not be propagated in a network 
of mixed LDP implementations.  Have you considered this situation? 

Jason Rusmisel.

Ina Minei wrote:

>   This document describes a mechanism that allows the creation of LDP
>signaled LSPs for prefixes which are not present in the routing table.
>
>   Comments welcome,
>
>		Thank you,
>
>			Ina Minei
>
>---------- Forwarded message ----------
>Date: 7 Oct 03 15:00:15 GMT
>From: Internet-Drafts@ietf.org
>To: IETF-Announce:  ;
>Newsgroups: jnx.ext.ietf.announce
>Subject: I-D ACTION:draft-minei-mpls-ldp-external-00.txt
>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>	Title		: LDP signaled LSPs for external prefixes
>	Author(s)	: L. Fang, et. al.
>	Filename	: draft-minei-mpls-ldp-external-00.txt
>	Pages		: 6
>	Date		: 2003-10-7
>
>In order to create forwarding state for a FEC received from a downstream
>LSR, LDP requires the presence of a matching entry in the routing table.
>This document describes a mechanism that allows the creation of LDP
>signaled LSPs for prefixes which are not present in the routing table.
>This draft is applicable to address prefix FECs and host FECs associated
>with either IPv4 or IPv6 prefixes.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-minei-mpls-ldp-external-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-minei-mpls-ldp-external-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-minei-mpls-ldp-external-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.
>



From owner-mpls@UU.NET  Mon Nov 10 12:58: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 MAA03240
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 12:58: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 QQpofv26824
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 17: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 QQpofv26375;
	Mon, 10 Nov 2003 17:58:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpofu03509
	for mpls-outgoing; Mon, 10 Nov 2003 17:38: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 QQpofu03493
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Nov 2003 17:38:17 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 QQpofu00777
	for <mpls@uu.net>; Mon, 10 Nov 2003 17:37: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 QQpofu22750
	for <mpls@uu.net>; Mon, 10 Nov 2003 17:37:09 GMT
Received: from sj-iport-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72])
	id QQpofu22715
	for <mpls@uu.net>; Mon, 10 Nov 2003 17:37:07 GMT
Received: from cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 10 Nov 2003 09:43:20 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAAHb3mU012955
	for <mpls@uu.net>; Mon, 10 Nov 2003 09:37:04 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADW17170;
	Mon, 10 Nov 2003 12:36:58 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAAHawN16047 for mpls@uu.net; Mon, 10 Nov 2003 12:36:58 -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 QQpofu03197
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Nov 2003 17:35:14 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 QQpofu26010
	for <mpls@UU.NET>; Mon, 10 Nov 2003 17:34: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 QQpofu09046
	for <mpls@UU.NET>; Mon, 10 Nov 2003 17:34:56 GMT
Received: from napoleon.monoski.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: c-67-162-155-17.client.comcast.net [67.162.155.17])
	id QQpofu09007
	for <mpls@UU.NET>; Mon, 10 Nov 2003 17:34:55 GMT
Received: from cisco.com (localhost [127.0.0.1])
	by napoleon.monoski.com (8.12.9/8.12.9) with ESMTP id hAAHYXuu005662;
	Mon, 10 Nov 2003 10:34:39 -0700 (MST)
Message-ID: <3FAFCC29.4010600@cisco.com>
Date: Mon, 10 Nov 2003 10:34:33 -0700
From: Luca Martini <lmartini@cisco.com>
Organization: Cisco Systems
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.2.1) Gecko/20030721
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Narendrakumar Limbani <narendrakumar.limbani@wipro.com>
CC: pwe3@ietf.org, mpls@UU.NET
Subject: Re: [PWE3] Setup of PW extending multiple tunnels
References: <7F396B9772328640B7593FA817EEEDAD89E6A9@blr-m3-msg.wipro.com>
In-Reply-To: <7F396B9772328640B7593FA817EEEDAD89E6A9@blr-m3-msg.wipro.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

The protocol does not preclude this situation.
yes it is possible.
Luca

Narendrakumar Limbani wrote:

> Hi,
>  
> I want to know whether it is possible to setup a PW extending multiple 
> tunnels.
>  
> for instance, I have setup like this
>  
>   A  ----p---------p--------   B    ------p----------p----------- C
>  
> I have one tunnel between A & B.
> I have one more tunnel between B & C.
>  
> Now is it possible to setup PW between A & B ?
> I am referring draft-ietf-pwe3-control-protocol-04.txt.
>  
>  
> Regds,
> Narendrakumar Limbani
>  
>  
>  
>
>  
>




From owner-mpls@UU.NET  Mon Nov 10 13:15: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 NAA03712
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 13:15: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 QQpofx25574
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 18:15: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 QQpofx24712;
	Mon, 10 Nov 2003 18:15:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpofv05264
	for mpls-outgoing; Mon, 10 Nov 2003 17:55:09 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 QQpofv05246
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Nov 2003 17:55:04 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 QQpofv29083
	for <mpls@UU.NET>; Mon, 10 Nov 2003 17:52:17 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 QQpofv16612
	for <mpls@UU.NET>; Mon, 10 Nov 2003 17:52:17 GMT
Received: from i2kc03-ukbr.domain1.systemhost.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp3.smtp.bt.com [217.32.164.138])
	id QQpofv16595
	for <mpls@UU.NET>; Mon, 10 Nov 2003 17:52:16 GMT
Received: from i2km96-ukbr.domain1.systemhost.net ([193.113.197.84]) by i2kc03-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 10 Nov 2003 17:52:16 +0000
Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km96-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 10 Nov 2003 17:52:16 +0000
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"
Content-Transfer-Encoding: quoted-printable
Subject: RE: on the mpls oam framework
Date: Mon, 10 Nov 2003 17:52:15 -0000
Message-ID: <0536FC9B908BEC4597EE721BE6A3538904EF2DF0@i2km07-ukbr.domain1.systemhost.net>
Thread-Topic: on the mpls oam framework
thread-index: AcOnoPd3PkSZiu6bTWOxUUTE3m2iaQAPML0w
To: <loa@pi.se>
Cc: <mpls@UU.NET>, <swallow@cisco.com>, <zinin@psg.com>
X-OriginalArrivalTime: 10 Nov 2003 17:52:16.0397 (UTC) FILETIME=[60F21BD0:01C3A7B3]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Loa....you are misrepresenting my 'agreement on the situation'.   I =
agree there is a problem.....but has it ever occurred to you that the =
starting point may be wrong?  The problem is not that Dave's paper fails =
to line-up with the MPLS arch papers, the problem is that the MPLS arch =
(sic) stuff is itself architecturally broken......the mere act of =
'doing' mp2p and PHP does not bless them with arch validity please note. =
 You can't expect Dave to fix that.....no doubt you also saw Dave's =
response.

I don't actually have any problem with all this *providing* people don't =
try and put a spin on things that are not correct to make them appear =
correct, ie one can't fix what is wrong/missing in MPLS by asking Dave =
to redo his paper...as its simply a statement of fact and is therefore =
'right'.  One can fix the MPLS arch of course, but this starts with an =
admission of what is not right now.....and I don't see any strong signs =
of this happening (at least any time soon), that is the key difference =
and the real problem here. =20

regards, Neil

> -----Original Message-----
> From: Loa Andersson [mailto:NtscpUsrLoa@netscape.net]
> Sent: 10 November 2003 15:38
> To: Harrison,N,Neil,IKR2 R
> Cc: loa@pi.se; mpls@UU.NET; swallow@cisco.com; zinin@psg.com
> Subject: Re: on the mpls oam framework
>=20
>=20
> Neil,
>=20
> I'm glad that you agree on the situation, and surprised on your
> attitude towards the guiding documents in MPLS development.
>=20
> We have the MPLS architecture and it is the starting point all
> other mpls documents, and should be so for the mpls om framework
> as well. To qoute you "Whether some people like it or not..."
>=20
> /Loa
>=20
> neil.2.harrison@bt.com wrote:
>=20
> >Loa,
> >
> >I agree there is a serious disconnect between the=20
> 'architecture' and what is being done in some places in IETF,=20
> eg PWE3.  Whether some people like them or not, G.805 and=20
> G.809 respresent the functional architecture of all=20
> technologies.....the former covers the co-cs and co-ps modes=20
> and the latter the cnls mode, and all technologies map to one=20
> of these modes.
> >
> >One must respect the architectural principles of the=20
> networking mode in question or else problems arise=20
> later.....the 'OAM problems' are one symptom of this.  The=20
> classic example that springs to mind is a link-connection (ie=20
> label) swapping co-ps forwarding mode (eg MPLS) that violates=20
> the allowed topological constructs of that mode (which in=20
> this case are p2p or p2mp) and terminates the trail 1 hop too=20
> soon (ie PHP).  There should also be layer independence in a=20
> simple client/server relationship, ie do not modify the client PDU.
> >
> >Keep the network architecture clean and the problems will=20
> not exist.......Dave (Allan's) paper is, in general, simply a=20
> survey of what has been 'done'.
> >
> >So please be very clear when identifying *where* the=20
> disconnects exist.....and they are not in Dave's paper.
> >
> >regards, Neil
> >
> > =20
> >
> >>-----Original Message-----
> >>From: Loa Andersson [mailto:NtscpUsrLoa@netscape.net]
> >>Sent: 10 November 2003 02:27
> >>To: MPLS wg
> >>Cc: George Swallow; Alex Zinin
> >>Subject: on the mpls oam framework
> >>
> >>
> >>All,
> >>
> >>I read the mpls oam framework as it has been suggested in
> >>Dave Allans draft (draft-allan-mpls-oam-frmwrk) and also
> >>re-read the the mpls architecture document. I've the architecture
> >>authors to review the oam framework and received some feedback
> >>from them.
> >>
> >>It is my understanding that there is a serious disconnect
> >>between the architecture and oam framework, and I therefore
> >>want to restart the oam framework in a fresh document,
> >>with the undertanding that this document shall be aligned
> >>with the architecture.
> >>
> >>I asked David Allan and Tom Nadeau to take on the editorship
> >>for this new document, and hope to have positive answers from
> >>both of them before the mpls wg meeting in Minneapolis.
> >>
> >>/Loa
> >>
> >>   =20
> >>
> >
> > =20
> >
>=20
>=20


From owner-mpls@UU.NET  Mon Nov 10 13:53: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 NAA05454
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 13:53: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 QQpofz15720
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 18:53: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 QQpofz15573;
	Mon, 10 Nov 2003 18:53:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpofy27574
	for mpls-outgoing; Mon, 10 Nov 2003 18:34: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 QQpofy27569
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Nov 2003 18:33:58 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 QQpofy07693
	for <mpls@uu.net>; Mon, 10 Nov 2003 18:30: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 QQpofy25133
	for <mpls@uu.net>; Mon, 10 Nov 2003 18:30:57 GMT
Received: from sj-iport-4.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-4.cisco.com [171.68.10.86])
	id QQpofy25127
	for <mpls@uu.net>; Mon, 10 Nov 2003 18:30:56 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAAIUqxg017482
	for <mpls@uu.net>; Mon, 10 Nov 2003 13:30:52 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADW24219;
	Mon, 10 Nov 2003 13:30:50 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAAIUoC20225 for mpls@uu.net; Mon, 10 Nov 2003 13:30:50 -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 QQpofx27254
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Nov 2003 18:29:05 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 QQpofx26724
	for <mpls@UU.NET>; Mon, 10 Nov 2003 18:26: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 QQpofx07447
	for <mpls@UU.NET>; Mon, 10 Nov 2003 18:26:25 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 QQpofx07428
	for <mpls@UU.NET>; Mon, 10 Nov 2003 18:26:24 GMT
Received: (qmail 13453 invoked by uid 12059); 10 Nov 2003 18:26:24 -0000
Received: from Shahram_Davari@pmc-sierra.com by father by uid 101 with qmail-scanner-1.20rc3 
 (uvscan: v4.1.40/v4302.  Clear:RC:1:. 
 Processed in 0.132908 secs); 10 Nov 2003 18:26:24 -0000
Received: from unknown (HELO ogmios.pmc-sierra.bc.ca) (216.241.226.59)
  by father.pmc-sierra.com with SMTP; 10 Nov 2003 18:26:23 -0000
Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by ogmios.pmc-sierra.bc.ca (8.12.9/8.12.7) with ESMTP id hAAIQM8p006457;
	Mon, 10 Nov 2003 10:26:22 -0800
Received: by bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59)
	id <TFV29YVT>; Mon, 10 Nov 2003 10:26:21 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115CCCD@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'loa@pi.se'" <loa@pi.se>, MPLS wg <mpls@UU.NET>
Cc: George Swallow <swallow@cisco.com>, Alex Zinin <zinin@psg.com>
Subject: RE: on the mpls oam framework
Date: Mon, 10 Nov 2003 10:26: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

Loa,

Could you please technically articulate were the disconnect is?
and why isn't it resolvable, so that it needs a new draft?
In other words please provide valid justification for your
request.

Thanks,
-Shahram

>-----Original Message-----
>From: Loa Andersson [mailto:NtscpUsrLoa@netscape.net]
>Sent: Sunday, November 09, 2003 9:27 PM
>To: MPLS wg
>Cc: George Swallow; Alex Zinin
>Subject: on the mpls oam framework
>
>
>All,
>
>I read the mpls oam framework as it has been suggested in
>Dave Allans draft (draft-allan-mpls-oam-frmwrk) and also
>re-read the the mpls architecture document. I've the architecture
>authors to review the oam framework and received some feedback
>from them.
>
>It is my understanding that there is a serious disconnect
>between the architecture and oam framework, and I therefore
>want to restart the oam framework in a fresh document,
>with the undertanding that this document shall be aligned
>with the architecture.
>
>I asked David Allan and Tom Nadeau to take on the editorship
>for this new document, and hope to have positive answers from
>both of them before the mpls wg meeting in Minneapolis.
>
>/Loa
>



From owner-mpls@UU.NET  Mon Nov 10 15:16: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 PAA10848
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 15:16: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 QQpogf10098
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 20:16: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 QQpogf08635;
	Mon, 10 Nov 2003 20:16:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpogd24288
	for mpls-outgoing; Mon, 10 Nov 2003 19:56: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 QQpogd24283
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Nov 2003 19:56:46 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 QQpogd24624
	for <mpls@uu.net>; Mon, 10 Nov 2003 19: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 QQpogd15409
	for <mpls@uu.net>; Mon, 10 Nov 2003 19:55:09 GMT
Received: from imo-d02.mx.aol.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imo-d02.mx.aol.com [205.188.157.34])
	id QQpogd15399
	for <mpls@uu.net>; Mon, 10 Nov 2003 19:55:08 GMT
Received: from NtscpUsrLoa@netscape.net
	by imo-d02.mx.aol.com (mail_out_v36_r1.1.) id p.ec.b42d5f3 (16240);
	Mon, 10 Nov 2003 14:54:57 -0500 (EST)
Received: from  netscape.net (dyn136-235.ietf58.ietf.org [130.129.136.235]) by air-in03.mx.aol.com (v97.8) with ESMTP id MAILININ34-3f703fafed1015; Mon, 10 Nov 2003 14:54:57 -0500
Message-ID: <3FAFECF7.6050406@netscape.net>
Date: Mon, 10 Nov 2003 20:54:31 +0100
From: Loa Andersson <NtscpUsrLoa@netscape.net>
Reply-To: loa@pi.se
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: neil.2.harrison@bt.com
CC: loa@pi.se, mpls@UU.NET, swallow@cisco.com, zinin@psg.com
Subject: Re: on the mpls oam framework
References: <0536FC9B908BEC4597EE721BE6A3538904EF2DF0@i2km07-ukbr.domain1.systemhost.net>
In-Reply-To: <0536FC9B908BEC4597EE721BE6A3538904EF2DF0@i2km07-ukbr.domain1.systemhost.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AOL-IP: 130.129.136.235
X-Mailer: Unknown (No Version)
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Neil,

I don't a need to be right - but it still seems like we agree
that there is a problem, and that problemis that there is a
disconnect between the "oam framework" and the mpls archtecture,
isn't that true.

The rest is jus the pesonal opnions of you and me.

We disagree exactly on how things are broken, I take it that you
want to discard the mpls architecture, my point is that the mpls
architecture is one the guiding doucments for the mpls wg, and as
such served us fine so far, and would like to stay with it.

Though I don't see how we could push forward with an id that
some of the authors and editor agree is not aligned with the
mpls architecture.


/Loa

 

neil.2.harrison@bt.com wrote:

>Loa....you are misrepresenting my 'agreement on the situation'.   I agree there is a problem.....but has it ever occurred to you that the starting point may be wrong?  The problem is not that Dave's paper fails to line-up with the MPLS arch papers, the problem is that the MPLS arch (sic) stuff is itself architecturally broken......the mere act of 'doing' mp2p and PHP does not bless them with arch validity please note.  You can't expect Dave to fix that.....no doubt you also saw Dave's response.
>
>I don't actually have any problem with all this *providing* people don't try and put a spin on things that are not correct to make them appear correct, ie one can't fix what is wrong/missing in MPLS by asking Dave to redo his paper...as its simply a statement of fact and is therefore 'right'.  One can fix the MPLS arch of course, but this starts with an admission of what is not right now.....and I don't see any strong signs of this happening (at least any time soon), that is the key difference and the real problem here.  
>
>regards, Neil
>
>  
>
>>-----Original Message-----
>>From: Loa Andersson [mailto:NtscpUsrLoa@netscape.net]
>>Sent: 10 November 2003 15:38
>>To: Harrison,N,Neil,IKR2 R
>>Cc: loa@pi.se; mpls@UU.NET; swallow@cisco.com; zinin@psg.com
>>Subject: Re: on the mpls oam framework
>>
>>
>>Neil,
>>
>>I'm glad that you agree on the situation, and surprised on your
>>attitude towards the guiding documents in MPLS development.
>>
>>We have the MPLS architecture and it is the starting point all
>>other mpls documents, and should be so for the mpls om framework
>>as well. To qoute you "Whether some people like it or not..."
>>
>>/Loa
>>
>>neil.2.harrison@bt.com wrote:
>>
>>    
>>
>>>Loa,
>>>
>>>I agree there is a serious disconnect between the 
>>>      
>>>
>>'architecture' and what is being done in some places in IETF, 
>>eg PWE3.  Whether some people like them or not, G.805 and 
>>G.809 respresent the functional architecture of all 
>>technologies.....the former covers the co-cs and co-ps modes 
>>and the latter the cnls mode, and all technologies map to one 
>>of these modes.
>>    
>>
>>>One must respect the architectural principles of the 
>>>      
>>>
>>networking mode in question or else problems arise 
>>later.....the 'OAM problems' are one symptom of this.  The 
>>classic example that springs to mind is a link-connection (ie 
>>label) swapping co-ps forwarding mode (eg MPLS) that violates 
>>the allowed topological constructs of that mode (which in 
>>this case are p2p or p2mp) and terminates the trail 1 hop too 
>>soon (ie PHP).  There should also be layer independence in a 
>>simple client/server relationship, ie do not modify the client PDU.
>>    
>>
>>>Keep the network architecture clean and the problems will 
>>>      
>>>
>>not exist.......Dave (Allan's) paper is, in general, simply a 
>>survey of what has been 'done'.
>>    
>>
>>>So please be very clear when identifying *where* the 
>>>      
>>>
>>disconnects exist.....and they are not in Dave's paper.
>>    
>>
>>>regards, Neil
>>>
>>> 
>>>
>>>      
>>>
>>>>-----Original Message-----
>>>>From: Loa Andersson [mailto:NtscpUsrLoa@netscape.net]
>>>>Sent: 10 November 2003 02:27
>>>>To: MPLS wg
>>>>Cc: George Swallow; Alex Zinin
>>>>Subject: on the mpls oam framework
>>>>
>>>>
>>>>All,
>>>>
>>>>I read the mpls oam framework as it has been suggested in
>>>>Dave Allans draft (draft-allan-mpls-oam-frmwrk) and also
>>>>re-read the the mpls architecture document. I've the architecture
>>>>authors to review the oam framework and received some feedback
>>>>        
>>>>
>>>>from them.
>>>      
>>>
>>>>It is my understanding that there is a serious disconnect
>>>>between the architecture and oam framework, and I therefore
>>>>want to restart the oam framework in a fresh document,
>>>>with the undertanding that this document shall be aligned
>>>>with the architecture.
>>>>
>>>>I asked David Allan and Tom Nadeau to take on the editorship
>>>>for this new document, and hope to have positive answers from
>>>>both of them before the mpls wg meeting in Minneapolis.
>>>>
>>>>/Loa
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>> 
>>>
>>>      
>>>
>
>  
>



From owner-mpls@UU.NET  Mon Nov 10 15:31: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 PAA11895
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 15:31: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 QQpogg01826
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 20:32:09 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 QQpogg01626;
	Mon, 10 Nov 2003 20:32:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoge14438
	for mpls-outgoing; Mon, 10 Nov 2003 20:12: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 QQpoge14433
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Nov 2003 20:12:47 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 QQpoge09933
	for <mpls@uu.net>; Mon, 10 Nov 2003 20:12: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 QQpoge03041
	for <mpls@uu.net>; Mon, 10 Nov 2003 20:12:29 GMT
Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint2.juniper.net [207.17.136.150])
	id QQpoge03022
	for <mpls@uu.net>; Mon, 10 Nov 2003 20:12:28 GMT
Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id hAAKCRi41238;
	Mon, 10 Nov 2003 12:12:27 -0800 (PST)
	(envelope-from ina@juniper.net)
Date: Mon, 10 Nov 2003 12:12:27 -0800 (PST)
From: Ina Minei <ina@juniper.net>
To: jason rusmisel <jason.rusmisel@alcatel.com>
cc: mpls@UU.NET
Subject: Re: I-D ACTION:draft-minei-mpls-ldp-external-00.txt (fwd)
In-Reply-To: <3FAFC7E9.3010103@alcatel.com>
Message-ID: <20031110114254.W8920@garnet.juniper.net>
References: <20031013100945.T88214@garnet.juniper.net> <3FAFC7E9.3010103@alcatel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


      Please see answers innline, marked ###.

                          Thank you,

                                  Ina

On Mon, 10 Nov 2003, jason rusmisel wrote:

> A question for you:
>
> If I understand correctly, the motivation for this draft is to allow LDP
> to be the single mechanism to distribute reachability rather than
> counting on a 2547bis-like mechanism.

### The motivation for this draft is to allow establishment of LDP
signaled LSPs without having to inject routes for them in the IGP.
The 2547bit scenario is an example of using the proposed extension.

> The overall approach of carrying the External FEC in the FEC TLV
> guarantees that these label mappings will not be propagated in a network
> of mixed LDP implementations.  Have you considered this situation?
>

### In a mixed network, LSPs for external FECs will be established only
through nodes that support this functionality, thus ensuring consistent
establishment of the LSPs. Note that since we don't have routing table
entries for these FECs, nodes not supporting the extension would not
propagate mappings for them anyway.

 > Jason Rusmisel.
>
> Ina Minei wrote:
>
> >   This document describes a mechanism that allows the creation of LDP
> >signaled LSPs for prefixes which are not present in the routing table.
> >
> >   Comments welcome,
> >
> >		Thank you,
> >
> >			Ina Minei
> >
> >---------- Forwarded message ----------
> >Date: 7 Oct 03 15:00:15 GMT
> >From: Internet-Drafts@ietf.org
> >To: IETF-Announce:  ;
> >Newsgroups: jnx.ext.ietf.announce
> >Subject: I-D ACTION:draft-minei-mpls-ldp-external-00.txt
> >
> >A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >
> >
> >	Title		: LDP signaled LSPs for external prefixes
> >	Author(s)	: L. Fang, et. al.
> >	Filename	: draft-minei-mpls-ldp-external-00.txt
> >	Pages		: 6
> >	Date		: 2003-10-7
> >
> >In order to create forwarding state for a FEC received from a downstream
> >LSR, LDP requires the presence of a matching entry in the routing table.
> >This document describes a mechanism that allows the creation of LDP
> >signaled LSPs for prefixes which are not present in the routing table.
> >This draft is applicable to address prefix FECs and host FECs associated
> >with either IPv4 or IPv6 prefixes.
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-minei-mpls-ldp-external-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-minei-mpls-ldp-external-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-minei-mpls-ldp-external-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.
> >
>


From owner-mpls@UU.NET  Mon Nov 10 15:49: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 PAA12856
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 15:49: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 QQpogh26067
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 20:49: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 QQpogh25970;
	Mon, 10 Nov 2003 20:49:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpogf16096
	for mpls-outgoing; Mon, 10 Nov 2003 20:29: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 QQpogf16088
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Nov 2003 20:29:40 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 QQpogf19891
	for <mpls@uu.net>; Mon, 10 Nov 2003 20:29: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 QQpogf03012
	for <mpls@uu.net>; Mon, 10 Nov 2003 20:29:25 GMT
Received: from sj-iport-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70])
	id QQpogf02947
	for <mpls@uu.net>; Mon, 10 Nov 2003 20:29:23 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAAKTIAv017145
	for <mpls@uu.net>; Mon, 10 Nov 2003 12:29:20 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADW38256;
	Mon, 10 Nov 2003 15:29:17 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAAKTHd24937 for mpls@uu.net; Mon, 10 Nov 2003 15:29:17 -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 QQpogf15993
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Nov 2003 20:27:08 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 QQpogf11590
	for <mpls@uu.net>; Mon, 10 Nov 2003 20:26: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 QQpogf28980
	for <mpls@uu.net>; Mon, 10 Nov 2003 20:26:27 GMT
Received: from netreference.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: netreference.com [216.151.229.253])
	id QQpogf28962
	for <mpls@uu.net>; Mon, 10 Nov 2003 20:26:27 GMT
Received: from ILAZAR.mplsrc.com (192.168.1.94) by netreference.com
 with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 10 Nov 2003 16:32:12 -0400
Message-Id: <5.1.0.14.2.20031110151617.00ac0f70@mail.earthlink.net>
X-Sender: news/mplsrc.com@localhost (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 10 Nov 2003 15:25:29 -0500
To: (Recipient list suppressed)
From: MPLS RC News <news@mplsrc.com>
Subject: MPLScon 2004 - Call for Presentations
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

**Call for Presentations - MPLScon Spring 2004**

MPLScon 2004 takes place on May 24-27 at the Marriott Financial Center in 
New York City, NY.

Now in it's fourth year, MPLScon focuses on providing vendors, service 
providers, and enterprise customers with information on technologies, 
trends, and challenges surrounding Multiprotocol Label Switching and 
MPLS-based services.   MPLScon provides network decision makers with the 
information they need to understand, evaluate, and deploy MPLS-based services.

MPLScon seeks qualified individuals to present on a variety of topics of 
interest to vendor, service provider, and enterprise communities.  A 
complete list of topics and themes can be found at 
http://www.mplscon.com/speaker/submit_pres.html

Presentation submissions are due November 19, 2003.   Questions should be 
addressed to Irwin Lazar, Conference Director, ilazar@mplscon.com, 
703-742-9659.




From owner-mpls@UU.NET  Mon Nov 10 18:39: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 SAA22915
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 18:39: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 QQpogs22945
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 23:40: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 QQpogs22719;
	Mon, 10 Nov 2003 23:39:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpogr28362
	for mpls-outgoing; Mon, 10 Nov 2003 23:21: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 QQpogr28353
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Nov 2003 23:21: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 QQpogr08243
	for <mpls@uu.net>; Mon, 10 Nov 2003 23:20: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 QQpogr00100
	for <mpls@uu.net>; Mon, 10 Nov 2003 23:20:37 GMT
Received: from imo-d02.mx.aol.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imo-d02.mx.aol.com [205.188.157.34])
	id QQpogr00090
	for <mpls@uu.net>; Mon, 10 Nov 2003 23:20:37 GMT
Received: from NtscpUsrLoa@netscape.net
	by imo-d02.mx.aol.com (mail_out_v36_r1.1.) id 9.1b2.87dff0f (22681);
	Mon, 10 Nov 2003 18:20:33 -0500 (EST)
Received: from  netscape.net (dyn136-235.ietf58.ietf.org [130.129.136.235]) by air-in04.mx.aol.com (v97.8) with ESMTP id MAILININ42-58993fb01d3f2d1; Mon, 10 Nov 2003 18:20:33 -0500
Message-ID: <3FB01D2D.9080107@netscape.net>
Date: Tue, 11 Nov 2003 00:20:13 +0100
From: Loa Andersson <NtscpUsrLoa@netscape.net>
Reply-To: loa@pi.se
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
CC: MPLS wg <mpls@UU.NET>, George Swallow <swallow@cisco.com>,
        Alex Zinin <zinin@psg.com>
Subject: Re: on the mpls oam framework
References: <4B6D09F3B826D411A67300D0B706EFDE0115CCCD@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca>
In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115CCCD@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-AOL-IP: 130.129.136.235
X-Mailer: Unknown (No Version)
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Sharam,

note that Neil, Dave and I agree on that the disconnect is there,
I'm not certain that they agree with how I described (but that
is also part of the disconnect :) ).

Anyway - I guess that the core of the matter is that the architecture
is written positioning mpls as a part of the ip protocol suite, while
the oam framework rather position it as a "newer and better ATM" that
necessarily needs to have all the features of ATM.

This shows up in a numbe of places, the concept of layers and levels
is, not what I see as useful in the type of IP network I've been
involved in.

The definition of "LSP" is not what is in the architecture document.

PHP is designed out by the oam framework, but an in by the mpls
architecture.

But you are misrepresenting me when you say that the differences is
not resolvable. In fact the proposal to start on a fresh document
is intended jsut to achieve that. I guess that if there are two people
representing two different ideas on a subject, the requirement that one
of the has to accept the ideas of the other to be part work seems to
be counter-productive.

Further if we have a "default" document in this case it should be the
architecture.

/Loa

Shahram Davari wrote:

>Loa,
>
>Could you please technically articulate were the disconnect is?
>and why isn't it resolvable, so that it needs a new draft?
>In other words please provide valid justification for your
>request.
>
>Thanks,
>-Shahram
>
>  
>
>>-----Original Message-----
>>From: Loa Andersson [mailto:NtscpUsrLoa@netscape.net]
>>Sent: Sunday, November 09, 2003 9:27 PM
>>To: MPLS wg
>>Cc: George Swallow; Alex Zinin
>>Subject: on the mpls oam framework
>>
>>
>>All,
>>
>>I read the mpls oam framework as it has been suggested in
>>Dave Allans draft (draft-allan-mpls-oam-frmwrk) and also
>>re-read the the mpls architecture document. I've the architecture
>>authors to review the oam framework and received some feedback
>>    
>>
>>from them.
>  
>
>>It is my understanding that there is a serious disconnect
>>between the architecture and oam framework, and I therefore
>>want to restart the oam framework in a fresh document,
>>with the undertanding that this document shall be aligned
>>with the architecture.
>>
>>I asked David Allan and Tom Nadeau to take on the editorship
>>for this new document, and hope to have positive answers from
>>both of them before the mpls wg meeting in Minneapolis.
>>
>>/Loa
>>
>>    
>>
>
>
>  
>



From owner-mpls@UU.NET  Mon Nov 10 19:17: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 TAA25301
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 19:17: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 QQpogv12095
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 00:17: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 QQpogv11908;
	Tue, 11 Nov 2003 00:17:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpogt01232
	for mpls-outgoing; Mon, 10 Nov 2003 23:58: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 QQpogt01227
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Nov 2003 23:58: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 QQpogt14150
	for <mpls@UU.NET>; Mon, 10 Nov 2003 23:57: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 QQpogt11954
	for <mpls@UU.NET>; Mon, 10 Nov 2003 23:57:30 GMT
Received: from ckmso1.proxy.att.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ckmso1.att.com [12.20.58.69])
	id QQpogt11935
	for <mpls@UU.NET>; Mon, 10 Nov 2003 23:57:29 GMT
Received: from attrh5i.attrh.att.com ([135.38.62.12])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id hAANv8hY013309
	for <mpls@UU.NET>; Mon, 10 Nov 2003 18:57:28 -0500
Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (6.5.032)
        id 3F307C6C01C40B64; Mon, 10 Nov 2003 18:57:09 -0500
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="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D ACTION:draft-lai-mpls-ldp-hist-mib-00.txt
Date: Mon, 10 Nov 2003 17:57:28 -0600
Message-ID: <7AFE40EF30EE754DA967D1B5968457CA02165E7E@KCCLUST06EVS1.ugd.att.com>
Thread-Topic: I-D ACTION:draft-lai-mpls-ldp-hist-mib-00.txt
Thread-Index: AcOm5F3CMsIJzZZCSiK3JYDmS27BawA2OYUw
From: "Lai, Wai S (Waisum), ALABS" <wlai@att.com>
To: <jcucchiara@mindspring.com>
Cc: <mpls@UU.NET>, "Ash, Gerald R (Jerry), ALABS" <gash@att.com>,
        "Chung, Li-Jin W, ALABS" <lic@att.com>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Joan,
  Thanks for your review of our draft and the comments below.
  As described in Section 2.1 of our draft, our requirements are very
specific, i.e., for the engineering of LDP Sessions and router resource
management.  To meet this requirement, there is a need to capture the
signaling usage/performance of the LDP Entities, and the traffic usage/
performance of the LDP Sessions.  Another specific requirement for
fault management is the need for persistent LSP information that
survives LSP failures.  The draft currently proposes five additional
objects, while the issue of measurement interval and recording counters
to maintain persistent history has been left open for further
discussion.
  We would like to hear also other SP's view on our draft.  Comments
and suggestions on how the above requirements could/should be met are
particularly welcome.
Thanks, Wai Sum

-----Original Message-----
From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com]
Sent: Sunday, November 09, 2003 12:13 PM
To: Lai, Wai S (Waisum), ALABS
Cc: mpls@UU.NET
Subject: Re: I-D ACTION:draft-lai-mpls-ldp-hist-mib-00.txt



Hi Wai Sum,

I have read this draft several times and was confused by it.
The requirements are very broad areas (i.e. Performance Management
Requirement,
Fault Management Requirement), however, the proposed solution of adding
5 new
objects so as to lessen the burden on the SNMP manager (NMS),
did not follow.

The objects being proposed are also confusing to me.  The Attempted
Session counter is already in the MPLS-LDP-STD-MIB and the=20
other 2 are totals don't provide relevant information in my opinion.
Why does an operator care about an Entity which is a MIB constuct
and not really important to LDP performance?

Also, the packet counters are not going to be useful unless you
are utilizing an NMS to monitor every node, and every LDP-LSP from
start to end.  You say you do not want to "burden" the network with
additional NMS traffic or increase polling on nodes,=20
but that would be the only way to make these counters useful=20
as far as I can tell.

I would like to hear from other operators on this draft.

  thanks, Joan


At 06:29 PM 10/22/03 -0400, Internet-Drafts@ietf.org wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
>	Title		: A Supplementary History Module for the MPLS
LDP-MIB
>	Author(s)	: W. Lai
>	Filename	: draft-lai-mpls-ldp-hist-mib-00.txt
>	Pages		: 8
>	Date		: 2003-10-22
>=09
>In this document, requirements for supplementing the MPLS LDP-MIB=20
>are presented for the support of specific network management needs=20
>for fault and performance management.  Based on these requirements,=20
>it describes managed objects in a supplementary history module for=20
>use with the LDP-MIB.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-lai-mpls-ldp-hist-mib-00.txt
>


From owner-mpls@UU.NET  Mon Nov 10 20:17: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 UAA27104
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 20:17: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 QQpogz01685
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 01:17: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 QQpogz01532;
	Tue, 11 Nov 2003 01:17:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpogx25247
	for mpls-outgoing; Tue, 11 Nov 2003 00:57: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 QQpogx25242
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 00:57:17 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 QQpogx29935
	for <mpls@uu.net>; Tue, 11 Nov 2003 00:54: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 QQpogx03712
	for <mpls@uu.net>; Tue, 11 Nov 2003 00:54:09 GMT
Received: from tiger.seabridge.co.il by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [212.25.127.226])
	id QQpogx03671
	for <mpls@uu.net>; Tue, 11 Nov 2003 00:54:07 GMT
Received: by tiger.seabridge.co.il with Internet Mail Service (5.5.2653.19)
	id <V1ZD1XND>; Tue, 11 Nov 2003 02:54:23 +0200
Message-ID: <C87E5A01714C7840B92CDED9E79329CA0117D11B@leopard.seabridge.co.il>
From: Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>
To: "'cheenu@bloomberg.net'" <cheenu@bloomberg.net>,
        "'arunv@force10networks.com'" <arunv@force10networks.com>,
        "'tnadeau@cisco.com'" <tnadeau@cisco.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>,
        "'ccamp@ops.ietf.org'"
	 <ccamp@ops.ietf.org>
Subject: MPLS Tunnel Maximum Hops
Date: Tue, 11 Nov 2003 02:54:18 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="windows-1255"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,
I have a comment regarding the mplsTunnelMaxHops scalar that indicates the
maximum number of hops that can be specified on each tunnel supported by the
LSR.
This scalar is a read only attribute but I can find it very useful to let
configure it as well. 
One of the CSPF constraints is the maximum number of hops the LSP may follow
through. The limitation on the maximum number for example can result from
the maximum packet size when fragmentation is not supported. In such a case
the maximum number of hops can depend on the network nature
(numbered/unnumbered). Instead of hard coding it with the worst case number,
let the network administrator, that is aware  of the network nature,
configure it.
Thanks, Nurit.


From owner-mpls@UU.NET  Mon Nov 10 21:44: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 VAA01220
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 21:44: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 QQpohe03746
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 02:44: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 QQpohe03542;
	Tue, 11 Nov 2003 02:44:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpohd10499
	for mpls-outgoing; Tue, 11 Nov 2003 02:24:19 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 QQpohd10494
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 02:24: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 QQpohd14662
	for <mpls@UU.NET>; Tue, 11 Nov 2003 02:23: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 QQpohd19683
	for <mpls@UU.NET>; Tue, 11 Nov 2003 02:23:53 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 QQpohd19671
	for <mpls@UU.NET>; Tue, 11 Nov 2003 02:23:52 GMT
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAB2Mwh17165
	for <mpls@UU.NET>; Mon, 10 Nov 2003 20:23:12 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59)
	id <WMXRWZH6>; Tue, 11 Nov 2003 03:22:56 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502EAF60E@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "Lai, Wai S (Waisum), ALABS" <wlai@att.com>, jcucchiara@mindspring.com
Cc: mpls@UU.NET, "Ash, Gerald R (Jerry), ALABS" <gash@att.com>,
        "Chung, Li-Jin W, ALABS" <lic@att.com>
Subject: RE: I-D ACTION:draft-lai-mpls-ldp-hist-mib-00.txt
Date: Tue, 11 Nov 2003 03:22:55 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

> ....  The draft currently proposes five additional
> objects, while the issue of measurement interval and 
> recording counters to maintain persistent history has
> been left open for further discussion.

Are you aware of RFC3593 ??
Is that something that might be usable here?

Bert


From owner-mpls@UU.NET  Mon Nov 10 22: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 WAA01972
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 22: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 QQpohg12735
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 03:09: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 QQpohg12590;
	Tue, 11 Nov 2003 03:09:18 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpohf13562
	for mpls-outgoing; Tue, 11 Nov 2003 02:51: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 QQpohf13557
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 02:51:30 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 QQpohf01330
	for <mpls@uu.net>; Tue, 11 Nov 2003 02:48: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 QQpohf16940
	for <mpls@uu.net>; Tue, 11 Nov 2003 02:48:02 GMT
Received: from sj-iport-3.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72])
	id QQpohf16921
	for <mpls@uu.net>; Tue, 11 Nov 2003 02:48:02 GMT
Received: from cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 10 Nov 2003 18:54:22 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAB2lwmU009255
	for <mpls@uu.net>; Mon, 10 Nov 2003 18:47:58 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADW64332;
	Mon, 10 Nov 2003 21:47:57 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAB2lvH02888 for mpls@uu.net; Mon, 10 Nov 2003 21:47:57 -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 QQpohf13107
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 02:46:33 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 QQpohf05538
	for <mpls@uu.net>; Tue, 11 Nov 2003 02: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 QQpohf14052
	for <mpls@uu.net>; Tue, 11 Nov 2003 02:45:15 GMT
Received: from sj-iport-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70])
	id QQpohf14042
	for <mpls@uu.net>; Tue, 11 Nov 2003 02:45:15 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAB2j9mW006881;
	Mon, 10 Nov 2003 18:45:12 -0800 (PST)
Received: from tnadeauw2k02 (che-vpn-cluster-2-150.cisco.com [10.86.242.150])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADW64233;
	Mon, 10 Nov 2003 21:45:08 -0500 (EST)
Reply-To: <tnadeau@cisco.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
To: <loa@pi.se>, "'MPLS wg'" <mpls@UU.NET>
Cc: "'George Swallow'" <swallow@cisco.com>, "'Alex Zinin'" <zinin@psg.com>
Subject: RE: on the mpls oam framework
Date: Mon, 10 Nov 2003 21:42:16 -0500
Organization: Cisco Systems, inc.
Message-ID: <008701c3a7fd$a3cea820$63808182@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
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <3FAEF78A.6050201@netscape.net>
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 Loa Andersson
>Sent: Sunday, November 09, 2003 9:27 PM
>To: MPLS wg
>Cc: George Swallow; Alex Zinin
>Subject: on the mpls oam framework
>
>
>All,
>
>I read the mpls oam framework as it has been suggested in
>Dave Allans draft (draft-allan-mpls-oam-frmwrk) and also
>re-read the the mpls architecture document. I've the architecture
>authors to review the oam framework and received some feedback
>from them.
>
>It is my understanding that there is a serious disconnect
>between the architecture and oam framework, and I therefore
>want to restart the oam framework in a fresh document,
>with the undertanding that this document shall be aligned
>with the architecture.
>
>I asked David Allan and Tom Nadeau to take on the editorship
>for this new document, and hope to have positive answers from
>both of them before the mpls wg meeting in Minneapolis.

	I would be happy to work with Dave to co-edit the new draft.

	--Tom





From owner-mpls@UU.NET  Mon Nov 10 22:23: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 WAA02309
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 22:23: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 QQpohh01785
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 03:23: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 QQpohh01522;
	Tue, 11 Nov 2003 03:23:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpohg27471
	for mpls-outgoing; Tue, 11 Nov 2003 03:04: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 QQpohg27330
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 03:04: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 QQpohg03525
	for <mpls@uu.net>; Tue, 11 Nov 2003 03:03: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 QQpohg04291
	for <mpls@uu.net>; Tue, 11 Nov 2003 03:03:29 GMT
Received: from sj-iport-4.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-4.cisco.com [171.68.10.86])
	id QQpohg04265
	for <mpls@uu.net>; Tue, 11 Nov 2003 03:03:29 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAB33PDM012212
	for <mpls@uu.net>; Mon, 10 Nov 2003 22:03:25 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADW64891;
	Mon, 10 Nov 2003 22:03:24 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAB33Of03735 for mpls@uu.net; Mon, 10 Nov 2003 22:03:24 -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 QQpohf14092
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 02:58: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 QQpohf06650
	for <mpls@UU.NET>; Tue, 11 Nov 2003 02:57: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 QQpohf27063
	for <mpls@UU.NET>; Tue, 11 Nov 2003 02:57:17 GMT
Received: from napoleon.monoski.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: c-67-162-155-17.client.comcast.net [67.162.155.17])
	id QQpohf27053
	for <mpls@UU.NET>; Tue, 11 Nov 2003 02:57:16 GMT
Received: from cisco.com (localhost [127.0.0.1])
	by napoleon.monoski.com (8.12.9/8.12.9) with ESMTP id hAB2uvuu017598;
	Mon, 10 Nov 2003 19:57:02 -0700 (MST)
Message-ID: <3FB04FF9.6000107@cisco.com>
Date: Mon, 10 Nov 2003 19:56:57 -0700
From: Luca Martini <lmartini@cisco.com>
Organization: Cisco Systems
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.2.1) Gecko/20030721
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ina Minei <ina@juniper.net>
CC: jason rusmisel <jason.rusmisel@alcatel.com>, mpls@UU.NET
Subject: Re: I-D ACTION:draft-minei-mpls-ldp-external-00.txt (fwd)
References: <20031013100945.T88214@garnet.juniper.net> <3FAFC7E9.3010103@alcatel.com> <20031110114254.W8920@garnet.juniper.net>
In-Reply-To: <20031110114254.W8920@garnet.juniper.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

so what is wrong with using the IBGP, and 3 label MPLS stack , while 
leaving LDP out of the routing business ?

Luca

Ina Minei wrote:

>      Please see answers innline, marked ###.
>
>                          Thank you,
>
>                                  Ina
>
>On Mon, 10 Nov 2003, jason rusmisel wrote:
>
>  
>
>>A question for you:
>>
>>If I understand correctly, the motivation for this draft is to allow LDP
>>to be the single mechanism to distribute reachability rather than
>>counting on a 2547bis-like mechanism.
>>    
>>
>
>### The motivation for this draft is to allow establishment of LDP
>signaled LSPs without having to inject routes for them in the IGP.
>The 2547bit scenario is an example of using the proposed extension.
>
>  
>
>>The overall approach of carrying the External FEC in the FEC TLV
>>guarantees that these label mappings will not be propagated in a network
>>of mixed LDP implementations.  Have you considered this situation?
>>
>>    
>>
>
>### In a mixed network, LSPs for external FECs will be established only
>through nodes that support this functionality, thus ensuring consistent
>establishment of the LSPs. Note that since we don't have routing table
>entries for these FECs, nodes not supporting the extension would not
>propagate mappings for them anyway.
>
> > Jason Rusmisel.
>  
>
>>Ina Minei wrote:
>>
>>    
>>
>>>  This document describes a mechanism that allows the creation of LDP
>>>signaled LSPs for prefixes which are not present in the routing table.
>>>
>>>  Comments welcome,
>>>
>>>		Thank you,
>>>
>>>			Ina Minei
>>>
>>>---------- Forwarded message ----------
>>>Date: 7 Oct 03 15:00:15 GMT
>>>From: Internet-Drafts@ietf.org
>>>To: IETF-Announce:  ;
>>>Newsgroups: jnx.ext.ietf.announce
>>>Subject: I-D ACTION:draft-minei-mpls-ldp-external-00.txt
>>>
>>>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>
>>>
>>>	Title		: LDP signaled LSPs for external prefixes
>>>	Author(s)	: L. Fang, et. al.
>>>	Filename	: draft-minei-mpls-ldp-external-00.txt
>>>	Pages		: 6
>>>	Date		: 2003-10-7
>>>
>>>In order to create forwarding state for a FEC received from a downstream
>>>LSR, LDP requires the presence of a matching entry in the routing table.
>>>This document describes a mechanism that allows the creation of LDP
>>>signaled LSPs for prefixes which are not present in the routing table.
>>>This draft is applicable to address prefix FECs and host FECs associated
>>>with either IPv4 or IPv6 prefixes.
>>>
>>>A URL for this Internet-Draft is:
>>>http://www.ietf.org/internet-drafts/draft-minei-mpls-ldp-external-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-minei-mpls-ldp-external-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-minei-mpls-ldp-external-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.
>>>
>>>      
>>>
>
>  
>




From owner-mpls@UU.NET  Mon Nov 10 22:41: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 WAA03046
	for <mpls-archive@lists.ietf.org>; Mon, 10 Nov 2003 22:41: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 QQpohi21580
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 03:41: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 QQpohi21236;
	Tue, 11 Nov 2003 03:41:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpohh05505
	for mpls-outgoing; Tue, 11 Nov 2003 03:19:54 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 QQpohh05500
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 03:19:53 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 QQpohh04611
	for <mpls@uu.net>; Tue, 11 Nov 2003 03: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 QQpohh06670
	for <mpls@uu.net>; Tue, 11 Nov 2003 03:15:09 GMT
Received: from sj-iport-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72])
	id QQpohh06648
	for <mpls@uu.net>; Tue, 11 Nov 2003 03:15:08 GMT
Received: from cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 10 Nov 2003 19:21:28 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAB3F4mU025690
	for <mpls@uu.net>; Mon, 10 Nov 2003 19:15:05 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADW65609;
	Mon, 10 Nov 2003 22:15:04 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAB3F4506143 for mpls@uu.net; Mon, 10 Nov 2003 22:15: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 QQpohg04456
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 03:13: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 QQpohg29871
	for <mpls@uu.net>; Tue, 11 Nov 2003 03:12: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 QQpohg01155
	for <mpls@uu.net>; Tue, 11 Nov 2003 03:12:19 GMT
Received: from sj-iport-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71])
	id QQpohg01139
	for <mpls@uu.net>; Tue, 11 Nov 2003 03:12:18 GMT
Received: from cisco.com (171.71.177.238)
  by sj-iport-2.cisco.com with ESMTP; 10 Nov 2003 19:14:06 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAB3CEmU023839;
	Mon, 10 Nov 2003 19:12:15 -0800 (PST)
Received: from tnadeauw2k02 (che-vpn-cluster-2-150.cisco.com [10.86.242.150])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADW65513;
	Mon, 10 Nov 2003 22:12:13 -0500 (EST)
Reply-To: <tnadeau@cisco.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
To: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>, <loa@pi.se>,
        "'MPLS wg'" <mpls@UU.NET>
Cc: "'George Swallow'" <swallow@cisco.com>, "'Alex Zinin'" <zinin@psg.com>
Subject: RE: on the mpls oam framework
Date: Mon, 10 Nov 2003 22:12:08 -0500
Organization: Cisco Systems, inc.
Message-ID: <00ed01c3a801$9aaf76d0$63808182@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
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115CCCD@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


>Loa,
>
>Could you please technically articulate were the disconnect is?
>and why isn't it resolvable, so that it needs a new draft?
>In other words please provide valid justification for your
>request.

	A quick read of RFC3031 will reveal the disconnects.

	--Tom




>Thanks,
>-Shahram
>
>>-----Original Message-----
>>From: Loa Andersson [mailto:NtscpUsrLoa@netscape.net]
>>Sent: Sunday, November 09, 2003 9:27 PM
>>To: MPLS wg
>>Cc: George Swallow; Alex Zinin
>>Subject: on the mpls oam framework
>>
>>
>>All,
>>
>>I read the mpls oam framework as it has been suggested in
>>Dave Allans draft (draft-allan-mpls-oam-frmwrk) and also
>>re-read the the mpls architecture document. I've the architecture
>>authors to review the oam framework and received some feedback
>>from them.
>>
>>It is my understanding that there is a serious disconnect
>>between the architecture and oam framework, and I therefore
>>want to restart the oam framework in a fresh document,
>>with the undertanding that this document shall be aligned
>>with the architecture.
>>
>>I asked David Allan and Tom Nadeau to take on the editorship
>>for this new document, and hope to have positive answers from
>>both of them before the mpls wg meeting in Minneapolis.
>>
>>/Loa
>>
>
>




From owner-mpls@UU.NET  Tue Nov 11 00:23: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 AAA06302
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 00:23: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 QQpohp03602
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 05:23: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 QQpohp03195;
	Tue, 11 Nov 2003 05:23:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoho22244
	for mpls-outgoing; Tue, 11 Nov 2003 05:07:54 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 QQpoho22239
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 05:07:50 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 QQpoho11437
	for <mpls@uu.net>; Tue, 11 Nov 2003 05:05: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 QQpoho25937
	for <mpls@uu.net>; Tue, 11 Nov 2003 05:05:03 GMT
Received: from sj-iport-4.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-4.cisco.com [171.68.10.86])
	id QQpoho25919
	for <mpls@uu.net>; Tue, 11 Nov 2003 05:05:02 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAB54tmU025928
	for <mpls@uu.net>; Mon, 10 Nov 2003 21:04:56 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADW69008;
	Tue, 11 Nov 2003 00:04:54 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAB54su11355 for mpls@uu.net; Tue, 11 Nov 2003 00:04:54 -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 QQpoho15689
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 05:03: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 QQpoho15465
	for <mpls@UU.NET>; Tue, 11 Nov 2003 05:02:02 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 QQpoho14878
	for <mpls@UU.NET>; Tue, 11 Nov 2003 05:02: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 QQpoho14837
	for <mpls@UU.NET>; Tue, 11 Nov 2003 05:02:01 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.8p1/8.12.8) with ESMTP id hAB51ghO029795;
	Tue, 11 Nov 2003 00:01:43 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311110501.hAB51ghO029795@workhorse.fictitious.org>
To: loa@pi.se
cc: Shahram Davari <Shahram_Davari@pmc-sierra.com>, MPLS wg <mpls@UU.NET>,
        George Swallow <swallow@cisco.com>, Alex Zinin <zinin@psg.com>
Reply-To: curtis@fictitious.org
Subject: Re: on the mpls oam framework 
In-reply-to: Your message of "Tue, 11 Nov 2003 00:20:13 +0100."
             <3FB01D2D.9080107@netscape.net> 
Date: Tue, 11 Nov 2003 00:01:42 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <3FB01D2D.9080107@netscape.net>, Loa Andersson writes:
> Sharam,
> 
> note that Neil, Dave and I agree on that the disconnect is there,
> I'm not certain that they agree with how I described (but that
> is also part of the disconnect :) ).
> 
> Anyway - I guess that the core of the matter is that the architecture
> is written positioning mpls as a part of the ip protocol suite, while
> the oam framework rather position it as a "newer and better ATM" that
> necessarily needs to have all the features of ATM.
> 
> This shows up in a numbe of places, the concept of layers and levels
> is, not what I see as useful in the type of IP network I've been
> involved in.
> 
> The definition of "LSP" is not what is in the architecture document.
> 
> PHP is designed out by the oam framework, but an in by the mpls
> architecture.
> 
> But you are misrepresenting me when you say that the differences is
> not resolvable. In fact the proposal to start on a fresh document
> is intended jsut to achieve that. I guess that if there are two people
> representing two different ideas on a subject, the requirement that one
> of the has to accept the ideas of the other to be part work seems to
> be counter-productive.
> 
> Further if we have a "default" document in this case it should be the
> architecture.
> 
> /Loa



Loa,

The default is reality and reality seems to be that PHP is here and
PHP is not going away any time soon.  So far Dave and Neil have not
made a compelling case that their notion of an OAM framework has
benefits that justify a change to the architecture and with it a
change in the reality that the two equipment suppliers with highest
market share both rely on PHP and so do many others.

I'm personally not all that convinced about P-MP but I'm also not
ready to say it should be eliminated based on it not fitting into a
particular OAM framework.

The architecture document is both a document that though maybe not
perfect has been a basis of the work of this group and is a good
reflection of reality.  The OAM framework attempts to align the work
of the MPLS WG with conflicting work of the ITU which has been
repeatedly rejected by the MPLS WG.

I entirely agree with you that we don't need to change the direction
of MPLS to make it a "newer better ATM" and therefore having Thomas
and David try to work together to produce an OAM framework that is
consistent with the MPLS architecture is a worthy goal.

If David does not want to compromise, then perhaps Thomas should serve
as editor of an OAM architecture document for advancement by the WG.
If so, perhaps David can advance his OAM architecture as an
informational document outside the WG.

Curtis



> Shahram Davari wrote:
> 
> >Loa,
> >
> >Could you please technically articulate were the disconnect is?
> >and why isn't it resolvable, so that it needs a new draft?
> >In other words please provide valid justification for your
> >request.
> >
> >Thanks,
> >-Shahram
> >
> >  
> >
> >>-----Original Message-----
> >>From: Loa Andersson [mailto:NtscpUsrLoa@netscape.net]
> >>Sent: Sunday, November 09, 2003 9:27 PM
> >>To: MPLS wg
> >>Cc: George Swallow; Alex Zinin
> >>Subject: on the mpls oam framework
> >>
> >>
> >>All,
> >>
> >>I read the mpls oam framework as it has been suggested in
> >>Dave Allans draft (draft-allan-mpls-oam-frmwrk) and also
> >>re-read the the mpls architecture document. I've the architecture
> >>authors to review the oam framework and received some feedback
> >>    
> >>
> >>from them.
> >  
> >
> >>It is my understanding that there is a serious disconnect
> >>between the architecture and oam framework, and I therefore
> >>want to restart the oam framework in a fresh document,
> >>with the undertanding that this document shall be aligned
> >>with the architecture.
> >>
> >>I asked David Allan and Tom Nadeau to take on the editorship
> >>for this new document, and hope to have positive answers from
> >>both of them before the mpls wg meeting in Minneapolis.
> >>
> >>/Loa



From owner-mpls@UU.NET  Tue Nov 11 07:04: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 HAA28474
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 07:04: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 QQpoiq05118
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 12:05: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 QQpoiq04878;
	Tue, 11 Nov 2003 12:05:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoio19508
	for mpls-outgoing; Tue, 11 Nov 2003 11:42: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 QQpoio19503
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 11:42:27 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 QQpoio01026
	for <mpls@UU.NET>; Tue, 11 Nov 2003 11:42: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 QQpoio06141
	for <mpls@UU.NET>; Tue, 11 Nov 2003 11:42:05 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 QQpoio06135
	for <mpls@UU.NET>; Tue, 11 Nov 2003 11:42:04 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hABBfpY26668;
	Tue, 11 Nov 2003 06:41:51 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <W3H86443>; Tue, 11 Nov 2003 06:41:51 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D02B9277B@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'loa@pi.se'" <loa@pi.se>, MPLS wg <mpls@UU.NET>
Subject: RE: on the mpls oam framework
Date: Tue, 11 Nov 2003 06:41:48 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-mpls@UU.NET
Precedence: bulk

Loa:

The thing that intrigues me with this discussion is that the framework
dicusses the limitations of what can be achieved with current practice.  Aka
when specific optional architectural components are used.
- folks choose to represent this as not aligned with the architecture. IMHO
these are different things. Certain implementation choices add complexity to
specific OAM functionality....no big surprise there. When I think the
document may be diminished, it is that the lack of honest acknowledgement of
the limitations of what can be achieved when certain architectural
components are used.

I am getting the impression that this is not about the MPLS architecture
itself per se, but about the specific instantiations that have been derived
from the MPLS architecture to date, which again is a subset of 3031. The
document does differ there in that it suggests if you want to instrument p2p
tunnels that extend e2e (which I would consider to be a perfectly legitimate
aspect of the MPLS arctecture), you can do so as an overlay or via not using
optional components of the architecture. Again this should fit under the
3031 umbrella. 

A document that outlined what was achievable and could be rounded out to say
what tools and practices today did achieve would be useful. That's where I'd
like to see the document go. I don't think we need to start over to do that.
Some sculpting and adding to the current framework should suffice. 

regards
Dave

> -----Original Message-----
> From: Loa Andersson [mailto:NtscpUsrLoa@netscape.net] 
> Sent: Monday, November 10, 2003 12:18 PM
> To: Allan, David [CAR:NS00:EXCH]; MPLS wg
> Subject: Re: on the mpls oam framework
> 
> 
> Dave,
> 
> I hope the "small problem" should not be taken in a 
> rethorical sense, and hope you are willing to work with Tom on this.
> 
> My interest in this is that we create a non-broken foundaiton 
> for mpls, rather than having work going of in different 
> incompatible directions. Hope you will see this a a chance to 
> contribute to this unified foundation.
> 
> I am a bit concerned with the view that alignmentti to the 
> mpls architecture  would diminish the value of the document.
> 
> /Loa
> 
> dallan@nortelnetworks.com wrote:
> 
> >Loa
> >
> >I have no small problem with the proposal to start over as I 
> feel like 
> >I'm being asked to set aside my and my colleagues convictions in the 
> >interest of producing what I would consider to be a document of 
> >diminshed significance.
> >
> >Given that the draft basically says you cannot do everything 
> with all 
> >connectivity structures as they stand and why (e.g. Mp2P and 
> PHP) and 
> >need to overlay P2P LSPs when certain functionality is required, I'm 
> >not too sure where the disconnect is. It discusses how you can use 
> >aspects of the architecture to create a framework whereby 
> any style of 
> >instrumentation and consequent measurability can be achieved.
> >
> >I'd prefer if those reviewing the document provided feedback as to 
> >where specific unresolvable disconnects existed. I'm not 
> sure they are 
> >unresolvable or innacurate.
> >
> >rgds
> >Dave
> >
> >  
> >
> >>-----Original Message-----
> >>From: Loa Andersson [mailto:NtscpUsrLoa@netscape.net]
> >>Sent: Sunday, November 09, 2003 9:27 PM
> >>To: MPLS wg
> >>Cc: George Swallow; Alex Zinin
> >>Subject: on the mpls oam framework
> >>
> >>
> >>All,
> >>
> >>I read the mpls oam framework as it has been suggested in 
> Dave Allans 
> >>draft (draft-allan-mpls-oam-frmwrk) and also re-read the the mpls 
> >>architecture document. I've the architecture authors to 
> review the oam 
> >>framework and received some feedback from them.
> >>
> >>It is my understanding that there is a serious disconnect
> >>between the architecture and oam framework, and I therefore 
> >>want to restart the oam framework in a fresh document, with 
> >>the undertanding that this document shall be aligned with the 
> >>architecture.
> >>
> >>I asked David Allan and Tom Nadeau to take on the editorship
> >>for this new document, and hope to have positive answers from 
> >>both of them before the mpls wg meeting in Minneapolis.
> >>
> >>/Loa
> >>
> >>
> >>    
> >>
> 
> 


From owner-mpls@UU.NET  Tue Nov 11 08:17: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 IAA00099
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 08:17: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 QQpoiv16227
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 13:17: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 QQpoiv15995;
	Tue, 11 Nov 2003 13:17:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoit14675
	for mpls-outgoing; Tue, 11 Nov 2003 12:54: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 QQpoit14668
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 12:54: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 QQpoit00520
	for <mpls@UU.NET>; Tue, 11 Nov 2003 12:54: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 QQpoit19393
	for <mpls@UU.NET>; Tue, 11 Nov 2003 12:54:10 GMT
Received: from cbibipnt08.hc.bt.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: saturn.bt.com [193.113.57.20])
	id QQpoit19382
	for <mpls@UU.NET>; Tue, 11 Nov 2003 12:54:09 GMT
Received: from cbibipnt08.hc.bt.com ([147.149.100.81]) by cbibipnt08.hc.bt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id W3FNLM1F; Tue, 11 Nov 2003 12:54:10 -0000
Received: From celiborn.ip-engineering.bt.com ([132.146.100.200]) by cbibipnt08.hc.bt.com (WebShield SMTP v4.5 MR1a);
	id 1068555249904; Tue, 11 Nov 2003 12:54:09 +0000
Received: from celiborn.galadriel.bt.co.uk ([132.146.100.200] helo=ip-engineering.bt.com)
	by celiborn.ip-engineering.bt.com with esmtp (Exim 4.04)
	id 1AJY22-0002DI-00; Tue, 11 Nov 2003 12:54:06 +0000
X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #11[UCI]
To: loa@pi.se
cc: Shahram Davari <Shahram_Davari@pmc-sierra.com>, MPLS wg <mpls@UU.NET>,
        George Swallow <swallow@cisco.com>, Alex Zinin <zinin@psg.com>
Subject: Re: on the mpls oam framework 
In-reply-to: Your message of "Tue, 11 Nov 2003 00:20:13 +0100."
             <3FB01D2D.9080107@netscape.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 11 Nov 2003 12:54:06 +0000
From: Peter Willis <pjw@ip-engineering.bt.com>
Message-Id: <E1AJY22-0002DI-00@celiborn.ip-engineering.bt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Loa,

I think you have to be careful to NOT give the message "MPLS will NEVER evolve 
to address your new requirements" to network operators. Because if that is the 
message you are giving you are condeming a lot of vendors who are hoping to 
sell MPLS based solutions into the network operators/carrier space.

-------------------------------------------------------------------------------
Peter Willis		            | E-mail: peter.j.willis@bt.com
Chief Data Networks Architect	    | 
BT Group CTO                        |
-------------------------------------------------------------------------------




From owner-mpls@UU.NET  Tue Nov 11 08:42: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 IAA01126
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 08:42: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 QQpoiw18475
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 13:42: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 QQpoiw17973;
	Tue, 11 Nov 2003 13:42:03 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoiv06085
	for mpls-outgoing; Tue, 11 Nov 2003 13:20:15 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 QQpoiv06074
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 13:20: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 QQpoiv09682
	for <mpls@uu.net>; Tue, 11 Nov 2003 13:19: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 QQpoiv29455
	for <mpls@uu.net>; Tue, 11 Nov 2003 13:19:32 GMT
Received: from sj-iport-5.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-5.cisco.com [171.68.10.87])
	id QQpoiv29444
	for <mpls@uu.net>; Tue, 11 Nov 2003 13:19:32 GMT
Received: from cisco.com (64.102.124.13)
  by sj-iport-5.cisco.com with ESMTP; 11 Nov 2003 05:23:02 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hABDJSDM019526
	for <mpls@uu.net>; Tue, 11 Nov 2003 08:19:29 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADW80948;
	Tue, 11 Nov 2003 08:19:28 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hABDJSX18212 for mpls@uu.net; Tue, 11 Nov 2003 08:19:28 -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 QQpoiv05981
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 13:18:23 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 QQpoiv04430
	for <mpls@uu.net>; Tue, 11 Nov 2003 13:17: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 QQpoiv26507
	for <mpls@uu.net>; Tue, 11 Nov 2003 13:17:09 GMT
Received: from ganesh.ctd.hcltech.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: Ganesh.hcltech.com [202.54.64.2])
	id QQpoiv26488
	for <mpls@uu.net>; Tue, 11 Nov 2003 13:17:08 GMT
Received: by GANESH with Internet Mail Service (5.5.2657.72)
	id <WVJH63MF>; Tue, 11 Nov 2003 18:47:07 +0530
Message-ID: <9F54AA5915501745A385AF7CBDC7E871653084@HARITHA.ctd.hcltech.com>
From: "Jeyanath Minto J - CTD, Chennai." <jeyananthj@ctd.hcltech.com>
To: mpls@UU.NET
Date: Tue, 11 Nov 2003 18:46:54 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

subscribe



From owner-mpls@UU.NET  Tue Nov 11 09:24:02 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 JAA02011
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 09:24:01 -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 QQpoiz25194
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 14:24: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 QQpoiz24782;
	Tue, 11 Nov 2003 14:23:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoiy24885
	for mpls-outgoing; Tue, 11 Nov 2003 14:03:26 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 QQpoiy24749
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 14:03:24 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 QQpoiy17221
	for <mpls@UU.NET>; Tue, 11 Nov 2003 14:02: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 QQpoiy10674
	for <mpls@UU.NET>; Tue, 11 Nov 2003 14:02:06 GMT
Received: from kcmso2.proxy.att.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: kcmso2.att.com [192.128.134.71])
	id QQpoiy10663
	for <mpls@UU.NET>; Tue, 11 Nov 2003 14:02:06 GMT
Received: from attrh5i.attrh.att.com ([135.38.62.12])
	by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id hABDo1mS004529
	for <mpls@UU.NET>; Tue, 11 Nov 2003 08:02:05 -0600
Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (6.5.032)
        id 3F307C6C01C66C26; Tue, 11 Nov 2003 09:01:45 -0500
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="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D ACTION:draft-lai-mpls-ldp-hist-mib-00.txt
Date: Tue, 11 Nov 2003 08:02:04 -0600
Message-ID: <7AFE40EF30EE754DA967D1B5968457CA1578D0@KCCLUST06EVS1.ugd.att.com>
Thread-Topic: I-D ACTION:draft-lai-mpls-ldp-hist-mib-00.txt
Thread-Index: AcOn+r211eIyt/FxSb+8YiXlWNzsJwAYLMEg
From: "Lai, Wai S (Waisum), ALABS" <wlai@att.com>
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, <jcucchiara@mindspring.com>
Cc: <mpls@UU.NET>, "Ash, Gerald R (Jerry), ALABS" <gash@att.com>,
        "Chung, Li-Jin W, ALABS" <lic@att.com>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Bert,
   Thanks for the pointer.  It looks like something relevant for our
use.
Would there be any problems to extend it for 5 minute intervals?
Thanks, Wai Sum

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Monday, November 10, 2003 9:23 PM
To: Lai, Wai S (Waisum), ALABS; jcucchiara@mindspring.com
Cc: mpls@UU.NET; Ash, Gerald R (Jerry), ALABS; Chung, Li-Jin W, ALABS
Subject: RE: I-D ACTION:draft-lai-mpls-ldp-hist-mib-00.txt


> ....  The draft currently proposes five additional
> objects, while the issue of measurement interval and=20
> recording counters to maintain persistent history has
> been left open for further discussion.

Are you aware of RFC3593 ??
Is that something that might be usable here?

Bert


From owner-mpls@UU.NET  Tue Nov 11 09:28: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 JAA02112
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 09:28: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 QQpoiz02041
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 14:28:27 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 QQpoiz01841;
	Tue, 11 Nov 2003 14:28:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoiy29439
	for mpls-outgoing; Tue, 11 Nov 2003 14:11: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 QQpoiy29345
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 14:10:58 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 QQpoiy02793
	for <mpls@UU.NET>; Tue, 11 Nov 2003 14:09:52 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 QQpoiy27049
	for <mpls@UU.NET>; Tue, 11 Nov 2003 14:09:51 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 QQpoiy27043
	for <mpls@UU.NET>; Tue, 11 Nov 2003 14:09:51 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hABE9ZY18209;
	Tue, 11 Nov 2003 09:09:36 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <W3H86W4X>; Tue, 11 Nov 2003 09:09:36 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D02B9277E@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'loa@pi.se'" <loa@pi.se>,
        Shahram Davari
	 <Shahram_Davari@pmc-sierra.com>
Cc: MPLS wg <mpls@UU.NET>, George Swallow <swallow@cisco.com>,
        Alex Zinin
	 <zinin@psg.com>
Subject: RE: on the mpls oam framework
Date: Tue, 11 Nov 2003 09:09:35 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-mpls@UU.NET
Precedence: bulk

Loa:

> note that Neil, Dave and I agree on that the disconnect is
> there, I'm not certain that they agree with how I described 
> (but that is also part of the disconnect :) ).

Again IMHO if there is a disconnect, it is what MPLS has become vs. its
origins as exclusively an IP helper. There is already a reasonable body of
evoluiton that is not covered in 3031. FOr example 3270 cast diffserv as
somthing entirely different from the concept of FEC, yet when reading 3031
you would expect diffserv to come under the umbrella of FEC. Further TTL
handling (pipe and uniform models) is not addressed either. Perhaps it is
time to respin 3031. Especially if folks want to exclusively clamp it down
to IP, 2547 and PWs.  
 
> Anyway - I guess that the core of the matter is that the
> architecture is written positioning mpls as a part of the ip 
> protocol suite, while the oam framework rather position it as 
> a "newer and better ATM" that necessarily needs to have all 
> the features of ATM.

I thought it was supposed to be an IP helper. If it is rigorously
constrained to being no more than IP, it adds no value, IP is sufficient and
complete. However MPLS does introduce new modes of failure into IP networks,
and does have this label swapping dataplane for which the black box behavior
of the network is a function of the control plane used. We are now carrying
other than IP, and the label stack depth (depending on the proposals you
see) can have several control planes both stacked and/or side by side, the
overall implications being rather subtle. That some OAM standards are
focused on p2p CO behavior (such as Y.1711) I would think is still
consistent with the data plane specified in 3031. That others (Y.17fec-cv,
LSP-PING) focus on broader behaviors when other control planes are used (LDP
etc.) is also consistent. 

> 
> This shows up in a numbe of places, the concept of layers and
> levels is, not what I see as useful in the type of IP network 
> I've been involved in.

That there are VPN layers, PW layers, transport layers, inter area solutions
that all have potentially unique control planes, and relationships between
the layers. The absence of a UNI means that network elements participate in
multiple control planes, and potentially multiple networks.
 
> The definition of "LSP" is not what is in the architecture document.
> 
> PHP is designed out by the oam framework, but an in by the
> mpls architecture.

Not designed out, but needs to be worked around for some styles of
measurement. It is a MAY in 3031 which suggests that the original authors
didn't think it universally suitable. I can also "mine" the list for lots of
"that was a mistake" testimonials....

> 
> But you are misrepresenting me when you say that the
> differences is not resolvable. In fact the proposal to start 
> on a fresh document is intended jsut to achieve that. I guess 
> that if there are two people representing two different ideas 
> on a subject, the requirement that one of the has to accept 
> the ideas of the other to be part work seems to be counter-productive.

I think that cuts both ways. I'm certainly willing to enlarge the document
to include both points of view. It is a framework document after all.....
;-)

cheers
Dave


From owner-mpls@UU.NET  Tue Nov 11 09:43: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 JAA02541
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 09:43: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 QQpoja14344
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 14:43: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 QQpoja14176;
	Tue, 11 Nov 2003 14:43:18 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoiz00890
	for mpls-outgoing; Tue, 11 Nov 2003 14:22: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 QQpoiz00819
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 14:21: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 QQpoiz24261
	for <mpls@uu.net>; Tue, 11 Nov 2003 14:21:15 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 QQpoiz05831
	for <mpls@uu.net>; Tue, 11 Nov 2003 14:21:15 GMT
Received: from imo-d02.mx.aol.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imo-d02.mx.aol.com [205.188.157.34])
	id QQpoiz05817
	for <mpls@uu.net>; Tue, 11 Nov 2003 14:21:14 GMT
Received: from NtscpUsrLoa@netscape.net
	by imo-d02.mx.aol.com (mail_out_v36_r1.1.) id z.e7.b0736d1 (16240);
	Tue, 11 Nov 2003 09:21:09 -0500 (EST)
Received: from  netscape.net (dyn132-165.ietf58.ietf.org [130.129.132.165]) by air-in03.mx.aol.com (v97.8) with ESMTP id MAILININ34-3f703fb0f04fc2; Tue, 11 Nov 2003 09:21:08 -0500
Message-ID: <3FB0F037.4030906@netscape.net>
Date: Tue, 11 Nov 2003 15:20:39 +0100
From: Loa Andersson <NtscpUsrLoa@netscape.net>
Reply-To: loa@pi.se
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Willis <pjw@ip-engineering.bt.com>
CC: Shahram Davari <Shahram_Davari@pmc-sierra.com>, MPLS wg <mpls@UU.NET>,
        George Swallow <swallow@cisco.com>, Alex Zinin <zinin@psg.com>
Subject: Re: on the mpls oam framework
References: <E1AJY22-0002DI-00@celiborn.ip-engineering.bt.com>
In-Reply-To: <E1AJY22-0002DI-00@celiborn.ip-engineering.bt.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-AOL-IP: 130.129.132.165
X-Mailer: Unknown (No Version)
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Peter,

of that is the impression you get I'm communicating badly,
"the message" I try to give is that we will evolve based on
known and agreed requirements.

/Loa

Peter Willis wrote:

>Loa,
>
>I think you have to be careful to NOT give the message "MPLS will NEVER evolve 
>to address your new requirements" to network operators. Because if that is the 
>message you are giving you are condeming a lot of vendors who are hoping to 
>sell MPLS based solutions into the network operators/carrier space.
>
>-------------------------------------------------------------------------------
>Peter Willis                   | E-mail: peter.j.willis@bt.com
>Chief Data Networks Architect      | 
>BT Group CTO                        |
>-------------------------------------------------------------------------------
>
>
>
>
>  
>



From owner-mpls@UU.NET  Tue Nov 11 09:43: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 JAA02557
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 09:43:15 -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 QQpoja05508
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 14:43: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 QQpoja05083;
	Tue, 11 Nov 2003 14:43:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoiz00897
	for mpls-outgoing; Tue, 11 Nov 2003 14:22: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 QQpoiz00824
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 14:21:56 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 QQpoiz23516
	for <mpls@UU.NET>; Tue, 11 Nov 2003 14:20: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 QQpoiz20676
	for <mpls@UU.NET>; Tue, 11 Nov 2003 14:20:48 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 QQpoiz20662
	for <mpls@UU.NET>; Tue, 11 Nov 2003 14:20: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 JAA18151;
	Tue, 11 Nov 2003 09:20:45 -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 JAA09515;
	Tue, 11 Nov 2003 09:20:45 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <WRC6J3LJ>; Tue, 11 Nov 2003 09:20:45 -0500
Message-ID: <313680C9A886D511A06000204840E1CF40BA8D@whq-msgusr-02.pit.comms.marconi.com>
From: "Punj, Arun" <Arun.Punj@marconi.com>
To: "'David Allan'" <dallan@nortelnetworks.com>, "'loa@pi.se'" <loa@pi.se>,
        MPLS wg <mpls@UU.NET>
Subject: RE: on the mpls oam framework
Date: Tue, 11 Nov 2003 09:20: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


Loa/Allan/Folks,

I think it is important to accomodate people with opposing points of
view. But that, IMHO, does not require writing a new document. Specially 
when the opposing point of view has not articulated any point which would 
invalidate a substantial portion [or even a portion] of allan-mpls-oam 
draft. 

It would be a pity if a document which nicely captures all the issues
was relegated to backburner for reasons - which are not even remotely
technical. However, I am sure if you want Thomas Nadeau to work as 
a co-author to evolve this document further in the right direction it
would be welcome. Thomas is a highly respected engineer and we welcome
his feedbacks and guidance - and a chance to discuss his point of view.

Further comments inline.

> -----Original Message-----
> From: Loa Andersson [mailto:NtscpUsrLoa@netscape.net]
> Sent: Monday, November 10, 2003 6:20 PM
> To: Shahram Davari
> Cc: MPLS wg; George Swallow; Alex Zinin
> Subject: Re: on the mpls oam framework
> 
> 
> Sharam,
> 
> note that Neil, Dave and I agree on that the disconnect is there,
> I'm not certain that they agree with how I described (but that
> is also part of the disconnect :) ).
> 
> Anyway - I guess that the core of the matter is that the architecture
> is written positioning mpls as a part of the ip protocol suite, while
> the oam framework rather position it as a "newer and better ATM" that
> necessarily needs to have all the features of ATM.
> 
> This shows up in a numbe of places, the concept of layers and levels
> is, not what I see as useful in the type of IP network I've been
> involved in.

Concept of layers and levels does show up in architecture document and
as the architecture document acknowledged MPLS is not IPLS. 

RFC 3031
   "label switched path       The path through one or more LSRs at one
                              level of the hierarchy followed by a
                              packets in a particular FEC."

   " MPLS stands for "Multiprotocol" Label Switching, multiprotocol
   because its techniques are applicable to ANY network layer protocol.
   In this document, however, we focus on the use of IP as the network
   layer protocol. "
> 
> The definition of "LSP" is not what is in the architecture document.
  
  Can you point out the difference ?

> 
> PHP is designed out by the oam framework, but an in by the mpls
> architecture.

  Thats incorrect. The allan-mpls-oam clearly identifies that pros
  and cons of PHP. And it identifes rightly, that PHP would 
  incur some implementation costs in so far as the OAM functionality
  is desired. And if you do not agree, look at the implementations
  for OAM out there.

  Further please look at following texts from RFC3031:
  
   "There is also a practical advantage to doing penultimate hop popping.
   If one does not do this, then when the LSP egress receives a packet,
   it first looks up the top label, and determines as a result of that
   lookup that it is indeed the LSP egress."
                    ^^^^^^^^^^^^^^^^^^^^^^^
   This "it is indeed the LSP egress" functionality loss with PHP is
   what causes many of the problems to appear, as identified clearly
   in allan-mpls-oam draft.

   Also from RFC 3031 [3.27.3. LSP Tunnels]:

   "If it is not necessary for the tunnel's receive endpoint to be able
   to determine which packets it receives through the tunnel, as
   discussed earlier, the label stack may be popped at the penultimate
   LSR in the tunnel."
  
   This section clearly identifies when PHP should and should not be
   used. Thus for desirable OAM features PHP should not be used. 
   Again, before any one starts distorting the words please refer 
   to allan-mpls-oam draft - it DOES include OAM for PHP implementations.

> 
> But you are misrepresenting me when you say that the differences is
> not resolvable. In fact the proposal to start on a fresh document
> is intended jsut to achieve that. I guess that if there are two people
> representing two different ideas on a subject, the 
> requirement that one
> of the has to accept the ideas of the other to be part work seems to
> be counter-productive.

Once we can clearly identify the differences - I am sure they can 
be resolved. Infact, mostly the differences seem to stem from the love
of what is out there - rather than what is correct. But even in that they
are unnecassary since allan-mpls-oam does not specifically rule out
any solution out there - regardless of its merits or rather lack of.

> 
> Further if we have a "default" document in this case it should be the
> architecture.

I think RFC3031 should be a guiding document and not starting point for
any new work done in MPLS.

Thanks
Arun



> 
> /Loa
> 
> Shahram Davari wrote:
> 
> >Loa,
> >
> >Could you please technically articulate were the disconnect is?
> >and why isn't it resolvable, so that it needs a new draft?
> >In other words please provide valid justification for your
> >request.
> >
> >Thanks,
> >-Shahram
> >
> >  
> >
> >>-----Original Message-----
> >>From: Loa Andersson [mailto:NtscpUsrLoa@netscape.net]
> >>Sent: Sunday, November 09, 2003 9:27 PM
> >>To: MPLS wg
> >>Cc: George Swallow; Alex Zinin
> >>Subject: on the mpls oam framework
> >>
> >>
> >>All,
> >>
> >>I read the mpls oam framework as it has been suggested in
> >>Dave Allans draft (draft-allan-mpls-oam-frmwrk) and also
> >>re-read the the mpls architecture document. I've the architecture
> >>authors to review the oam framework and received some feedback
> >>    
> >>
> >>from them.
> >  
> >
> >>It is my understanding that there is a serious disconnect
> >>between the architecture and oam framework, and I therefore
> >>want to restart the oam framework in a fresh document,
> >>with the undertanding that this document shall be aligned
> >>with the architecture.
> >>
> >>I asked David Allan and Tom Nadeau to take on the editorship
> >>for this new document, and hope to have positive answers from
> >>both of them before the mpls wg meeting in Minneapolis.
> >>
> >>/Loa
> >>
> >>    
> >>
> >
> >
> >  
> >
> 


From owner-mpls@UU.NET  Tue Nov 11 09:56: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 JAA03093
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 09:56: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 QQpojb21259
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 14:56: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 QQpojb21112;
	Tue, 11 Nov 2003 14:56:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoja02690
	for mpls-outgoing; Tue, 11 Nov 2003 14:41: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 QQpoja02617
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 14:41:01 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 QQpoja14172
	for <mpls@UU.NET>; Tue, 11 Nov 2003 14:38: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 QQpoja07540
	for <mpls@UU.NET>; Tue, 11 Nov 2003 14:38:26 GMT
Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint2.juniper.net [207.17.136.150])
	id QQpoja07527
	for <mpls@UU.NET>; Tue, 11 Nov 2003 14:38:25 GMT
Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id hABEcBi27983;
	Tue, 11 Nov 2003 06:38:11 -0800 (PST)
	(envelope-from ina@juniper.net)
Date: Tue, 11 Nov 2003 06:38:11 -0800 (PST)
From: Ina Minei <ina@juniper.net>
To: Luca Martini <lmartini@cisco.com>
cc: jason rusmisel <jason.rusmisel@alcatel.com>, "" <mpls@UU.NET>
Subject: Re: I-D ACTION:draft-minei-mpls-ldp-external-00.txt (fwd)
In-Reply-To: <3FB04FF9.6000107@cisco.com>
Message-ID: <20031111063341.T16133@garnet.juniper.net>
References: <20031013100945.T88214@garnet.juniper.net> <3FAFC7E9.3010103@alcatel.com>
 <20031110114254.W8920@garnet.juniper.net> <3FB04FF9.6000107@cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


	There is nothing wrong in that. The mechanism described in the
draft is a general mechnism, the vpn scenario is a usage example.

				Thank you,

					Ina

On Mon, 10 Nov 2003, Luca Martini wrote:

> so what is wrong with using the IBGP, and 3 label MPLS stack , while
> leaving LDP out of the routing business ?
>
> Luca
>
> Ina Minei wrote:
>
> >      Please see answers innline, marked ###.
> >
> >                          Thank you,
> >
> >                                  Ina
> >
> >On Mon, 10 Nov 2003, jason rusmisel wrote:
> >
> >
> >
> >>A question for you:
> >>
> >>If I understand correctly, the motivation for this draft is to allow LDP
> >>to be the single mechanism to distribute reachability rather than
> >>counting on a 2547bis-like mechanism.
> >>
> >>
> >
> >### The motivation for this draft is to allow establishment of LDP
> >signaled LSPs without having to inject routes for them in the IGP.
> >The 2547bit scenario is an example of using the proposed extension.
> >
> >
> >
> >>The overall approach of carrying the External FEC in the FEC TLV
> >>guarantees that these label mappings will not be propagated in a network
> >>of mixed LDP implementations.  Have you considered this situation?
> >>
> >>
> >>
> >
> >### In a mixed network, LSPs for external FECs will be established only
> >through nodes that support this functionality, thus ensuring consistent
> >establishment of the LSPs. Note that since we don't have routing table
> >entries for these FECs, nodes not supporting the extension would not
> >propagate mappings for them anyway.
> >
> > > Jason Rusmisel.
> >
> >
> >>Ina Minei wrote:
> >>
> >>
> >>
> >>>  This document describes a mechanism that allows the creation of LDP
> >>>signaled LSPs for prefixes which are not present in the routing table.
> >>>
> >>>  Comments welcome,
> >>>
> >>>		Thank you,
> >>>
> >>>			Ina Minei
> >>>
> >>>---------- Forwarded message ----------
> >>>Date: 7 Oct 03 15:00:15 GMT
> >>>From: Internet-Drafts@ietf.org
> >>>To: IETF-Announce:  ;
> >>>Newsgroups: jnx.ext.ietf.announce
> >>>Subject: I-D ACTION:draft-minei-mpls-ldp-external-00.txt
> >>>
> >>>A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >>>
> >>>
> >>>	Title		: LDP signaled LSPs for external prefixes
> >>>	Author(s)	: L. Fang, et. al.
> >>>	Filename	: draft-minei-mpls-ldp-external-00.txt
> >>>	Pages		: 6
> >>>	Date		: 2003-10-7
> >>>
> >>>In order to create forwarding state for a FEC received from a downstream
> >>>LSR, LDP requires the presence of a matching entry in the routing table.
> >>>This document describes a mechanism that allows the creation of LDP
> >>>signaled LSPs for prefixes which are not present in the routing table.
> >>>This draft is applicable to address prefix FECs and host FECs associated
> >>>with either IPv4 or IPv6 prefixes.
> >>>
> >>>A URL for this Internet-Draft is:
> >>>http://www.ietf.org/internet-drafts/draft-minei-mpls-ldp-external-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-minei-mpls-ldp-external-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-minei-mpls-ldp-external-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.
> >>>
> >>>
> >>>
> >
> >
> >
>
>


From owner-mpls@UU.NET  Tue Nov 11 10:11: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 KAA04354
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 10:11: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 QQpojc24489
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 15:11: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 QQpojc24266;
	Tue, 11 Nov 2003 15:11:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpojb03979
	for mpls-outgoing; Tue, 11 Nov 2003 14:49: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 QQpojb03974
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 14:49:27 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 QQpojb28739
	for <mpls@UU.NET>; Tue, 11 Nov 2003 14:47: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 QQpojb19470
	for <mpls@UU.NET>; Tue, 11 Nov 2003 14:47:04 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 QQpojb19460
	for <mpls@UU.NET>; Tue, 11 Nov 2003 14:47:04 GMT
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hABEl0w23402
	for <mpls@UU.NET>; Tue, 11 Nov 2003 08:47:01 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59)
	id <WMXRXKJF>; Tue, 11 Nov 2003 15:46:00 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502EAF74C@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "Lai, Wai S (Waisum), ALABS" <wlai@att.com>, jcucchiara@mindspring.com
Cc: mpls@UU.NET, "Ash, Gerald R (Jerry), ALABS" <gash@att.com>,
        "Chung, Li-Jin W, ALABS" <lic@att.com>
Subject: RE: I-D ACTION:draft-lai-mpls-ldp-hist-mib-00.txt
Date: Tue, 11 Nov 2003 15:45:59 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

> 
> Bert,
>    Thanks for the pointer.  It looks like something relevant for our
> use.
> Would there be any problems to extend it for 5 minute intervals?

I think it would not be good to add to that existing doc, cause it
is already at DS and so it would have to recycle at PS.

But..

You/one/we could do a separate set of TCs for 5 minute intervals
Or we could generalize it so that intervals are variable (e.g.
need to be configured)... or ...

Is it something that is needed in many places?
Maybe something to discuss on mibs mailing list.

Bert

> Thanks, Wai Sum
> 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Monday, November 10, 2003 9:23 PM
> To: Lai, Wai S (Waisum), ALABS; jcucchiara@mindspring.com
> Cc: mpls@UU.NET; Ash, Gerald R (Jerry), ALABS; Chung, Li-Jin W, ALABS
> Subject: RE: I-D ACTION:draft-lai-mpls-ldp-hist-mib-00.txt
> 
> 
> > ....  The draft currently proposes five additional
> > objects, while the issue of measurement interval and 
> > recording counters to maintain persistent history has
> > been left open for further discussion.
> 
> Are you aware of RFC3593 ??
> Is that something that might be usable here?
> 
> Bert
> 


From owner-mpls@UU.NET  Tue Nov 11 10:22: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 KAA05391
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 10:22: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 QQpojd09774
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 15:23: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 QQpojd09399;
	Tue, 11 Nov 2003 15:22:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpojc15857
	for mpls-outgoing; Tue, 11 Nov 2003 15:03: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 QQpojc15846
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 15:03: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 QQpojc08198
	for <mpls@uu.net>; Tue, 11 Nov 2003 15:00: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 QQpojc07260
	for <mpls@uu.net>; Tue, 11 Nov 2003 15:00:56 GMT
Received: from sj-iport-4.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-4.cisco.com [171.68.10.86])
	id QQpojc07230
	for <mpls@uu.net>; Tue, 11 Nov 2003 15:00:55 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hABF0pDM011707
	for <mpls@uu.net>; Tue, 11 Nov 2003 10:00:52 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADW88850;
	Tue, 11 Nov 2003 10:00:51 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hABF0pc24667 for mpls@uu.net; Tue, 11 Nov 2003 10:00:51 -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 QQpojb04826
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 14:59: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 QQpojb11888
	for <mpls@uu.net>; Tue, 11 Nov 2003 14:59: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 QQpojb23670
	for <mpls@uu.net>; Tue, 11 Nov 2003 14:59:06 GMT
Received: from sj-iport-4.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-4.cisco.com [171.68.10.86])
	id QQpojb23656
	for <mpls@uu.net>; Tue, 11 Nov 2003 14:59:05 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hABEx1DM011113;
	Tue, 11 Nov 2003 09:59:02 -0500 (EST)
Received: from tnadeauw2k02 (che-vpn-cluster-1-105.cisco.com [10.86.240.105])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADW88615;
	Tue, 11 Nov 2003 09:59:00 -0500 (EST)
Reply-To: <tnadeau@cisco.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
To: "'David Allan'" <dallan@nortelnetworks.com>, <loa@pi.se>,
        "'MPLS wg'" <mpls@UU.NET>
Subject: RE: on the mpls oam framework
Date: Tue, 11 Nov 2003 08:58:47 -0600
Organization: Cisco Systems, inc.
Message-ID: <019001c3a864$54c49070$63808182@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
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <FFFC48AEAA5F7447929F4F0D93FCC12D02B9277B@zcard031.ca.nortel.com>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


>Loa:
>
>The thing that intrigues me with this discussion is that the framework
>dicusses the limitations of what can be achieved with current 
>practice.  Aka
>when specific optional architectural components are used.
>- folks choose to represent this as not aligned with the 
>architecture. IMHO
>these are different things. Certain implementation choices add 
>complexity to
>specific OAM functionality....no big surprise there. When I think the
>document may be diminished, it is that the lack of honest 
>acknowledgement of
>the limitations of what can be achieved when certain architectural
>components are used.

	If what you are describing is true, then it seems 
appropriate that your document be published as an informational
ID that captures these points. To me this doesn't seem
appropriate for a framework that is used to drive existing
OAM work based on the current framework.

	--Tom



>I am getting the impression that this is not about the MPLS 
>architecture
>itself per se, but about the specific instantiations that have 
>been derived
>from the MPLS architecture to date, which again is a subset of 
>3031. The
>document does differ there in that it suggests if you want to 
>instrument p2p
>tunnels that extend e2e (which I would consider to be a 
>perfectly legitimate
>aspect of the MPLS arctecture), you can do so as an overlay or 
>via not using
>optional components of the architecture. Again this should fit 
>under the
>3031 umbrella. 
>
>A document that outlined what was achievable and could be 
>rounded out to say
>what tools and practices today did achieve would be useful. 
>That's where I'd
>like to see the document go. I don't think we need to start 
>over to do that.
>Some sculpting and adding to the current framework should suffice. 
>
>regards
>Dave
>
>> -----Original Message-----
>> From: Loa Andersson [mailto:NtscpUsrLoa@netscape.net] 
>> Sent: Monday, November 10, 2003 12:18 PM
>> To: Allan, David [CAR:NS00:EXCH]; MPLS wg
>> Subject: Re: on the mpls oam framework
>> 
>> 
>> Dave,
>> 
>> I hope the "small problem" should not be taken in a 
>> rethorical sense, and hope you are willing to work with Tom on this.
>> 
>> My interest in this is that we create a non-broken foundaiton 
>> for mpls, rather than having work going of in different 
>> incompatible directions. Hope you will see this a a chance to 
>> contribute to this unified foundation.
>> 
>> I am a bit concerned with the view that alignmentti to the 
>> mpls architecture  would diminish the value of the document.
>> 
>> /Loa
>> 
>> dallan@nortelnetworks.com wrote:
>> 
>> >Loa
>> >
>> >I have no small problem with the proposal to start over as I 
>> feel like 
>> >I'm being asked to set aside my and my colleagues 
>convictions in the 
>> >interest of producing what I would consider to be a document of 
>> >diminshed significance.
>> >
>> >Given that the draft basically says you cannot do everything 
>> with all 
>> >connectivity structures as they stand and why (e.g. Mp2P and 
>> PHP) and 
>> >need to overlay P2P LSPs when certain functionality is 
>required, I'm 
>> >not too sure where the disconnect is. It discusses how you can use 
>> >aspects of the architecture to create a framework whereby 
>> any style of 
>> >instrumentation and consequent measurability can be achieved.
>> >
>> >I'd prefer if those reviewing the document provided feedback as to 
>> >where specific unresolvable disconnects existed. I'm not 
>> sure they are 
>> >unresolvable or innacurate.
>> >
>> >rgds
>> >Dave
>> >
>> >  
>> >
>> >>-----Original Message-----
>> >>From: Loa Andersson [mailto:NtscpUsrLoa@netscape.net]
>> >>Sent: Sunday, November 09, 2003 9:27 PM
>> >>To: MPLS wg
>> >>Cc: George Swallow; Alex Zinin
>> >>Subject: on the mpls oam framework
>> >>
>> >>
>> >>All,
>> >>
>> >>I read the mpls oam framework as it has been suggested in 
>> Dave Allans 
>> >>draft (draft-allan-mpls-oam-frmwrk) and also re-read the the mpls 
>> >>architecture document. I've the architecture authors to 
>> review the oam 
>> >>framework and received some feedback from them.
>> >>
>> >>It is my understanding that there is a serious disconnect
>> >>between the architecture and oam framework, and I therefore 
>> >>want to restart the oam framework in a fresh document, with 
>> >>the undertanding that this document shall be aligned with the 
>> >>architecture.
>> >>
>> >>I asked David Allan and Tom Nadeau to take on the editorship
>> >>for this new document, and hope to have positive answers from 
>> >>both of them before the mpls wg meeting in Minneapolis.
>> >>
>> >>/Loa
>> >>
>> >>
>> >>    
>> >>
>> 
>> 
>




From owner-mpls@UU.NET  Tue Nov 11 10:38: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 KAA06237
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 10:37: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 QQpoje00402
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 15:38:09 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 QQpoje00228;
	Tue, 11 Nov 2003 15:38:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpojd26222
	for mpls-outgoing; Tue, 11 Nov 2003 15:19:24 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 QQpojd26189
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 15:19:16 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 QQpojc10130
	for <mpls@uu.net>; Tue, 11 Nov 2003 15: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 QQpojc11174
	for <mpls@uu.net>; Tue, 11 Nov 2003 15:12:24 GMT
Received: from sj-iport-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70])
	id QQpojc11155
	for <mpls@uu.net>; Tue, 11 Nov 2003 15:12:24 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hABFCDmU005710
	for <mpls@uu.net>; Tue, 11 Nov 2003 07:12:13 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADW90118;
	Tue, 11 Nov 2003 10:12:12 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hABFCCV25747 for mpls@uu.net; Tue, 11 Nov 2003 10:12: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 QQpojc24748
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 15:11: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 QQpojc02494
	for <mpls@uu.net>; Tue, 11 Nov 2003 15:10: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 QQpojc23035
	for <mpls@uu.net>; Tue, 11 Nov 2003 15:10:40 GMT
Received: from sj-iport-4.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-4.cisco.com [171.68.10.86])
	id QQpojc23023
	for <mpls@uu.net>; Tue, 11 Nov 2003 15:10:39 GMT
Received: from cisco.com (frondo.cisco.com [161.44.172.154])
	by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hABFAaxg011064;
	Tue, 11 Nov 2003 10:10:36 -0500 (EST)
Message-Id: <200311111510.hABFAaxg011064@rtp-core-1.cisco.com>
To: curtis@fictitious.org
cc: loa@pi.se, Shahram Davari <Shahram_Davari@pmc-sierra.com>,
        MPLS wg <mpls@UU.NET>, George Swallow <swallow@cisco.com>,
        Alex Zinin <zinin@psg.com>, swallow@cisco.com
Subject: Re: on the mpls oam framework 
In-reply-to: Your message of "Tue, 11 Nov 2003 00:01:42 EST."
             <200311110501.hAB51ghO029795@workhorse.fictitious.org> 
Date: Tue, 11 Nov 2003 10:10:36 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Curtis -

> I'm personally not all that convinced about P-MP but I'm also not
> ready to say it should be eliminated based on it not fitting into a
> particular OAM framework.

You need to re-read what Neil wrote.  

> Loa....you are misrepresenting my 'agreement on the situation'.   I =
> agree there is a problem.....but has it ever occurred to you that the =
> starting point may be wrong?  The problem is not that Dave's paper fails =
> to line-up with the MPLS arch papers, the problem is that the MPLS arch =
> (sic) stuff is itself architecturally broken......the mere act of =
> 'doing' mp2p and PHP does not bless them with arch validity please note. =
          ^^^^
>  You can't expect Dave to fix that.....no doubt you also saw Dave's =
> response.

He's talking about LDP/Unicast.  Which we use for everything except if
you *only* use TE in the core.  So his view of the world is much more
narrow than you imagined!

...George

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719



From owner-mpls@UU.NET  Tue Nov 11 11:02: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 LAA07257
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 11:02: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 QQpojg01637
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 16:03: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 QQpojg01390;
	Tue, 11 Nov 2003 16:02:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpojf29055
	for mpls-outgoing; Tue, 11 Nov 2003 15:47:21 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 QQpojf29040
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 15:47:19 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 QQpoje25343
	for <mpls@uu.net>; Tue, 11 Nov 2003 15:38:56 GMT
From: jcucchiara@mindspring.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 QQpoje18205
	for <mpls@uu.net>; Tue, 11 Nov 2003 15:38:56 GMT
Received: from hall.mail.mindspring.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hall.mail.mindspring.net [207.69.200.60])
	id QQpoje18194
	for <mpls@uu.net>; Tue, 11 Nov 2003 15:38:56 GMT
Received: from [192.168.167.40] (helo=wamui02.slb.atl.earthlink.net)
	by hall.mail.mindspring.net with esmtp (Exim 3.33 #1)
	id 1AJabX-00032W-00; Tue, 11 Nov 2003 10:38:55 -0500
Message-ID: <17555366.1068565135550.JavaMail.root@wamui02.slb.atl.earthlink.net>
Date: Tue, 11 Nov 2003 10:38:47 -0500 (EST)
Reply-To: jcucchiara@mindspring.com
To: wlai@att.com
Subject: Re: I-D ACTION:draft-lai-mpls-ldp-hist-mib-00.txt
Cc: mpls@UU.NET
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Earthlink Zoo Mail 1.0
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Wai Sum,

Could you please directly address the following questions/comments:

1)  Why does an operator care about a total for Established Sessions
and Terminated Sessions on a per Entity basis?  
These counters are AUGMENTS to the
Entity table and I am unclear as to why an operator would deem these
counts useful.  Please do not tell me that it is helpful for router resource
management and engineering of LDP sessions.  Please tell me "how" they
address the issue of router resource management and/or engineering of
LDP sessions.    An Entity is a MIB construct.  Keeping totals of all sessions,
which were established or terminated on a per Entity basis 
over some time frame, does not seem very helpful in my opinion, so
I am trying to understand why you think that these are helpful. 

2)  With regard to the counters which are being proposed to AUGMENT 
the session table, exactly how do they help with Fault Management unless
an NMS is polling them on every single node, on every LSP from start to 
end, and the agent is storing some history of these on every node? 
How does this help with router resources?  

I would think that such a feature would use quite a bit of router resources 
to store this information.


3) Also with regard to the counters which AUGMENT the session table,
if/when the LSP goes down, what happens to the information
stored in this table.  Since it AUGMENTS the session table, the session is
gone, so is this information gone also?

   thanks, 
    -Joan


-----Original Message-----

Joan,
  Thanks for your review of our draft and the comments below.
  As described in Section 2.1 of our draft, our requirements are very
specific, i.e., for the engineering of LDP Sessions and router resource
management.  To meet this requirement, there is a need to capture the
signaling usage/performance of the LDP Entities, and the traffic usage/
performance of the LDP Sessions.  Another specific requirement for
fault management is the need for persistent LSP information that
survives LSP failures.  The draft currently proposes five additional
objects, while the issue of measurement interval and recording counters
to maintain persistent history has been left open for further
discussion.
  We would like to hear also other SP's view on our draft.  Comments
and suggestions on how the above requirements could/should be met are
particularly welcome.
Thanks, Wai Sum

-----Original Message-----
From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com]
Sent: Sunday, November 09, 2003 12:13 PM
To: Lai, Wai S (Waisum), ALABS
Cc: mpls@UU.NET
Subject: Re: I-D ACTION:draft-lai-mpls-ldp-hist-mib-00.txt



Hi Wai Sum,

I have read this draft several times and was confused by it.
The requirements are very broad areas (i.e. Performance Management
Requirement,
Fault Management Requirement), however, the proposed solution of adding
5 new
objects so as to lessen the burden on the SNMP manager (NMS),
did not follow.

The objects being proposed are also confusing to me.  The Attempted
Session counter is already in the MPLS-LDP-STD-MIB and the 
other 2 are totals don't provide relevant information in my opinion.
Why does an operator care about an Entity which is a MIB constuct
and not really important to LDP performance?

Also, the packet counters are not going to be useful unless you
are utilizing an NMS to monitor every node, and every LDP-LSP from
start to end.  You say you do not want to "burden" the network with
additional NMS traffic or increase polling on nodes, 
but that would be the only way to make these counters useful 
as far as I can tell.

I would like to hear from other operators on this draft.

  thanks, Joan


At 06:29 PM 10/22/03 -0400, Internet-Drafts@ietf.org wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
>	Title		: A Supplementary History Module for the MPLS
LDP-MIB
>	Author(s)	: W. Lai
>	Filename	: draft-lai-mpls-ldp-hist-mib-00.txt
>	Pages		: 8
>	Date		: 2003-10-22
>	
>In this document, requirements for supplementing the MPLS LDP-MIB 
>are presented for the support of specific network management needs 
>for fault and performance management.  Based on these requirements, 
>it describes managed objects in a supplementary history module for 
>use with the LDP-MIB.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-lai-mpls-ldp-hist-mib-00.txt
>










From owner-mpls@UU.NET  Tue Nov 11 11:03: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 LAA07304
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 11:03: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 QQpojg04919
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 16:03: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 QQpojg04707;
	Tue, 11 Nov 2003 16:03:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpojf29118
	for mpls-outgoing; Tue, 11 Nov 2003 15:48: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 QQpojf29110
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 15:48:29 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 QQpojf05746
	for <mpls@UU.NET>; Tue, 11 Nov 2003 15:48: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 QQpojf11152
	for <mpls@UU.NET>; Tue, 11 Nov 2003 15:48:05 GMT
Received: from relay0.netfirms.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: m0.netfirms.com [209.171.43.51])
	id QQpojf11130
	for <mpls@UU.NET>; Tue, 11 Nov 2003 15:48:04 GMT
Received: (qmail 462 invoked from network); 11 Nov 2003 15:39:03 -0000
Received: from dyn132-211.ietf58.ietf.org (HELO Puppy) (130.129.132.211)
  by 0 with SMTP; 11 Nov 2003 15:39:03 -0000
Message-ID: <010701c3a869$f1437bf0$db818182@Puppy>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Soft/hard pre-emption
Date: Tue, 11 Nov 2003 15:39:01 -0000
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.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

As my first step in resolving this issue I would like to conduct a brief survey amongst
implementors.

Please feel free to respond to me off-list and in confidence. If you do not want your
information shared more widely, please state that explicitly in your email.

Also, please note that this questionnaire is NOT a discussion of what is the correct
behavior. It is simply collecting information about interpretation of RFCs 2205 and 3209.

Thanks,
Adrian

Questions:

1. When your implementation receives a PathErr message indicating pre-emption for an
established LSP, does it tear the LSP (i.e. release labels) or only release resources
(i.e. leave the LSP in place as 'best effort')?
In other words, is your default behavior hard or soft pre-emption?

2. When your implementation receives any other (non-notify) PathErr for an established
LSP, does it tear the LSP (i.e. release labels) or leave it in place?

3. Is your code carrying live traffic, in lab tests, or in development?

4. If deployed, can you give me a feeling for the number of LSRs in the field (just an
order of magnitude)?

Thanks,
Adrian



From owner-mpls@UU.NET  Tue Nov 11 11:27: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 LAA08355
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 11:27:21 -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 QQpojh08038
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 16:27:32 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 QQpojh07875;
	Tue, 11 Nov 2003 16:27:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpojg19827
	for mpls-outgoing; Tue, 11 Nov 2003 16:11: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 QQpojg19773
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 16:11:04 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 QQpojg19271
	for <mpls@uu.net>; Tue, 11 Nov 2003 16:10: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 QQpojg13148
	for <mpls@uu.net>; Tue, 11 Nov 2003 16:10:55 GMT
Received: from sj-iport-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70])
	id QQpojg13116
	for <mpls@uu.net>; Tue, 11 Nov 2003 16:10:54 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hABGAmAt017274
	for <mpls@uu.net>; Tue, 11 Nov 2003 08:10:48 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADW96335;
	Tue, 11 Nov 2003 11:10:47 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hABGAlX01793 for mpls@uu.net; Tue, 11 Nov 2003 11:10:47 -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 QQpojg19286
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 16:09: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 QQpojg28517
	for <mpls@UU.NET>; Tue, 11 Nov 2003 16:08: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 QQpojg07893
	for <mpls@UU.NET>; Tue, 11 Nov 2003 16:08:27 GMT
Received: from exchange.timetra.com by cmr0.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 QQpojg07881
	for <mpls@UU.NET>; Tue, 11 Nov 2003 16:08:27 GMT
Received: from vkompellaxp ([192.168.5.178] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Tue, 11 Nov 2003 08:08:24 -0800
Reply-To: <vach.kompella@alcatel.com>
From: "Vach Kompella" <vach.kompella@alcatel.com>
To: "'Ina Minei'" <ina@juniper.net>, "'Luca Martini'" <lmartini@cisco.com>
Cc: "'jason rusmisel'" <jason.rusmisel@alcatel.com>, <mpls@UU.NET>
Subject: RE: I-D ACTION:draft-minei-mpls-ldp-external-00.txt (fwd)
Date: Tue, 11 Nov 2003 08:10:33 -0800
Organization: Alcatel USA
Message-ID: <00c901c3a86e$56e939a0$0101010a@eng.timetra.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
In-Reply-To: <20031111063341.T16133@garnet.juniper.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-OriginalArrivalTime: 11 Nov 2003 16:08:24.0757 (UTC) FILETIME=[09030E50:01C3A86E]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

There is a technique which avoids external routes altogether.  The basic
technique is to run IBGP between PE routers only, to do your normal
application of policy, costing, route selection, etc. that BGP gives
you.  Once you pick the BGP next hop that is the best route, you
normally turn to your IGP to get to the BGP next hop.  Instead, what you
do is that you figure out the LDP path to that BGP next hop, and tunnel
the IP packet there.  For want of a better term, let's call this the BGP
shortcuts method.

So there are several issues I'd like you to address, with ref to the
IBGP mesh-avoidance technique:

1. is it less costly?
   - your solution requires all external routes in the LDP database
   - the BGP shortcuts method does not

2. is it more "correct"?
   - since your normal approach to dealing with external routes is to
apply BGP route selection, by sending the external route via LDP without
the BGP attributes, you aren't quite doing what you used to, when you
used IBGP.  I'd suggest that there should be an opaque TLV that carries
BGP attributes so the PEs can do similar route selection.

3. does it converge faster?
   - I highly doubt it: you potentially have BGP, IGP and LDP that need
to converge

So, Luca, could you please resurrect your draft, and let's have some
discussions focussed around that solution?

-Vach=20

> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf=20
> Of Ina Minei
> Sent: Tuesday, November 11, 2003 6:38 AM
> To: Luca Martini
> Cc: jason rusmisel; mpls@UU.NET
> Subject: Re: I-D ACTION:draft-minei-mpls-ldp-external-00.txt (fwd)
>=20
>=20
>=20
> 	There is nothing wrong in that. The mechanism described=20
> in the draft is a general mechnism, the vpn scenario is a=20
> usage example.
>=20
> 				Thank you,
>=20
> 					Ina
>=20
> On Mon, 10 Nov 2003, Luca Martini wrote:
>=20
> > so what is wrong with using the IBGP, and 3 label MPLS=20
> stack , while=20
> > leaving LDP out of the routing business ?
> >
> > Luca
> >



From owner-mpls@UU.NET  Tue Nov 11 11:28: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 LAA08484
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 11:28: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 QQpojh06363
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 16:28:58 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 QQpojh06150;
	Tue, 11 Nov 2003 16:28:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpojg20215
	for mpls-outgoing; Tue, 11 Nov 2003 16: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 QQpojg20199
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 16:13:41 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 QQpojg17520
	for <mpls@uu.net>; Tue, 11 Nov 2003 16: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 QQpojg00160
	for <mpls@uu.net>; Tue, 11 Nov 2003 16:13:00 GMT
Received: from sj-iport-4.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-4.cisco.com [171.68.10.86])
	id QQpojg00143
	for <mpls@uu.net>; Tue, 11 Nov 2003 16:12:59 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hABGCtw5000446
	for <mpls@uu.net>; Tue, 11 Nov 2003 08:12:56 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADW96542;
	Tue, 11 Nov 2003 11:12:54 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hABGCsq01813 for mpls@uu.net; Tue, 11 Nov 2003 11: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 QQpojg20043
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 16:12: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 QQpojg19591
	for <mpls@UU.NET>; Tue, 11 Nov 2003 16:11: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 QQpojg11202
	for <mpls@UU.NET>; Tue, 11 Nov 2003 16:11:07 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 QQpojg11173
	for <mpls@UU.NET>; Tue, 11 Nov 2003 16:11:06 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.8p1/8.12.8) with ESMTP id hABGAThO031321;
	Tue, 11 Nov 2003 11:10:29 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311111610.hABGAThO031321@workhorse.fictitious.org>
To: George Swallow <swallow@cisco.com>
cc: curtis@fictitious.org, loa@pi.se,
        Shahram Davari <Shahram_Davari@pmc-sierra.com>, MPLS wg <mpls@UU.NET>,
        Alex Zinin <zinin@psg.com>
Reply-To: curtis@fictitious.org
Subject: Re: on the mpls oam framework 
In-reply-to: Your message of "Tue, 11 Nov 2003 10:10:36 EST."
             <200311111510.hABFAaxg011064@rtp-core-1.cisco.com> 
Date: Tue, 11 Nov 2003 11:10:29 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <200311111510.hABFAaxg011064@rtp-core-1.cisco.com>, George Swallow w
rites:
> Curtis -
> 
> > I'm personally not all that convinced about P-MP but I'm also not
> > ready to say it should be eliminated based on it not fitting into a
> > particular OAM framework.
> 
> You need to re-read what Neil wrote.  
> 
> > Loa....you are misrepresenting my 'agreement on the situation'.   I =
> > agree there is a problem.....but has it ever occurred to you that the =
> > starting point may be wrong?  The problem is not that Dave's paper fails =
> > to line-up with the MPLS arch papers, the problem is that the MPLS arch =
> > (sic) stuff is itself architecturally broken......the mere act of =
> > 'doing' mp2p and PHP does not bless them with arch validity please note. =
>           ^^^^
> >  You can't expect Dave to fix that.....no doubt you also saw Dave's =
> > response.
> 
> He's talking about LDP/Unicast.  Which we use for everything except if
> you *only* use TE in the core.  So his view of the world is much more
> narrow than you imagined!
> 
> ...George


Right..  Sorry.  Amend my statement to "I'm also not ready to say we
should eliminate mp2p based on it not fitting into a particular OAM
framework".

LDP/unicast seems here to stay as well.

Curtis



From owner-mpls@UU.NET  Tue Nov 11 11:58: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 LAA09947
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 11:58: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 QQpojj07783
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 16:58: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 QQpojj07653;
	Tue, 11 Nov 2003 16:58:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoji22868
	for mpls-outgoing; Tue, 11 Nov 2003 16:38: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 QQpoji22863
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 16:38: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 QQpoji04181
	for <mpls@uu.net>; Tue, 11 Nov 2003 16:37: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 QQpoji15781
	for <mpls@uu.net>; Tue, 11 Nov 2003 16:37:51 GMT
Received: from sj-iport-4.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-4.cisco.com [171.68.10.86])
	id QQpoji15769
	for <mpls@uu.net>; Tue, 11 Nov 2003 16:37:50 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hABGbkxg005084
	for <mpls@uu.net>; Tue, 11 Nov 2003 11:37:47 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADW99573;
	Tue, 11 Nov 2003 11:37:45 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hABGbjL06296 for mpls@uu.net; Tue, 11 Nov 2003 11:37:45 -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 QQpoji22566
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 16:35:37 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 QQpoji29759
	for <mpls@UU.NET>; Tue, 11 Nov 2003 16:33: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 QQpoji15622
	for <mpls@UU.NET>; Tue, 11 Nov 2003 16:33:07 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 QQpoji15594
	for <mpls@UU.NET>; Tue, 11 Nov 2003 16:33:06 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.8p1/8.12.8) with ESMTP id hABGWPhO031408;
	Tue, 11 Nov 2003 11:32:26 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311111632.hABGWPhO031408@workhorse.fictitious.org>
To: "David Allan" <dallan@nortelnetworks.com>
cc: "'loa@pi.se'" <loa@pi.se>, Shahram Davari <Shahram_Davari@pmc-sierra.com>,
        MPLS wg <mpls@UU.NET>, George Swallow <swallow@cisco.com>,
        Alex Zinin <zinin@psg.com>
Reply-To: curtis@fictitious.org
Subject: Re: on the mpls oam framework 
In-reply-to: Your message of "Tue, 11 Nov 2003 09:09:35 EST."
             <FFFC48AEAA5F7447929F4F0D93FCC12D02B9277E@zcard031.ca.nortel.com> 
Date: Tue, 11 Nov 2003 11:32:25 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <FFFC48AEAA5F7447929F4F0D93FCC12D02B9277E@zcard031.ca.nortel.com>, "
David Allan" writes:
> 
> > 
> > But you are misrepresenting me when you say that the
> > differences is not resolvable. In fact the proposal to start 
> > on a fresh document is intended jsut to achieve that. I guess 
> > that if there are two people representing two different ideas 
> > on a subject, the requirement that one of the has to accept 
> > the ideas of the other to be part work seems to be counter-productive.
> 
> I think that cuts both ways. I'm certainly willing to enlarge the document
> to include both points of view. It is a framework document after all.....
> ;-)
> 
> cheers
> Dave


Dave,

A measurement framework that only works for one case, RSVP/TE not
using PHP or ECMP, is of very limited use.  A more useful measurement
framework would work for RSVP/TE but also works for LDP with its mp2p
nature, works with ECMP used with LDP (or RSVP/TE over hierarchical
tunnels).  MPLS OAM defined in the ITU only works for RSVP/TE, no PHP,
no ECMP.  MPLS ping/traceroute works for all of the above cases,
provides more information.  MPLS Ping is also infinitely more
practical because it can be implemented without change to the high
speed forwarding plane (because it involves only altered TTL
processing) or at most minimal change.

As long as you are offering a framework in which MPLS OAM is the
solution and all network architectures for which MPLS OAM doesn't work
are described as "broken" or deficient, there is no sense in the MPLS
WG giving it serious consideration.

If on the other hand the document described an approach that worked
in all conditions that are of interest and also mentioned a tool for a
specific circumstance favored by some, you'd have a document the WG
could consider for advancement.  That is a very different document
from what you now have and it does require starting over.

Curtis



From owner-mpls@UU.NET  Tue Nov 11 12:16: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 MAA10847
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 12:16: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 QQpojl01440
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 17:16: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 QQpojl01151;
	Tue, 11 Nov 2003 17:16:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpojj25142
	for mpls-outgoing; Tue, 11 Nov 2003 16:59: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 QQpojj25131
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 16:59: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 QQpojj27361
	for <mpls@uu.net>; Tue, 11 Nov 2003 16:57: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 QQpojj16577
	for <mpls@uu.net>; Tue, 11 Nov 2003 16:57:27 GMT
Received: from sj-iport-5.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-5.cisco.com [171.68.10.87])
	id QQpojj16561
	for <mpls@uu.net>; Tue, 11 Nov 2003 16:57:27 GMT
Received: from cisco.com (171.68.223.137)
  by sj-iport-5.cisco.com with ESMTP; 11 Nov 2003 09:01:01 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hABGvNrX000161
	for <mpls@uu.net>; Tue, 11 Nov 2003 08:57:24 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADX01729;
	Tue, 11 Nov 2003 11:57:22 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hABGvMH07870 for mpls@uu.net; Tue, 11 Nov 2003 11:57:22 -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 QQpojj24687
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 16:54:46 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 QQpojj14964
	for <mpls@UU.NET>; Tue, 11 Nov 2003 16:52: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 QQpojj00257
	for <mpls@UU.NET>; Tue, 11 Nov 2003 16:52:18 GMT
Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: mother.pmc-sierra.com [216.241.224.12])
	id QQpojj00235
	for <mpls@UU.NET>; Tue, 11 Nov 2003 16:52:17 GMT
Received: (qmail 10157 invoked by uid 12059); 11 Nov 2003 16:52:16 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.20rc3 
 (uvscan: v4.1.40/v4302.  Clear:RC:1:. 
 Processed in 0.118933 secs); 11 Nov 2003 16:52:16 -0000
Received: from unknown (HELO ogmios.pmc-sierra.bc.ca) (216.241.226.59)
  by mother.pmc-sierra.com with SMTP; 11 Nov 2003 16:52:16 -0000
Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by ogmios.pmc-sierra.bc.ca (8.12.9/8.12.7) with ESMTP id hABGqF8p018535;
	Tue, 11 Nov 2003 08:52:15 -0800
Received: by bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59)
	id <TFV20KFB>; Tue, 11 Nov 2003 08:52:15 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115CCD9@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        David Allan
	 <dallan@nortelnetworks.com>
Cc: "'loa@pi.se'" <loa@pi.se>, MPLS wg <mpls@UU.NET>,
        George Swallow
	 <swallow@cisco.com>, Alex Zinin <zinin@psg.com>
Subject: RE: on the mpls oam framework 
Date: Tue, 11 Nov 2003 08:52:12 -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

Curtis,

I think you are misreading the draft. It doesn't say that there shouldn't be any OAM
tools for ECMP, PHP, Mp2p. All it says is that special considerations and complexities
are involved in those cases, and it outlines the issues that needs to be considered
while designing an OAM tool.

So I don't see your point as a valid point to discard this draft, and I am sure many
other WG members agree with me.

Yours,
-Shahram

>-----Original Message-----
>From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org]
>Sent: Tuesday, November 11, 2003 11:32 AM
>To: David Allan
>Cc: 'loa@pi.se'; Shahram Davari; MPLS wg; George Swallow; Alex Zinin
>Subject: Re: on the mpls oam framework 
>
>
>
>In message 
><FFFC48AEAA5F7447929F4F0D93FCC12D02B9277E@zcard031.ca.nortel.com>, "
>David Allan" writes:
>> 
>> > 
>> > But you are misrepresenting me when you say that the
>> > differences is not resolvable. In fact the proposal to start 
>> > on a fresh document is intended jsut to achieve that. I guess 
>> > that if there are two people representing two different ideas 
>> > on a subject, the requirement that one of the has to accept 
>> > the ideas of the other to be part work seems to be 
>counter-productive.
>> 
>> I think that cuts both ways. I'm certainly willing to 
>enlarge the document
>> to include both points of view. It is a framework document 
>after all.....
>> ;-)
>> 
>> cheers
>> Dave
>
>
>Dave,
>
>A measurement framework that only works for one case, RSVP/TE not
>using PHP or ECMP, is of very limited use.  A more useful measurement
>framework would work for RSVP/TE but also works for LDP with its mp2p
>nature, works with ECMP used with LDP (or RSVP/TE over hierarchical
>tunnels).  MPLS OAM defined in the ITU only works for RSVP/TE, no PHP,
>no ECMP.  MPLS ping/traceroute works for all of the above cases,
>provides more information.  MPLS Ping is also infinitely more
>practical because it can be implemented without change to the high
>speed forwarding plane (because it involves only altered TTL
>processing) or at most minimal change.
>
>As long as you are offering a framework in which MPLS OAM is the
>solution and all network architectures for which MPLS OAM doesn't work
>are described as "broken" or deficient, there is no sense in the MPLS
>WG giving it serious consideration.
>
>If on the other hand the document described an approach that worked
>in all conditions that are of interest and also mentioned a tool for a
>specific circumstance favored by some, you'd have a document the WG
>could consider for advancement.  That is a very different document
>from what you now have and it does require starting over.
>
>Curtis
>



From owner-mpls@UU.NET  Tue Nov 11 12:17: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 MAA10892
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 12:17: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 QQpojl04198
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 17:17: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 QQpojl03929;
	Tue, 11 Nov 2003 17:17:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpojk29970
	for mpls-outgoing; Tue, 11 Nov 2003 17:00: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 QQpojk28917
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 17:00:42 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 QQpojj08947
	for <mpls@UU.NET>; Tue, 11 Nov 2003 16:58: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 QQpojj08121
	for <mpls@UU.NET>; Tue, 11 Nov 2003 16:58:58 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 QQpojj08101
	for <mpls@UU.NET>; Tue, 11 Nov 2003 16:58:57 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hABGwRY29944;
	Tue, 11 Nov 2003 11:58:27 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <W3H866TV>; Tue, 11 Nov 2003 11:58:28 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D02B92781@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>
Cc: "'loa@pi.se'" <loa@pi.se>,
        Shahram Davari
	 <Shahram_Davari@pmc-sierra.com>,
        MPLS wg <mpls@UU.NET>, Alex Zinin
	 <zinin@psg.com>
Subject: RE: on the mpls oam framework 
Date: Tue, 11 Nov 2003 11:58:26 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-mpls@UU.NET
Precedence: bulk

If you want to trivialize the framework draft to the ITU stuff only, read
the Y.17fec-cv overview draft. 

IMHO You are persisting in ignoring what you don't want to see.

rgds
Dave

> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] 
> Sent: Tuesday, November 11, 2003 11:32 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: 'loa@pi.se'; Shahram Davari; MPLS wg; George Swallow; Alex Zinin
> Subject: Re: on the mpls oam framework 
> 
> 
> 
> In message 
> <FFFC48AEAA5F7447929F4F0D93FCC12D02B9277E@zcard031.ca.nortel.c
> om>, " David Allan" writes:
> > 
> > > 
> > > But you are misrepresenting me when you say that the 
> differences is 
> > > not resolvable. In fact the proposal to start on a fresh 
> document is 
> > > intended jsut to achieve that. I guess that if there are 
> two people 
> > > representing two different ideas on a subject, the 
> requirement that 
> > > one of the has to accept the ideas of the other to be part work 
> > > seems to be counter-productive.
> > 
> > I think that cuts both ways. I'm certainly willing to enlarge the 
> > document to include both points of view. It is a framework document 
> > after all.....
> > ;-)
> > 
> > cheers
> > Dave
> 
> 
> Dave,
> 
> A measurement framework that only works for one case, RSVP/TE 
> not using PHP or ECMP, is of very limited use.  A more useful 
> measurement framework would work for RSVP/TE but also works 
> for LDP with its mp2p nature, works with ECMP used with LDP 
> (or RSVP/TE over hierarchical tunnels).  MPLS OAM defined in 
> the ITU only works for RSVP/TE, no PHP, no ECMP.  MPLS 
> ping/traceroute works for all of the above cases, provides 
> more information.  MPLS Ping is also infinitely more 
> practical because it can be implemented without change to the 
> high speed forwarding plane (because it involves only altered TTL
> processing) or at most minimal change.
> 
> As long as you are offering a framework in which MPLS OAM is 
> the solution and all network architectures for which MPLS OAM 
> doesn't work are described as "broken" or deficient, there is 
> no sense in the MPLS WG giving it serious consideration.
> 
> If on the other hand the document described an approach that 
> worked in all conditions that are of interest and also 
> mentioned a tool for a specific circumstance favored by some, 
> you'd have a document the WG could consider for advancement.  
> That is a very different document from what you now have and 
> it does require starting over.
> 
> Curtis
> 


From owner-mpls@UU.NET  Tue Nov 11 12:45:07 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 MAA12895
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 12:45:07 -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 QQpojn16963
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 17:45: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 QQpojn16745;
	Tue, 11 Nov 2003 17:45:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpojl17471
	for mpls-outgoing; Tue, 11 Nov 2003 17:29: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 QQpojl17464
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 17:29: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 QQpojl25035
	for <mpls@UU.NET>; Tue, 11 Nov 2003 17:28: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 QQpojl26688
	for <mpls@UU.NET>; Tue, 11 Nov 2003 17:28:35 GMT
Received: from psg.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: psg.com [147.28.0.62])
	id QQpojl26670
	for <mpls@UU.NET>; Tue, 11 Nov 2003 17:28:35 GMT
Received: from psg.com ([147.28.0.62] helo=[127.0.0.1])
	by psg.com with esmtp (Exim 4.24; FreeBSD 4.9)
	id 1AJcJe-000APU-IT
	for mpls@UU.NET; Tue, 11 Nov 2003 17:28:34 +0000
Date: Tue, 11 Nov 2003 11:28:04 -0600
From: Alex Zinin <zinin@psg.com>
Reply-To: Alex Zinin <zinin@psg.com>
X-Priority: 3 (Normal)
Message-ID: <5012035626.20031111112804@psg.com>
To: MPLS wg <mpls@UU.NET>
Subject: My comment on draft-chen-ldp-ttl
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


A more elaborate version of the comment I made at the mic today:

The draft uses the LDP Hello message to negotiate enabling of the TTL
check. Though the draft says that only Link Hellos (T=0) should be
used for this, it does not say anything about securing those Hellos.
Neither RFC3036 nor the draft _require_ the receiving LSR to drop Link
Hellos that are sent to an address other than the AllRouters multicast
(e.g. an LSR's unicast address). So if a spoofed Link Hello is
accepted, the receiver may mistakenly apply the TTL check to a session
with a peer that does not support it, and hence prevent it from coming
up. Similarly, if a Hello without the new parameter is spoofed, the
attacker may cause the LSR to disable the check and mount a
overloading DoS attack against an existing session.

I would suggest that the draft is modified to recommend that Link
Hellos (with or without the new optional parameter) MUST be sent to
the unroutable AllRouters multicast address and MUST be dropped by the
receiver if they are not. This should make the Link Hellos at least as
secure as the session packets.

The Security Consideration section should also be extended to describe
the potential Link Hello spoofing attack possible by an on-the-wire
adversary, and then point out that given the current network
operational practices, the risk of such exposure is considered to be
sufficiently low.

--
Alex



From owner-mpls@UU.NET  Tue Nov 11 13:26: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 NAA14418
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 13:26: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 QQpojp17644
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 18:26: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 QQpojp17439;
	Tue, 11 Nov 2003 18:26:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpojo09979
	for mpls-outgoing; Tue, 11 Nov 2003 18:11: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 QQpojo09974
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 18:11: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 QQpojo21710
	for <mpls@uu.net>; Tue, 11 Nov 2003 18:11: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 QQpojo28354
	for <mpls@uu.net>; Tue, 11 Nov 2003 18:11:27 GMT
Received: from sj-iport-5.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-5.cisco.com [171.68.10.87])
	id QQpojo28345
	for <mpls@uu.net>; Tue, 11 Nov 2003 18:11:26 GMT
Received: from cisco.com (64.102.124.13)
  by sj-iport-5.cisco.com with ESMTP; 11 Nov 2003 10:15:00 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hABIBMDM026143
	for <mpls@uu.net>; Tue, 11 Nov 2003 13:11:22 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADX09812;
	Tue, 11 Nov 2003 13:11:21 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hABIBLj13936 for mpls@uu.net; Tue, 11 Nov 2003 13:11:21 -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 QQpojo09195
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 18:08:34 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 QQpojo29429
	for <mpls@UU.NET>; Tue, 11 Nov 2003 18:07: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 QQpojo02803
	for <mpls@UU.NET>; Tue, 11 Nov 2003 18:07: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 QQpojo02782
	for <mpls@UU.NET>; Tue, 11 Nov 2003 18:07:54 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.8p1/8.12.8) with ESMTP id hABI7ShO031954;
	Tue, 11 Nov 2003 13:07:28 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311111807.hABI7ShO031954@workhorse.fictitious.org>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
cc: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        David Allan <dallan@nortelnetworks.com>, "'loa@pi.se'" <loa@pi.se>,
        MPLS wg <mpls@UU.NET>, George Swallow <swallow@cisco.com>,
        Alex Zinin <zinin@psg.com>
Reply-To: curtis@fictitious.org
Subject: Re: on the mpls oam framework 
In-reply-to: Your message of "Tue, 11 Nov 2003 08:52:12 PST."
             <4B6D09F3B826D411A67300D0B706EFDE0115CCD9@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> 
Date: Tue, 11 Nov 2003 13:07:28 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <4B6D09F3B826D411A67300D0B706EFDE0115CCD9@nt-exch-yow.pmc_nt.nt.pmc-
sierra.bc.ca>, Shahram Davari writes:
>  
> Curtis,
>  
> I think you are misreading the draft. It doesn't say that there
> shouldn't be any OAM tools for ECMP, PHP, Mp2p. All it says is that
> special considerations and complexities are involved in those cases,
> and it outlines the issues that needs to be considered while designing
> an OAM tool.
>  
> So I don't see your point as a valid point to discard this draft, and
> I am sure many other WG members agree with me.
>  
> Yours,
> -Shahram


I think the draft as is could be submitted as an informational draft
submitted by Dave outside the work group.

As a framework for OAM it is a diversion from progress rather than a
step toward progress.  It would be enough to give a simple statement
that any form of OAM which simply injects traffic at ingress and
counts traffic at egress is insufficient in many circumstances and
perhaps briefly enumerate the circumstances rather than describe them
in detail.  The framework can then outline requirements agreed to in
the WG and if it follows other framework documents it may touch on
solution approaches concentrating on those that work within the entire
framework (work in all cases, meet the largest set of requirements).
Mention can be made of those approaches that work in a limited context
but the overall emphasis should not be on evaluation of the
implications of network topology on a specific solution that has been
rejected by the WG.

Curtis



From owner-mpls@UU.NET  Tue Nov 11 14:19:36 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 OAA16192
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 14:19: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 QQpojt00469
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 19:19: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 QQpojt00008;
	Tue, 11 Nov 2003 19:19:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpojs19184
	for mpls-outgoing; Tue, 11 Nov 2003 19:00: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 QQpojs18765
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 19:00: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 QQpojr18838
	for <mpls@UU.NET>; Tue, 11 Nov 2003 18:56: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 QQpojr16231
	for <mpls@UU.NET>; Tue, 11 Nov 2003 18:56:12 GMT
Received: from auemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: auemail2.lucent.com [192.11.223.163])
	id QQpojr16215
	for <mpls@UU.NET>; Tue, 11 Nov 2003 18:56:11 GMT
Received: from md6370exch004u.wins.lucent.com (h135-114-172-12.lucent.com [135.114.172.12])
	by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hABIuXA15692
	for <mpls@UU.NET>; Tue, 11 Nov 2003 12:56:44 -0600 (CST)
Received: by md6370exch004u.nse.lucent.com with Internet Mail Service (5.5.2653.19)
	id <4C4HHAAP>; Tue, 11 Nov 2003 13:55:34 -0500
Message-ID: <305D2EAC01C45448A7F3ECC487666F6C09BA76CE@md6370exch004u.nse.lucent.com>
From: "Natale, Robert C (Bob)" <bnatale@lucent.com>
To: MPLS wg <mpls@UU.NET>
Subject: RE: on the mpls oam framework 
Date: Tue, 11 Nov 2003 13:55:32 -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,

Largely for the reasons already outlined by Loa, Curtis, Tom,
and George (apologies if I have misunderstood any of your
positions), I support re-starting the MPLS Management Framework
effort.  This framework should be as consonant as possible with
the existing MPLS Architectural Framework at this point in time.

As has also been pointed out, Dave, Neil, and others have made
some excellent observations that may need to be considered in
both future evolutions of the MPLS architecture documents and
ancillary/specific management-related documents.  But the baseline
MPLS Management Framework document needs to be as synergistic as
possible with standard MPLS architecture and with the most common
current and near-term deployment scenarios.

Cheers,

BobN

> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org]
> Sent: Tuesday, November 11, 2003 1:07 PM
> To: Shahram Davari
> Cc: 'curtis@fictitious.org'; David Allan; 'loa@pi.se'; MPLS wg; George
> Swallow; Alex Zinin
> Subject: Re: on the mpls oam framework 
> 
> 
> 
> In message 
> <4B6D09F3B826D411A67300D0B706EFDE0115CCD9@nt-exch-yow.pmc_nt.nt.pmc-
> sierra.bc.ca>, Shahram Davari writes:
> >  
> > Curtis,
> >  
> > I think you are misreading the draft. It doesn't say that there
> > shouldn't be any OAM tools for ECMP, PHP, Mp2p. All it says is that
> > special considerations and complexities are involved in those cases,
> > and it outlines the issues that needs to be considered 
> while designing
> > an OAM tool.
> >  
> > So I don't see your point as a valid point to discard this 
> draft, and
> > I am sure many other WG members agree with me.
> >  
> > Yours,
> > -Shahram
> 
> 
> I think the draft as is could be submitted as an informational draft
> submitted by Dave outside the work group.
> 
> As a framework for OAM it is a diversion from progress rather than a
> step toward progress.  It would be enough to give a simple statement
> that any form of OAM which simply injects traffic at ingress and
> counts traffic at egress is insufficient in many circumstances and
> perhaps briefly enumerate the circumstances rather than describe them
> in detail.  The framework can then outline requirements agreed to in
> the WG and if it follows other framework documents it may touch on
> solution approaches concentrating on those that work within the entire
> framework (work in all cases, meet the largest set of requirements).
> Mention can be made of those approaches that work in a limited context
> but the overall emphasis should not be on evaluation of the
> implications of network topology on a specific solution that has been
> rejected by the WG.
> 
> Curtis
> 


From owner-mpls@UU.NET  Tue Nov 11 17:34: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 RAA25429
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 17:34: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 QQpokg02829
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 22:34: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 QQpokg02467;
	Tue, 11 Nov 2003 22:34:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpokf17548
	for mpls-outgoing; Tue, 11 Nov 2003 22:16: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 QQpokf17543
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Nov 2003 22:16: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 QQpoke15049
	for <mpls@uu.net>; Tue, 11 Nov 2003 22:14: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 QQpoke26420
	for <mpls@uu.net>; Tue, 11 Nov 2003 22:14:12 GMT
Received: from tiger.seabridge.co.il by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [212.25.127.226])
	id QQpoke26359
	for <mpls@uu.net>; Tue, 11 Nov 2003 22:14:11 GMT
Received: by tiger.seabridge.co.il with Internet Mail Service (5.5.2653.19)
	id <V1ZD152N>; Wed, 12 Nov 2003 00:14:26 +0200
Message-ID: <C87E5A01714C7840B92CDED9E79329CA0117D127@leopard.seabridge.co.il>
From: Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>
To: "'cheenu@bloomberg.net'" <cheenu@bloomberg.net>,
        "'arunv@force10networks.com'" <arunv@force10networks.com>,
        "'tnadeau@cisco.com'" <tnadeau@cisco.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>,
        "'ccamp@ops.ietf.org'"
	 <ccamp@ops.ietf.org>
Subject: MPLS Tunnel Maximum Hops
Date: Wed, 12 Nov 2003 00:14:26 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="windows-1255"
Sender: owner-mpls@UU.NET
Precedence: bulk

Any response to the bellow?

Hi,
I have a question  regarding the mplsTunnelMaxHops scalar that indicates the
maximum number of hops that can be specified on each tunnel supported by the
LSR.
This scalar is a read only attribute but I can find it very useful to let
configure it as well. 
One of the CSPF constraints is the maximum number of hops the LSP may follow
through. The limitation on the maximum number for example can result from
the maximum packet size when fragmentation is not supported. In such a case
the maximum number of hops can depend on the network nature
(numbered/unnumbered). Instead of hard coding it with the worst case number,
let the network administrator, that is aware  of the network nature,
configure it.
Moreover, I think that the maximum hops should be configurable per tunnel.
Thanks, Nurit.


From owner-mpls@UU.NET  Tue Nov 11 22:38: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 WAA06095
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 22:38: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 QQpola12203
	for <mpls-archive@lists.ietf.org>; Wed, 12 Nov 2003 03:38: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 QQpola11878;
	Wed, 12 Nov 2003 03:38:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpokz17785
	for mpls-outgoing; Wed, 12 Nov 2003 03:18: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 QQpokz17778
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Nov 2003 03:18:19 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 QQpokz11030
	for <mpls@uu.net>; Wed, 12 Nov 2003 03:17: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 QQpokz14592
	for <mpls@uu.net>; Wed, 12 Nov 2003 03:17:39 GMT
Received: from sj-iport-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70])
	id QQpokz14584
	for <mpls@uu.net>; Wed, 12 Nov 2003 03:17:39 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAC3HZAt018636
	for <mpls@uu.net>; Tue, 11 Nov 2003 19:17:36 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADX50986;
	Tue, 11 Nov 2003 22:17:34 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAC3HYT22772 for mpls@uu.net; Tue, 11 Nov 2003 22:17:34 -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 QQpnys25657
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 8 Nov 2003 19:34: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 QQpnys12174
	for <mpls@uu.net>; Sat, 8 Nov 2003 19:33: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 QQpnys18424
	for <mpls@uu.net>; Sat, 8 Nov 2003 19:33:39 GMT
Received: from fep01-mail.bloor.is.net.cable.rogers.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fep01-mail.bloor.is.net.cable.rogers.com [66.185.86.71])
	id QQpnys18419
	for <mpls@uu.net>; Sat, 8 Nov 2003 19:33:38 GMT
Received: from dune ([24.103.66.219])
          by fep01-mail.bloor.is.net.cable.rogers.com
          (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP
          id <20031108193308.EZTX489038.fep01-mail.bloor.is.net.cable.rogers.com@dune>
          for <mpls@uu.net>; Sat, 8 Nov 2003 14:33:08 -0500
Message-ID: <009e01c3a62f$2125b960$2202a8c0@flfrd.phub.net.cable.rogers.com>
From: "Martin Dubuc" <m.dubuc@rogers.com>
To: "Mpls \(E-mail\)" <mpls@UU.NET>
Subject: TE Link MIB/Bandwidth Objects
Date: Sat, 8 Nov 2003 14:33:04 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_009B_01C3A605.380E1480"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4922.1500
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800
X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep01-mail.bloor.is.net.cable.rogers.com from [24.103.66.219] using ID <m.dubuc@rogers.com> at Sat, 8 Nov 2003 14:33:08 -0500
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_009B_01C3A605.380E1480
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

A concern was raised to change the type of the bandwidth objects of the =
TE link MIB. The current type expresses bandwidth in 1000 of bps on a 32 =
bit integer, which means the bandwidth of links is constrained at 4000 =
Gbps. I have investigated the issue and found that some drafts, like =
draft-katz-yeung-ospf-traffic-10.txt use 32-bit IEEE floating point =
format to represent link bandwidth. I am wondering if there is agreement =
to use such type in the TE link MIB.

Martin
------=_NextPart_000_009B_01C3A605.380E1480
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=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4926.2500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#fffbf0>
<DIV><FONT size=3D2>A concern was raised to change the type of the =
bandwidth=20
objects of the TE link MIB. The current type expresses bandwidth in 1000 =
of bps=20
on a 32 bit integer, which means the bandwidth of links is constrained=20
at&nbsp;4000 Gbps. I have investigated the issue and found that some =
drafts,=20
like draft-katz-yeung-ospf-traffic-10.txt use 32-bit IEEE floating point =
format=20
to represent link bandwidth. I am wondering if there is agreement to use =
such=20
type in the TE link MIB.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Martin</FONT></DIV></BODY></HTML>

------=_NextPart_000_009B_01C3A605.380E1480--



From owner-mpls@UU.NET  Tue Nov 11 22:43: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 WAA06244
	for <mpls-archive@lists.ietf.org>; Tue, 11 Nov 2003 22:43: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 QQpola03281
	for <mpls-archive@lists.ietf.org>; Wed, 12 Nov 2003 03:43: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 QQpola03083;
	Wed, 12 Nov 2003 03:43:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpokz18527
	for mpls-outgoing; Wed, 12 Nov 2003 03:27: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 QQpokz18520
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Nov 2003 03:27: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 QQpokz22500
	for <mpls@UU.NET>; Wed, 12 Nov 2003 03:25: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 QQpokz25385
	for <mpls@UU.NET>; Wed, 12 Nov 2003 03:25:58 GMT
Received: from prattle.redback.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: prattle.redback.com [155.53.12.9])
	id QQpokz25366
	for <mpls@UU.NET>; Wed, 12 Nov 2003 03:25:57 GMT
Received: from localhost (localhost [127.0.0.1])
	by prattle.redback.com (Postfix) with ESMTP
	id 407CB990C8E; Tue, 11 Nov 2003 19:25:57 -0800 (PST)
Received: from prattle.redback.com ([127.0.0.1])
 by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 12030-07; Tue, 11 Nov 2003 19:25:56 -0800 (PST)
Received: from redback.com (redwood.redback.com [155.53.44.120])
	by prattle.redback.com (Postfix) with ESMTP
	id C4724990C8D; Tue, 11 Nov 2003 19:25:56 -0800 (PST)
Message-ID: <3FB1A844.7FE0960D@redback.com>
Date: Tue, 11 Nov 2003 19:25:56 -0800
From: Albert Tian <tian@redback.com>
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.0.38 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Alex Zinin <zinin@psg.com>
Cc: MPLS wg <mpls@UU.NET>
Subject: Re: My comment on draft-chen-ldp-ttl
References: <5012035626.20031111112804@psg.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at redback.com
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi, Alex,

These are very good suggestions. We will add more text on making the hello more
secure as well as analyzing the risks of spoofed hellos.

Thanks,

Albert


Alex Zinin wrote:
> 
> A more elaborate version of the comment I made at the mic today:
> 
> The draft uses the LDP Hello message to negotiate enabling of the TTL
> check. Though the draft says that only Link Hellos (T=0) should be
> used for this, it does not say anything about securing those Hellos.
> Neither RFC3036 nor the draft _require_ the receiving LSR to drop Link
> Hellos that are sent to an address other than the AllRouters multicast
> (e.g. an LSR's unicast address). So if a spoofed Link Hello is
> accepted, the receiver may mistakenly apply the TTL check to a session
> with a peer that does not support it, and hence prevent it from coming
> up. Similarly, if a Hello without the new parameter is spoofed, the
> attacker may cause the LSR to disable the check and mount a
> overloading DoS attack against an existing session.
> 
> I would suggest that the draft is modified to recommend that Link
> Hellos (with or without the new optional parameter) MUST be sent to
> the unroutable AllRouters multicast address and MUST be dropped by the
> receiver if they are not. This should make the Link Hellos at least as
> secure as the session packets.
> 
> The Security Consideration section should also be extended to describe
> the potential Link Hello spoofing attack possible by an on-the-wire
> adversary, and then point out that given the current network
> operational practices, the risk of such exposure is considered to be
> sufficiently low.
> 
> --
> Alex


From owner-mpls@UU.NET  Wed Nov 12 11:37: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 LAA26053
	for <mpls-archive@lists.ietf.org>; Wed, 12 Nov 2003 11:37: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 QQpona11897
	for <mpls-archive@lists.ietf.org>; Wed, 12 Nov 2003 16:37: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 QQpona11639;
	Wed, 12 Nov 2003 16:37:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpomz28890
	for mpls-outgoing; Wed, 12 Nov 2003 16:19: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 QQpomz28883
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Nov 2003 16:18: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 QQpomz26393
	for <mpls@uu.net>; Wed, 12 Nov 2003 16:17: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 QQpomz29344
	for <mpls@uu.net>; Wed, 12 Nov 2003 16:17:00 GMT
Received: from sj-iport-3.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72])
	id QQpomz29314
	for <mpls@uu.net>; Wed, 12 Nov 2003 16:17:00 GMT
Received: from cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 12 Nov 2003 08:23:47 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hACGGtmU027284
	for <mpls@uu.net>; Wed, 12 Nov 2003 08:16:55 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADX80673;
	Wed, 12 Nov 2003 11:16:54 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hACGGsL00417 for mpls@uu.net; Wed, 12 Nov 2003 11:16: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 QQpomy28263
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Nov 2003 16:14: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 QQpomy28082
	for <mpls@uu.net>; Wed, 12 Nov 2003 16:14: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 QQpomy05816
	for <mpls@uu.net>; Wed, 12 Nov 2003 16:14:05 GMT
Received: from sj-iport-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72])
	id QQpomy05802
	for <mpls@uu.net>; Wed, 12 Nov 2003 16:14:04 GMT
Received: from cisco.com (171.71.177.237)
  by sj-iport-3.cisco.com with ESMTP; 12 Nov 2003 08:20:52 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hACGDxAt021303;
	Wed, 12 Nov 2003 08:14:00 -0800 (PST)
Received: from tnadeauw2k02 (che-vpn-cluster-1-102.cisco.com [10.86.240.102])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADX80355;
	Wed, 12 Nov 2003 11:13:58 -0500 (EST)
Reply-To: <tnadeau@cisco.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
To: "'Nurit Sprecher'" <nurit.sprecher@SeabridgeNetworks.com>,
        <cheenu@bloomberg.net>, <arunv@force10networks.com>
Cc: <mpls@UU.NET>, <ccamp@ops.ietf.org>
Subject: RE: MPLS Tunnel Maximum Hops
Date: Wed, 12 Nov 2003 10:13:44 -0600
Organization: Cisco Systems, inc.
Message-ID: <014b01c3a937$f5c4d9c0$6701a8c0@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
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <C87E5A01714C7840B92CDED9E79329CA0117D127@leopard.seabridge.co.il>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



>Any response to the bellow?

	The MIB is well past IETF last call, so
I don't believe we can make any further changes
at this time.

	--Tom



>Hi,
>I have a question  regarding the mplsTunnelMaxHops scalar that 
>indicates the
>maximum number of hops that can be specified on each tunnel 
>supported by the
>LSR.
>This scalar is a read only attribute but I can find it very 
>useful to let
>configure it as well. 
>One of the CSPF constraints is the maximum number of hops the 
>LSP may follow
>through. The limitation on the maximum number for example can 
>result from
>the maximum packet size when fragmentation is not supported. 
>In such a case
>the maximum number of hops can depend on the network nature
>(numbered/unnumbered). Instead of hard coding it with the 
>worst case number,
>let the network administrator, that is aware  of the network nature,
>configure it.
>Moreover, I think that the maximum hops should be configurable 
>per tunnel.
>Thanks, Nurit.
>
>




From owner-mpls@UU.NET  Wed Nov 12 11:55: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 LAA27231
	for <mpls-archive@lists.ietf.org>; Wed, 12 Nov 2003 11:55: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 QQponb20418
	for <mpls-archive@lists.ietf.org>; Wed, 12 Nov 2003 16:55: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 QQponb19926;
	Wed, 12 Nov 2003 16:55:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpona00630
	for mpls-outgoing; Wed, 12 Nov 2003 16:37: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 QQpona00623
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Nov 2003 16:37: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 QQpona01718
	for <mpls@uu.net>; Wed, 12 Nov 2003 16:36: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 QQpona23291
	for <mpls@uu.net>; Wed, 12 Nov 2003 16:36:35 GMT
Received: from imo-d01.mx.aol.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imo-d01.mx.aol.com [205.188.157.33])
	id QQpona23272
	for <mpls@uu.net>; Wed, 12 Nov 2003 16:36:34 GMT
Received: from NtscpUsrLoa@netscape.net
	by imo-d01.mx.aol.com (mail_out_v36_r1.1.) id c.7.b3a81d0 (16239);
	Wed, 12 Nov 2003 11:34:39 -0500 (EST)
Received: from  netscape.net (dyn068-239.ietf58.ietf.org [130.129.68.239]) by air-in03.mx.aol.com (v97.8) with ESMTP id MAILININ33-3f6f3fb26115c5; Wed, 12 Nov 2003 11:34:39 -0500
Message-ID: <3FB26113.80103@netscape.net>
Date: Wed, 12 Nov 2003 17:34:27 +0100
From: Loa Andersson <NtscpUsrLoa@netscape.net>
Reply-To: loa@pi.se
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: tnadeau@cisco.com
CC: "'Nurit Sprecher'" <nurit.sprecher@SeabridgeNetworks.com>,
        cheenu@bloomberg.net, arunv@force10networks.com, mpls@UU.NET,
        ccamp@ops.ietf.org
Subject: Re: MPLS Tunnel Maximum Hops
References: <014b01c3a937$f5c4d9c0$6701a8c0@amer.cisco.com>
In-Reply-To: <014b01c3a937$f5c4d9c0$6701a8c0@amer.cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-AOL-IP: 130.129.68.239
X-Mailer: Unknown (No Version)
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Tom,

while I agree that we don't want any changes just now.
It would also be good to understand if this is a good idea
or not. If not we could discard it now, if it is would could
make a log for future updates. Any opinion?

/Loa

Thomas D. Nadeau wrote:

>  
>
>>Any response to the bellow?
>>    
>>
>
>   The MIB is well past IETF last call, so
>I don't believe we can make any further changes
>at this time.
>
>   --Tom
>
>
>
>  
>
>>Hi,
>>I have a question  regarding the mplsTunnelMaxHops scalar that 
>>indicates the
>>maximum number of hops that can be specified on each tunnel 
>>supported by the
>>LSR.
>>This scalar is a read only attribute but I can find it very 
>>useful to let
>>configure it as well. 
>>One of the CSPF constraints is the maximum number of hops the 
>>LSP may follow
>>through. The limitation on the maximum number for example can 
>>result from
>>the maximum packet size when fragmentation is not supported. 
>>In such a case
>>the maximum number of hops can depend on the network nature
>>(numbered/unnumbered). Instead of hard coding it with the 
>>worst case number,
>>let the network administrator, that is aware  of the network nature,
>>configure it.
>>Moreover, I think that the maximum hops should be configurable 
>>per tunnel.
>>Thanks, Nurit.
>>
>>
>>    
>>
>
>
>
>
>  
>



From owner-mpls@UU.NET  Wed Nov 12 12:10: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 MAA28078
	for <mpls-archive@lists.ietf.org>; Wed, 12 Nov 2003 12:10:09 -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 QQponc13605
	for <mpls-archive@lists.ietf.org>; Wed, 12 Nov 2003 17:10: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 QQponc13260;
	Wed, 12 Nov 2003 17:10:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQponb02261
	for mpls-outgoing; Wed, 12 Nov 2003 16:51: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 QQponb02241
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Nov 2003 16:50: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 QQponb09174
	for <mpls@uu.net>; Wed, 12 Nov 2003 16:48: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 QQponb11457
	for <mpls@uu.net>; Wed, 12 Nov 2003 16:48:55 GMT
Received: from tiger.seabridge.co.il by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [212.25.127.226])
	id QQponb11357
	for <mpls@uu.net>; Wed, 12 Nov 2003 16:48:51 GMT
Received: by tiger.seabridge.co.il with Internet Mail Service (5.5.2653.19)
	id <V1ZD178H>; Wed, 12 Nov 2003 18:25:16 +0200
Message-ID: <C87E5A01714C7840B92CDED9E79329CA0117D131@leopard.seabridge.co.il>
From: Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>
To: "'tnadeau@cisco.com'" <tnadeau@cisco.com>,
        Nurit Sprecher
	 <nurit.sprecher@SeabridgeNetworks.com>,
        cheenu@bloomberg.net, arunv@force10networks.com
Cc: mpls@UU.NET, ccamp@ops.ietf.org
Subject: RE: MPLS Tunnel Maximum Hops
Date: Wed, 12 Nov 2003 18:25:15 +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 Tom for responding me.
I understand that this is in a last call state, but this issue should be
addressed somehow? 
I am surprised that such an attribute that is provided to the CSPF algorithm
is not configurable. How can you determine its value? Hard-coded? Doesn't it
have to do with network topology?
I think it should be configurable and we should see how we could add it to
the draft.
Nurit.

-----Original Message-----
From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
Sent: Wednesday, November 12, 2003 18:14
To: 'Nurit Sprecher'; cheenu@bloomberg.net; arunv@force10networks.com
Cc: mpls@uu.net; ccamp@ops.ietf.org
Subject: RE: MPLS Tunnel Maximum Hops


>Any response to the bellow?

        The MIB is well past IETF last call, so
I don't believe we can make any further changes
at this time.

        --Tom



>Hi,
>I have a question  regarding the mplsTunnelMaxHops scalar that
>indicates the
>maximum number of hops that can be specified on each tunnel
>supported by the
>LSR.
>This scalar is a read only attribute but I can find it very
>useful to let
>configure it as well.
>One of the CSPF constraints is the maximum number of hops the
>LSP may follow
>through. The limitation on the maximum number for example can
>result from
>the maximum packet size when fragmentation is not supported.
>In such a case
>the maximum number of hops can depend on the network nature
>(numbered/unnumbered). Instead of hard coding it with the
>worst case number,
>let the network administrator, that is aware  of the network nature,
>configure it.
>Moreover, I think that the maximum hops should be configurable
>per tunnel.
>Thanks, Nurit.
>
>


From owner-mpls@UU.NET  Wed Nov 12 12:50: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 MAA29698
	for <mpls-archive@lists.ietf.org>; Wed, 12 Nov 2003 12:50: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 QQponf02417
	for <mpls-archive@lists.ietf.org>; Wed, 12 Nov 2003 17:51: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 QQponf01833;
	Wed, 12 Nov 2003 17:50:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpone24912
	for mpls-outgoing; Wed, 12 Nov 2003 17:31: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 QQpone24907
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Nov 2003 17:31: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 QQpond03024
	for <mpls@UU.NET>; Wed, 12 Nov 2003 17:27: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 QQpond20810
	for <mpls@UU.NET>; Wed, 12 Nov 2003 17:27:45 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 QQpond20799
	for <mpls@UU.NET>; Wed, 12 Nov 2003 17:27:44 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hACHQYX12961;
	Wed, 12 Nov 2003 12:26:34 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <W3H873M3>; Wed, 12 Nov 2003 12:26:35 -0500
Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E608408596@zcard0ke.ca.nortel.com>
From: "Don Fedyk" <dwfedyk@nortelnetworks.com>
To: loa@pi.se, tnadeau@cisco.com
Cc: "'Nurit Sprecher'" <nurit.sprecher@SeabridgeNetworks.com>,
        cheenu@bloomberg.net, arunv@force10networks.com, mpls@UU.NET,
        ccamp@ops.ietf.org
Subject: RE: MPLS Tunnel Maximum Hops
Date: Wed, 12 Nov 2003 12:26:34 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-mpls@UU.NET
Precedence: bulk

Loa

Limiting hops is a good idea IMHO and probably should be in the MIB down the
road. 

Don


> -----Original Message-----
> From: Loa Andersson [mailto:NtscpUsrLoa@netscape.net] 
> Sent: Wednesday, November 12, 2003 11:34 AM
> To: tnadeau@cisco.com
> Cc: 'Nurit Sprecher'; cheenu@bloomberg.net; 
> arunv@force10networks.com; mpls@UU.NET; ccamp@ops.ietf.org
> Subject: Re: MPLS Tunnel Maximum Hops
> 
> 
> Tom,
> 
> while I agree that we don't want any changes just now.
> It would also be good to understand if this is a good idea
> or not. If not we could discard it now, if it is would could 
> make a log for future updates. Any opinion?
> 
> /Loa


From owner-mpls@UU.NET  Wed Nov 12 12: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 MAA29802
	for <mpls-archive@lists.ietf.org>; Wed, 12 Nov 2003 12: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 QQponf05097
	for <mpls-archive@lists.ietf.org>; Wed, 12 Nov 2003 17:52: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 QQponf04860;
	Wed, 12 Nov 2003 17:52:46 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpone25011
	for mpls-outgoing; Wed, 12 Nov 2003 17:34: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 QQpone25001
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Nov 2003 17:34: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 QQpone12365
	for <mpls@uu.net>; Wed, 12 Nov 2003 17:33:17 GMT
From: jcucchiara@mindspring.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 QQpone09822
	for <mpls@uu.net>; Wed, 12 Nov 2003 17:33:17 GMT
Received: from hall.mail.mindspring.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hall.mail.mindspring.net [207.69.200.60])
	id QQpone09811
	for <mpls@uu.net>; Wed, 12 Nov 2003 17:33:16 GMT
Received: from [192.168.167.40] (helo=wamui02.slb.atl.earthlink.net)
	by hall.mail.mindspring.net with esmtp (Exim 3.33 #1)
	id 1AJyqV-0006oV-00; Wed, 12 Nov 2003 12:31:59 -0500
Message-ID: <21014584.1068658318844.JavaMail.root@wamui02.slb.atl.earthlink.net>
Date: Wed, 12 Nov 2003 12:31:52 -0500 (GMT-05:00)
Reply-To: jcucchiara@mindspring.com
To: Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>,
        "'tnadeau@cisco.com'" <tnadeau@cisco.com>,
        Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>,
        cheenu@bloomberg.net, arunv@force10networks.com
Subject: RE: MPLS Tunnel Maximum Hops
Cc: mpls@UU.NET, ccamp@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Earthlink Zoo Mail 1.0
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hi Nurit,

I can understand you wanting this change, but that is why
we had working group last calls in June and an IETF last
call in Aug/Sep.  That is the opportunity for
folks to give their comments,  knowing that the MIB can only
have minor edits after that.   

The most minimal way I see to make this change (and this is
just my opinion) is:

* change the mplsTunnelMaxHops object to read-write
* agree upon a DEFVAL (default value upon startup, which can
   be set to a different value by an operator)
* add to the conformance statement that this may be supported
   as a read-only

So, in addition to making the object read-write, think it needs a 
DEFVAL, and this would need to be discussed and agreed upon by
the working group.   This is more than minor editing in my opinion.
I am in agreement with Loa and Tom and would like to see
the MIBs move forward.

  -Thanks, 
    -Joan

-----Original Message-----
From: Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>
Sent: Nov 12, 2003 11:25 AM
To: "'tnadeau@cisco.com'" <tnadeau@cisco.com>, 
	Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>, 
	cheenu@bloomberg.net, arunv@force10networks.com
Cc: mpls@UU.NET, ccamp@ops.ietf.org
Subject: RE: MPLS Tunnel Maximum Hops

Thanks Tom for responding me.
I understand that this is in a last call state, but this issue should be
addressed somehow? 
I am surprised that such an attribute that is provided to the CSPF algorithm
is not configurable. How can you determine its value? Hard-coded? Doesn't it
have to do with network topology?
I think it should be configurable and we should see how we could add it to
the draft.
Nurit.

-----Original Message-----
From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
Sent: Wednesday, November 12, 2003 18:14
To: 'Nurit Sprecher'; cheenu@bloomberg.net; arunv@force10networks.com
Cc: mpls@uu.net; ccamp@ops.ietf.org
Subject: RE: MPLS Tunnel Maximum Hops


>Any response to the bellow?

        The MIB is well past IETF last call, so
I don't believe we can make any further changes
at this time.

        --Tom



>Hi,
>I have a question  regarding the mplsTunnelMaxHops scalar that
>indicates the
>maximum number of hops that can be specified on each tunnel
>supported by the
>LSR.
>This scalar is a read only attribute but I can find it very
>useful to let
>configure it as well.
>One of the CSPF constraints is the maximum number of hops the
>LSP may follow
>through. The limitation on the maximum number for example can
>result from
>the maximum packet size when fragmentation is not supported.
>In such a case
>the maximum number of hops can depend on the network nature
>(numbered/unnumbered). Instead of hard coding it with the
>worst case number,
>let the network administrator, that is aware  of the network nature,
>configure it.
>Moreover, I think that the maximum hops should be configurable
>per tunnel.
>Thanks, Nurit.
>
>





From owner-mpls@UU.NET  Wed Nov 12 15:13: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 PAA06165
	for <mpls-archive@lists.ietf.org>; Wed, 12 Nov 2003 15:13: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 QQpono00581
	for <mpls-archive@lists.ietf.org>; Wed, 12 Nov 2003 20:13: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 QQpono00375;
	Wed, 12 Nov 2003 20:13:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQponn14323
	for mpls-outgoing; Wed, 12 Nov 2003 19:53:47 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 QQponn14318
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Nov 2003 19:53: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 QQponn05167
	for <mpls@UU.NET>; Wed, 12 Nov 2003 19:52: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 QQponn00458
	for <mpls@UU.NET>; Wed, 12 Nov 2003 19:52:27 GMT
Received: from tiger.seabridge.co.il by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [212.25.127.226])
	id QQponn00417
	for <mpls@UU.NET>; Wed, 12 Nov 2003 19:52:25 GMT
Received: by tiger.seabridge.co.il with Internet Mail Service (5.5.2653.19)
	id <V1ZD18RH>; Wed, 12 Nov 2003 21:52:41 +0200
Message-ID: <C87E5A01714C7840B92CDED9E79329CA0117D137@leopard.seabridge.co.il>
From: Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>
To: "'jcucchiara@mindspring.com'" <jcucchiara@mindspring.com>,
        Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>,
        "'tnadeau@cisco.com'" <tnadeau@cisco.com>, cheenu@bloomberg.net,
        arunv@force10networks.com
Cc: mpls@UU.NET, ccamp@ops.ietf.org
Subject: RE: MPLS Tunnel Maximum Hops
Date: Wed, 12 Nov 2003 21:52:40 +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 Joan,
Thanks for the response.
1. What is the procedure to push it to the standard right now when the draft
is in a last call?
2. Do you agree that this should be configurable? Otherwise how can you
determine on the value?
3. Do you agree that it may be required also to configure it per tunnel (but
have a default value)? 
Until now I have just got e-mails on the procedure but not on the idea
itself.
I'll appreciate your response, Nurit.


-----Original Message-----
From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com]
Sent: Wednesday, November 12, 2003 19:32
To: Nurit Sprecher; 'tnadeau@cisco.com'; Nurit Sprecher;
cheenu@bloomberg.net; arunv@force10networks.com
Cc: mpls@UU.NET; ccamp@ops.ietf.org
Subject: RE: MPLS Tunnel Maximum Hops


Hi Nurit,

I can understand you wanting this change, but that is why
we had working group last calls in June and an IETF last
call in Aug/Sep.  That is the opportunity for
folks to give their comments,  knowing that the MIB can only
have minor edits after that.  

The most minimal way I see to make this change (and this is
just my opinion) is:

* change the mplsTunnelMaxHops object to read-write
* agree upon a DEFVAL (default value upon startup, which can
   be set to a different value by an operator)
* add to the conformance statement that this may be supported
   as a read-only

So, in addition to making the object read-write, think it needs a
DEFVAL, and this would need to be discussed and agreed upon by
the working group.   This is more than minor editing in my opinion.
I am in agreement with Loa and Tom and would like to see
the MIBs move forward.

  -Thanks,
    -Joan

-----Original Message-----
From: Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>
Sent: Nov 12, 2003 11:25 AM
To: "'tnadeau@cisco.com'" <tnadeau@cisco.com>,
        Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>,
        cheenu@bloomberg.net, arunv@force10networks.com
Cc: mpls@UU.NET, ccamp@ops.ietf.org
Subject: RE: MPLS Tunnel Maximum Hops

Thanks Tom for responding me.
I understand that this is in a last call state, but this issue should be
addressed somehow?
I am surprised that such an attribute that is provided to the CSPF algorithm
is not configurable. How can you determine its value? Hard-coded? Doesn't it
have to do with network topology?
I think it should be configurable and we should see how we could add it to
the draft.
Nurit.

-----Original Message-----
From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
Sent: Wednesday, November 12, 2003 18:14
To: 'Nurit Sprecher'; cheenu@bloomberg.net; arunv@force10networks.com
Cc: mpls@uu.net; ccamp@ops.ietf.org
Subject: RE: MPLS Tunnel Maximum Hops


>Any response to the bellow?

        The MIB is well past IETF last call, so
I don't believe we can make any further changes
at this time.

        --Tom



>Hi,
>I have a question  regarding the mplsTunnelMaxHops scalar that
>indicates the
>maximum number of hops that can be specified on each tunnel
>supported by the
>LSR.
>This scalar is a read only attribute but I can find it very
>useful to let
>configure it as well.
>One of the CSPF constraints is the maximum number of hops the
>LSP may follow
>through. The limitation on the maximum number for example can
>result from
>the maximum packet size when fragmentation is not supported.
>In such a case
>the maximum number of hops can depend on the network nature
>(numbered/unnumbered). Instead of hard coding it with the
>worst case number,
>let the network administrator, that is aware  of the network nature,
>configure it.
>Moreover, I think that the maximum hops should be configurable
>per tunnel.
>Thanks, Nurit.
>
>



From owner-mpls@UU.NET  Wed Nov 12 15:29: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 PAA07567
	for <mpls-archive@lists.ietf.org>; Wed, 12 Nov 2003 15:29: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 QQponp26781
	for <mpls-archive@lists.ietf.org>; Wed, 12 Nov 2003 20:29: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 QQponp26422;
	Wed, 12 Nov 2003 20:29:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpono04936
	for mpls-outgoing; Wed, 12 Nov 2003 20:14: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 QQpono04923
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Nov 2003 20:14: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 QQpono01621
	for <mpls@uu.net>; Wed, 12 Nov 2003 20:13: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 QQpono21295
	for <mpls@uu.net>; Wed, 12 Nov 2003 20:13:15 GMT
Received: from imo-d01.mx.aol.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imo-d01.mx.aol.com [205.188.157.33])
	id QQpono21288
	for <mpls@uu.net>; Wed, 12 Nov 2003 20:13:15 GMT
Received: from NtscpUsrLoa@netscape.net
	by imo-d01.mx.aol.com (mail_out_v36_r1.1.) id i.2c.b444638 (22681);
	Wed, 12 Nov 2003 15:12:17 -0500 (EST)
Received: from  netscape.net (tla-loa.ietf58.ietf.org [130.129.131.229]) by air-in04.mx.aol.com (v97.8) with ESMTP id MAILININ42-58993fb2941b387; Wed, 12 Nov 2003 15:12:15 -0500
Message-ID: <3FB29419.3050305@netscape.net>
Date: Wed, 12 Nov 2003 21:12:09 +0100
From: Loa Andersson <NtscpUsrLoa@netscape.net>
Reply-To: loa@pi.se
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>
CC: "'jcucchiara@mindspring.com'" <jcucchiara@mindspring.com>,
        "'tnadeau@cisco.com'" <tnadeau@cisco.com>, cheenu@bloomberg.net,
        arunv@force10networks.com, mpls@UU.NET, ccamp@ops.ietf.org
Subject: Re: MPLS Tunnel Maximum Hops
References: <C87E5A01714C7840B92CDED9E79329CA0117D137@leopard.seabridge.co.il>
In-Reply-To: <C87E5A01714C7840B92CDED9E79329CA0117D137@leopard.seabridge.co.il>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AOL-IP: 130.129.131.229
X-Mailer: Unknown (No Version)
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Nurit,

with my wg chair hat on :) - the way to push things to
standard  now is to write down the proposal in an ID
and have the wg to discuss it.

"Now" is a point in time when the other option - commenting
on a draft and have editors/authors change the ID, because
we have a set of mib modules in review and we don't want to
delay this review longer than necessary. To have the documents
out represents much more "good", than an update that would
respin the doc back into wg last call, especially since the
documents in review is heavily dependent on each other.

/Loa

Nurit Sprecher wrote:

>Hi Joan,
>Thanks for the response.
>1. What is the procedure to push it to the standard right now when the draft
>is in a last call?
>2. Do you agree that this should be configurable? Otherwise how can you
>determine on the value?
>3. Do you agree that it may be required also to configure it per tunnel (but
>have a default value)? 
>Until now I have just got e-mails on the procedure but not on the idea
>itself.
>I'll appreciate your response, Nurit.
>
>
>-----Original Message-----
>From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com]
>Sent: Wednesday, November 12, 2003 19:32
>To: Nurit Sprecher; 'tnadeau@cisco.com'; Nurit Sprecher;
>cheenu@bloomberg.net; arunv@force10networks.com
>Cc: mpls@UU.NET; ccamp@ops.ietf.org
>Subject: RE: MPLS Tunnel Maximum Hops
>
>
>Hi Nurit,
>
>I can understand you wanting this change, but that is why
>we had working group last calls in June and an IETF last
>call in Aug/Sep.  That is the opportunity for
>folks to give their comments,  knowing that the MIB can only
>have minor edits after that.  
>
>The most minimal way I see to make this change (and this is
>just my opinion) is:
>
>* change the mplsTunnelMaxHops object to read-write
>* agree upon a DEFVAL (default value upon startup, which can
>   be set to a different value by an operator)
>* add to the conformance statement that this may be supported
>   as a read-only
>
>So, in addition to making the object read-write, think it needs a
>DEFVAL, and this would need to be discussed and agreed upon by
>the working group.   This is more than minor editing in my opinion.
>I am in agreement with Loa and Tom and would like to see
>the MIBs move forward.
>
>  -Thanks,
>    -Joan
>
>-----Original Message-----
>From: Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>
>Sent: Nov 12, 2003 11:25 AM
>To: "'tnadeau@cisco.com'" <tnadeau@cisco.com>,
>        Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>,
>        cheenu@bloomberg.net, arunv@force10networks.com
>Cc: mpls@UU.NET, ccamp@ops.ietf.org
>Subject: RE: MPLS Tunnel Maximum Hops
>
>Thanks Tom for responding me.
>I understand that this is in a last call state, but this issue should be
>addressed somehow?
>I am surprised that such an attribute that is provided to the CSPF algorithm
>is not configurable. How can you determine its value? Hard-coded? Doesn't it
>have to do with network topology?
>I think it should be configurable and we should see how we could add it to
>the draft.
>Nurit.
>
>-----Original Message-----
>From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
>Sent: Wednesday, November 12, 2003 18:14
>To: 'Nurit Sprecher'; cheenu@bloomberg.net; arunv@force10networks.com
>Cc: mpls@uu.net; ccamp@ops.ietf.org
>Subject: RE: MPLS Tunnel Maximum Hops
>
>
>  
>
>>Any response to the bellow?
>>    
>>
>
>        The MIB is well past IETF last call, so
>I don't believe we can make any further changes
>at this time.
>
>        --Tom
>
>
>
>  
>
>>Hi,
>>I have a question  regarding the mplsTunnelMaxHops scalar that
>>indicates the
>>maximum number of hops that can be specified on each tunnel
>>supported by the
>>LSR.
>>This scalar is a read only attribute but I can find it very
>>useful to let
>>configure it as well.
>>One of the CSPF constraints is the maximum number of hops the
>>LSP may follow
>>through. The limitation on the maximum number for example can
>>result from
>>the maximum packet size when fragmentation is not supported.
>>In such a case
>>the maximum number of hops can depend on the network nature
>>(numbered/unnumbered). Instead of hard coding it with the
>>worst case number,
>>let the network administrator, that is aware  of the network nature,
>>configure it.
>>Moreover, I think that the maximum hops should be configurable
>>per tunnel.
>>Thanks, Nurit.
>>
>>
>>    
>>
>
>
>
>
>  
>



From owner-mpls@UU.NET  Wed Nov 12 17:20: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 RAA12992
	for <mpls-archive@lists.ietf.org>; Wed, 12 Nov 2003 17:20: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 QQponx07244
	for <mpls-archive@lists.ietf.org>; Wed, 12 Nov 2003 22:20: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 QQponx07109;
	Wed, 12 Nov 2003 22:20:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQponv02777
	for mpls-outgoing; Wed, 12 Nov 2003 21:55:39 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 QQponv02769
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Nov 2003 21:55:25 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 QQponv05902
	for <mpls@UU.NET>; Wed, 12 Nov 2003 21:52: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 QQponv27285
	for <mpls@UU.NET>; Wed, 12 Nov 2003 21:52:56 GMT
Received: from relay0.netfirms.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: m0.netfirms.com [209.171.43.51])
	id QQponv27256
	for <mpls@UU.NET>; Wed, 12 Nov 2003 21:52:54 GMT
Received: (qmail 74397 invoked from network); 12 Nov 2003 21:52:51 -0000
Received: from dyn132-211.ietf58.ietf.org (HELO Puppy) (130.129.132.211)
  by 0 with SMTP; 12 Nov 2003 21:52:51 -0000
Message-ID: <00e201c3a967$5413b850$d3848182@Puppy>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Nurit Sprecher" <nurit.sprecher@SeabridgeNetworks.com>,
        <jcucchiara@mindspring.com>, <tnadeau@cisco.com>,
        <cheenu@bloomberg.net>, <arunv@force10networks.com>
Cc: <mpls@UU.NET>, <ccamp@ops.ietf.org>
References: <C87E5A01714C7840B92CDED9E79329CA0117D137@leopard.seabridge.co.il>
Subject: Re: MPLS Tunnel Maximum Hops
Date: Wed, 12 Nov 2003 21:51:55 -0000
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.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

I am unclear why this object should be writeable.

As you imply, it is either something that you wish to control for each individual CSPF
calculation (in which case it is a per tunnel instance configuration parameter) or it is a
quality of the entire LSR and is applied to all LSPs.

The current object was intended to reflect the capabilities of the LSR, not an operational
requirement. Thus it cannot be changed by the operator.

It would be a different thing if you want to change the LSR's CSPF behavior (compared with
stating the LSR's capabilities).

So *if* this was to advance I would say that it should either be:
- a per tunnel instance object
- a configuration parameter for CSPF.
Personally, I do not see the requirement for the former, and the latter is clearly out of
scope of the MPLS MIB modules.

Note that there is an edge condition where you need to limit the size of ERO on some
interfaces but not on others. In my view, this is a property of the interface which should
be reported to CSPF direct, and not configured through the MPLS MIBs.

Cheers,
Adrian

----- Original Message ----- 
From: "Nurit Sprecher" <nurit.sprecher@SeabridgeNetworks.com>
To: <jcucchiara@mindspring.com>; "Nurit Sprecher" <nurit.sprecher@SeabridgeNetworks.com>;
<tnadeau@cisco.com>; <cheenu@bloomberg.net>; <arunv@force10networks.com>
Cc: <mpls@UU.NET>; <ccamp@ops.ietf.org>
Sent: Wednesday, November 12, 2003 7:52 PM
Subject: RE: MPLS Tunnel Maximum Hops


> Hi Joan,
> Thanks for the response.
> 1. What is the procedure to push it to the standard right now when the draft
> is in a last call?
> 2. Do you agree that this should be configurable? Otherwise how can you
> determine on the value?
> 3. Do you agree that it may be required also to configure it per tunnel (but
> have a default value)?
> Until now I have just got e-mails on the procedure but not on the idea
> itself.
> I'll appreciate your response, Nurit.
>
>
> -----Original Message-----
> From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com]
> Sent: Wednesday, November 12, 2003 19:32
> To: Nurit Sprecher; 'tnadeau@cisco.com'; Nurit Sprecher;
> cheenu@bloomberg.net; arunv@force10networks.com
> Cc: mpls@UU.NET; ccamp@ops.ietf.org
> Subject: RE: MPLS Tunnel Maximum Hops
>
>
> Hi Nurit,
>
> I can understand you wanting this change, but that is why
> we had working group last calls in June and an IETF last
> call in Aug/Sep.  That is the opportunity for
> folks to give their comments,  knowing that the MIB can only
> have minor edits after that.
>
> The most minimal way I see to make this change (and this is
> just my opinion) is:
>
> * change the mplsTunnelMaxHops object to read-write
> * agree upon a DEFVAL (default value upon startup, which can
>    be set to a different value by an operator)
> * add to the conformance statement that this may be supported
>    as a read-only
>
> So, in addition to making the object read-write, think it needs a
> DEFVAL, and this would need to be discussed and agreed upon by
> the working group.   This is more than minor editing in my opinion.
> I am in agreement with Loa and Tom and would like to see
> the MIBs move forward.
>
>   -Thanks,
>     -Joan
>
> -----Original Message-----
> From: Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>
> Sent: Nov 12, 2003 11:25 AM
> To: "'tnadeau@cisco.com'" <tnadeau@cisco.com>,
>         Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>,
>         cheenu@bloomberg.net, arunv@force10networks.com
> Cc: mpls@UU.NET, ccamp@ops.ietf.org
> Subject: RE: MPLS Tunnel Maximum Hops
>
> Thanks Tom for responding me.
> I understand that this is in a last call state, but this issue should be
> addressed somehow?
> I am surprised that such an attribute that is provided to the CSPF algorithm
> is not configurable. How can you determine its value? Hard-coded? Doesn't it
> have to do with network topology?
> I think it should be configurable and we should see how we could add it to
> the draft.
> Nurit.
>
> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: Wednesday, November 12, 2003 18:14
> To: 'Nurit Sprecher'; cheenu@bloomberg.net; arunv@force10networks.com
> Cc: mpls@uu.net; ccamp@ops.ietf.org
> Subject: RE: MPLS Tunnel Maximum Hops
>
>
> >Any response to the bellow?
>
>         The MIB is well past IETF last call, so
> I don't believe we can make any further changes
> at this time.
>
>         --Tom
>
>
>
> >Hi,
> >I have a question  regarding the mplsTunnelMaxHops scalar that
> >indicates the
> >maximum number of hops that can be specified on each tunnel
> >supported by the
> >LSR.
> >This scalar is a read only attribute but I can find it very
> >useful to let
> >configure it as well.
> >One of the CSPF constraints is the maximum number of hops the
> >LSP may follow
> >through. The limitation on the maximum number for example can
> >result from
> >the maximum packet size when fragmentation is not supported.
> >In such a case
> >the maximum number of hops can depend on the network nature
> >(numbered/unnumbered). Instead of hard coding it with the
> >worst case number,
> >let the network administrator, that is aware  of the network nature,
> >configure it.
> >Moreover, I think that the maximum hops should be configurable
> >per tunnel.
> >Thanks, Nurit.
> >
> >
>
>



From owner-mpls@UU.NET  Wed Nov 12 18:36: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 SAA17282
	for <mpls-archive@lists.ietf.org>; Wed, 12 Nov 2003 18:36: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 QQpooc03833
	for <mpls-archive@lists.ietf.org>; Wed, 12 Nov 2003 23:37: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 QQpooc02475;
	Wed, 12 Nov 2003 23:36:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoob17930
	for mpls-outgoing; Wed, 12 Nov 2003 23:16: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 QQpoob17923
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Nov 2003 23:16:08 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 QQpoob14870
	for <mpls@uu.net>; Wed, 12 Nov 2003 23:15: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 QQpoob00978
	for <mpls@uu.net>; Wed, 12 Nov 2003 23:15:23 GMT
Received: from sj-iport-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71])
	id QQpoob00949
	for <mpls@uu.net>; Wed, 12 Nov 2003 23:15:22 GMT
Received: from cisco.com (171.71.177.254)
  by sj-iport-2.cisco.com with ESMTP; 12 Nov 2003 15:17:25 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hACNF7w5008119
	for <mpls@uu.net>; Wed, 12 Nov 2003 15:15:07 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADY23908;
	Wed, 12 Nov 2003 18:15:06 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hACNF6q10422 for mpls@uu.net; Wed, 12 Nov 2003 18: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 QQpooa17157
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Nov 2003 23:13: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 QQpooa10554
	for <mpls@uu.net>; Wed, 12 Nov 2003 23:11: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 QQpooa22023
	for <mpls@uu.net>; Wed, 12 Nov 2003 23:11:52 GMT
Received: from sj-iport-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71])
	id QQpooa22001
	for <mpls@uu.net>; Wed, 12 Nov 2003 23:11:51 GMT
Received: from cisco.com (171.71.177.238)
  by sj-iport-2.cisco.com with ESMTP; 12 Nov 2003 15:14:05 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hACNBkmU001202;
	Wed, 12 Nov 2003 15:11:47 -0800 (PST)
Received: from tnadeauw2k02 (che-vpn-cluster-1-65.cisco.com [10.86.240.65])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADY23675;
	Wed, 12 Nov 2003 18:11:45 -0500 (EST)
Reply-To: <tnadeau@cisco.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
To: "'Adrian Farrel'" <adrian@olddog.co.uk>,
        "'Nurit Sprecher'" <nurit.sprecher@SeabridgeNetworks.com>,
        <jcucchiara@mindspring.com>, <cheenu@bloomberg.net>,
        <arunv@force10networks.com>
Cc: <mpls@UU.NET>, <ccamp@ops.ietf.org>
Subject: RE: MPLS Tunnel Maximum Hops
Date: Wed, 12 Nov 2003 17:11:31 -0600
Organization: Cisco Systems, inc.
Message-ID: <008e01c3a972$557988e0$6701a8c0@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
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <00e201c3a967$5413b850$d3848182@Puppy>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


>I am unclear why this object should be writeable.

	I agree.

>As you imply, it is either something that you wish to control 
>for each individual CSPF
>calculation (in which case it is a per tunnel instance 
>configuration parameter) or it is a
>quality of the entire LSR and is applied to all LSPs.
>
>The current object was intended to reflect the capabilities of 
>the LSR, not an operational
>requirement. Thus it cannot be changed by the operator.
>
>It would be a different thing if you want to change the LSR's 
>CSPF behavior (compared with
>stating the LSR's capabilities).
>
>So *if* this was to advance I would say that it should either be:
>- a per tunnel instance object
>- a configuration parameter for CSPF.
>Personally, I do not see the requirement for the former, and 
>the latter is clearly out of
>scope of the MPLS MIB modules.
>
>Note that there is an edge condition where you need to limit 
>the size of ERO on some
>interfaces but not on others. In my view, this is a property 
>of the interface which should
>be reported to CSPF direct, and not configured through the MPLS MIBs.
	
	I agree. The only possible option would be to add
another object to reflect the configured value.

	--Tom


>
>Cheers,
>Adrian
>
>----- Original Message ----- 
>From: "Nurit Sprecher" <nurit.sprecher@SeabridgeNetworks.com>
>To: <jcucchiara@mindspring.com>; "Nurit Sprecher" 
><nurit.sprecher@SeabridgeNetworks.com>;
><tnadeau@cisco.com>; <cheenu@bloomberg.net>; 
><arunv@force10networks.com>
>Cc: <mpls@UU.NET>; <ccamp@ops.ietf.org>
>Sent: Wednesday, November 12, 2003 7:52 PM
>Subject: RE: MPLS Tunnel Maximum Hops
>
>
>> Hi Joan,
>> Thanks for the response.
>> 1. What is the procedure to push it to the standard right 
>now when the draft
>> is in a last call?
>> 2. Do you agree that this should be configurable? Otherwise 
>how can you
>> determine on the value?
>> 3. Do you agree that it may be required also to configure it 
>per tunnel (but
>> have a default value)?
>> Until now I have just got e-mails on the procedure but not 
>on the idea
>> itself.
>> I'll appreciate your response, Nurit.
>>
>>
>> -----Original Message-----
>> From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com]
>> Sent: Wednesday, November 12, 2003 19:32
>> To: Nurit Sprecher; 'tnadeau@cisco.com'; Nurit Sprecher;
>> cheenu@bloomberg.net; arunv@force10networks.com
>> Cc: mpls@UU.NET; ccamp@ops.ietf.org
>> Subject: RE: MPLS Tunnel Maximum Hops
>>
>>
>> Hi Nurit,
>>
>> I can understand you wanting this change, but that is why
>> we had working group last calls in June and an IETF last
>> call in Aug/Sep.  That is the opportunity for
>> folks to give their comments,  knowing that the MIB can only
>> have minor edits after that.
>>
>> The most minimal way I see to make this change (and this is
>> just my opinion) is:
>>
>> * change the mplsTunnelMaxHops object to read-write
>> * agree upon a DEFVAL (default value upon startup, which can
>>    be set to a different value by an operator)
>> * add to the conformance statement that this may be supported
>>    as a read-only
>>
>> So, in addition to making the object read-write, think it needs a
>> DEFVAL, and this would need to be discussed and agreed upon by
>> the working group.   This is more than minor editing in my opinion.
>> I am in agreement with Loa and Tom and would like to see
>> the MIBs move forward.
>>
>>   -Thanks,
>>     -Joan
>>
>> -----Original Message-----
>> From: Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>
>> Sent: Nov 12, 2003 11:25 AM
>> To: "'tnadeau@cisco.com'" <tnadeau@cisco.com>,
>>         Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>,
>>         cheenu@bloomberg.net, arunv@force10networks.com
>> Cc: mpls@UU.NET, ccamp@ops.ietf.org
>> Subject: RE: MPLS Tunnel Maximum Hops
>>
>> Thanks Tom for responding me.
>> I understand that this is in a last call state, but this 
>issue should be
>> addressed somehow?
>> I am surprised that such an attribute that is provided to 
>the CSPF algorithm
>> is not configurable. How can you determine its value? 
>Hard-coded? Doesn't it
>> have to do with network topology?
>> I think it should be configurable and we should see how we 
>could add it to
>> the draft.
>> Nurit.
>>
>> -----Original Message-----
>> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
>> Sent: Wednesday, November 12, 2003 18:14
>> To: 'Nurit Sprecher'; cheenu@bloomberg.net; arunv@force10networks.com
>> Cc: mpls@uu.net; ccamp@ops.ietf.org
>> Subject: RE: MPLS Tunnel Maximum Hops
>>
>>
>> >Any response to the bellow?
>>
>>         The MIB is well past IETF last call, so
>> I don't believe we can make any further changes
>> at this time.
>>
>>         --Tom
>>
>>
>>
>> >Hi,
>> >I have a question  regarding the mplsTunnelMaxHops scalar that
>> >indicates the
>> >maximum number of hops that can be specified on each tunnel
>> >supported by the
>> >LSR.
>> >This scalar is a read only attribute but I can find it very
>> >useful to let
>> >configure it as well.
>> >One of the CSPF constraints is the maximum number of hops the
>> >LSP may follow
>> >through. The limitation on the maximum number for example can
>> >result from
>> >the maximum packet size when fragmentation is not supported.
>> >In such a case
>> >the maximum number of hops can depend on the network nature
>> >(numbered/unnumbered). Instead of hard coding it with the
>> >worst case number,
>> >let the network administrator, that is aware  of the network nature,
>> >configure it.
>> >Moreover, I think that the maximum hops should be configurable
>> >per tunnel.
>> >Thanks, Nurit.
>> >
>> >
>>
>>
>
>




From owner-mpls@UU.NET  Wed Nov 12 18:58: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 SAA18306
	for <mpls-archive@lists.ietf.org>; Wed, 12 Nov 2003 18:58: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 QQpood03036
	for <mpls-archive@lists.ietf.org>; Wed, 12 Nov 2003 23:58: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 QQpood02512;
	Wed, 12 Nov 2003 23:58:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpooc19448
	for mpls-outgoing; Wed, 12 Nov 2003 23:35: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 QQpooc19430
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Nov 2003 23:35:37 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 QQpooc16822
	for <mpls@uu.net>; Wed, 12 Nov 2003 23:35: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 QQpooc25074
	for <mpls@uu.net>; Wed, 12 Nov 2003 23:35:04 GMT
Received: from sj-iport-4.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-4.cisco.com [171.68.10.86])
	id QQpooc25021
	for <mpls@uu.net>; Wed, 12 Nov 2003 23:35:03 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hACNYwxg029856
	for <mpls@uu.net>; Wed, 12 Nov 2003 18:34:59 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADY25443;
	Wed, 12 Nov 2003 18:34:57 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hACNYuO12355 for mpls@uu.net; Wed, 12 Nov 2003 18:34:56 -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 QQpooc19301
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Nov 2003 23:33:30 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 QQpooc04775
	for <mpls@uu.net>; Wed, 12 Nov 2003 23:32:18 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 QQpooc19359
	for <mpls@uu.net>; Wed, 12 Nov 2003 23:32:18 GMT
Received: from sj-iport-5.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-5.cisco.com [171.68.10.87])
	id QQpooc19342
	for <mpls@uu.net>; Wed, 12 Nov 2003 23:32:18 GMT
Received: from cisco.com (64.102.124.13)
  by sj-iport-5.cisco.com with ESMTP; 12 Nov 2003 15:32:26 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hACNWDDM023688;
	Wed, 12 Nov 2003 18:32:13 -0500 (EST)
Received: from tnadeauw2k02 (che-vpn-cluster-1-65.cisco.com [10.86.240.65])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADY25242;
	Wed, 12 Nov 2003 18:32:12 -0500 (EST)
Reply-To: <tnadeau@cisco.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
To: "'Don Fedyk'" <dwfedyk@nortelnetworks.com>, <loa@pi.se>
Cc: "'Nurit Sprecher'" <nurit.sprecher@SeabridgeNetworks.com>,
        <cheenu@bloomberg.net>, <arunv@force10networks.com>, <mpls@UU.NET>,
        <ccamp@ops.ietf.org>
Subject: RE: MPLS Tunnel Maximum Hops
Date: Wed, 12 Nov 2003 17:32:02 -0600
Organization: Cisco Systems, inc.
Message-ID: <009901c3a975$30c069d0$6701a8c0@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
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <0D7FC1D8D861D511AEA70002A52CE5E608408596@zcard0ke.ca.nortel.com>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


	I would like to hear from operators who have deployed
the existing MPLS TE MIB on this issue before we rush to make
any changes. The other question is whether this is something 
that matters to those deploying MPLS or GMPLS or both.

	--Tom


>Limiting hops is a good idea IMHO and probably should be in 
>the MIB down the
>road. 
>
>Don
>
>
>> -----Original Message-----
>> From: Loa Andersson [mailto:NtscpUsrLoa@netscape.net] 
>> Sent: Wednesday, November 12, 2003 11:34 AM
>> To: tnadeau@cisco.com
>> Cc: 'Nurit Sprecher'; cheenu@bloomberg.net; 
>> arunv@force10networks.com; mpls@UU.NET; ccamp@ops.ietf.org
>> Subject: Re: MPLS Tunnel Maximum Hops
>> 
>> 
>> Tom,
>> 
>> while I agree that we don't want any changes just now.
>> It would also be good to understand if this is a good idea
>> or not. If not we could discard it now, if it is would could 
>> make a log for future updates. Any opinion?
>> 
>> /Loa
>




From owner-mpls@UU.NET  Wed Nov 12 19:02: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 TAA18440
	for <mpls-archive@lists.ietf.org>; Wed, 12 Nov 2003 19:02: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 QQpooe16755
	for <mpls-archive@lists.ietf.org>; Thu, 13 Nov 2003 00:02: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 QQpooe16456;
	Thu, 13 Nov 2003 00:02:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpooc19903
	for mpls-outgoing; Wed, 12 Nov 2003 23:40: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 QQpooc19893
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Nov 2003 23:39: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 QQpooc19587
	for <mpls@uu.net>; Wed, 12 Nov 2003 23:39: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 QQpooc07552
	for <mpls@uu.net>; Wed, 12 Nov 2003 23:39:31 GMT
Received: from sj-iport-5.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-5.cisco.com [171.68.10.87])
	id QQpooc07538
	for <mpls@uu.net>; Wed, 12 Nov 2003 23:39:31 GMT
Received: from cisco.com (64.102.124.13)
  by sj-iport-5.cisco.com with ESMTP; 12 Nov 2003 15:39:40 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hACNdQDM025950
	for <mpls@uu.net>; Wed, 12 Nov 2003 18:39:27 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADY25863;
	Wed, 12 Nov 2003 18:39:26 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hACNdQB13053 for mpls@uu.net; Wed, 12 Nov 2003 18:39:26 -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 QQpooc19747
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Nov 2003 23:37: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 QQpooc02402
	for <mpls@uu.net>; Wed, 12 Nov 2003 23:36: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 QQpooc27869
	for <mpls@uu.net>; Wed, 12 Nov 2003 23:36:46 GMT
Received: from sj-iport-5.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-5.cisco.com [171.68.10.87])
	id QQpooc27847
	for <mpls@uu.net>; Wed, 12 Nov 2003 23:36:45 GMT
Received: from cisco.com (64.102.124.12)
  by sj-iport-5.cisco.com with ESMTP; 12 Nov 2003 15:36:54 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hACNaexg000484;
	Wed, 12 Nov 2003 18:36:41 -0500 (EST)
Received: from tnadeauw2k02 (che-vpn-cluster-1-65.cisco.com [10.86.240.65])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ADY25576;
	Wed, 12 Nov 2003 18:36:39 -0500 (EST)
Reply-To: <tnadeau@cisco.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
To: <loa@pi.se>
Cc: "'Nurit Sprecher'" <nurit.sprecher@SeabridgeNetworks.com>,
        <cheenu@bloomberg.net>, <arunv@force10networks.com>, <mpls@UU.NET>,
        <ccamp@ops.ietf.org>
Subject: RE: MPLS Tunnel Maximum Hops
Date: Wed, 12 Nov 2003 18:36:34 -0500
Organization: Cisco Systems, inc.
Message-ID: <009c01c3a975$cf92d480$6701a8c0@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
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <3FB26113.80103@netscape.net>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



>Tom,
>
>while I agree that we don't want any changes just now.
>It would also be good to understand if this is a good idea
>or not. If not we could discard it now, if it is would could
>make a log for future updates. Any opinion?

	That is a good idea. I will keep a list of things
that didn't get into the current version.

	--Tom



>
>/Loa
>
>Thomas D. Nadeau wrote:
>
>>  
>>
>>>Any response to the bellow?
>>>    
>>>
>>
>>   The MIB is well past IETF last call, so
>>I don't believe we can make any further changes
>>at this time.
>>
>>   --Tom
>>
>>
>>
>>  
>>
>>>Hi,
>>>I have a question  regarding the mplsTunnelMaxHops scalar that 
>>>indicates the
>>>maximum number of hops that can be specified on each tunnel 
>>>supported by the
>>>LSR.
>>>This scalar is a read only attribute but I can find it very 
>>>useful to let
>>>configure it as well. 
>>>One of the CSPF constraints is the maximum number of hops the 
>>>LSP may follow
>>>through. The limitation on the maximum number for example can 
>>>result from
>>>the maximum packet size when fragmentation is not supported. 
>>>In such a case
>>>the maximum number of hops can depend on the network nature
>>>(numbered/unnumbered). Instead of hard coding it with the 
>>>worst case number,
>>>let the network administrator, that is aware  of the network nature,
>>>configure it.
>>>Moreover, I think that the maximum hops should be configurable 
>>>per tunnel.
>>>Thanks, Nurit.
>>>
>>>
>>>    
>>>
>>
>>
>>
>>
>>  
>>
>
>




From owner-mpls@UU.NET  Wed Nov 12 19:06: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 TAA18549
	for <mpls-archive@lists.ietf.org>; Wed, 12 Nov 2003 19:06: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 QQpooe22562
	for <mpls-archive@lists.ietf.org>; Thu, 13 Nov 2003 00:06: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 QQpooe22166;
	Thu, 13 Nov 2003 00:06:03 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpooc20264
	for mpls-outgoing; Wed, 12 Nov 2003 23:43: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 QQpooc20256
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Nov 2003 23:43:16 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 QQpooc06222
	for <mpls@UU.NET>; Wed, 12 Nov 2003 23:43: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 QQpooc13112
	for <mpls@UU.NET>; Wed, 12 Nov 2003 23:42:59 GMT
Received: from tiger.seabridge.co.il by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [212.25.127.226])
	id QQpooc13042
	for <mpls@UU.NET>; Wed, 12 Nov 2003 23:42:58 GMT
Received: by tiger.seabridge.co.il with Internet Mail Service (5.5.2653.19)
	id <V1ZD188W>; Thu, 13 Nov 2003 01:43:14 +0200
Message-ID: <C87E5A01714C7840B92CDED9E79329CA0117D140@leopard.seabridge.co.il>
From: Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>
To: "'tnadeau@cisco.com'" <tnadeau@cisco.com>,
        "'Adrian Farrel'"
	 <adrian@olddog.co.uk>,
        Nurit Sprecher
	 <nurit.sprecher@SeabridgeNetworks.com>,
        jcucchiara@mindspring.com, cheenu@bloomberg.net,
        arunv@force10networks.com
Cc: mpls@UU.NET, ccamp@ops.ietf.org
Subject: RE: MPLS Tunnel Maximum Hops
Date: Thu, 13 Nov 2003 01:43:12 +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

Well, meanwhile I have talked to Adrian and explained to him why it is
required. 
I definitely think that this should be configurable per tunnel. For
different tunnels I would like to limit the number of hops it may flow
through (from many reasons that I'll specify in a detailed mail next week)
and I would like to find the best route (using the CSPF) that can be
committed to this restriction. I believe that this limitation relates not
only to the LSR capability but also to the network topology and to the
tunnels constraints (for example the required latency, etc.). 
Please note that even if it relates to the LSR capability, other LSRs that
have LSPs that flow via this LSR should be aware of this limitation,
otherwise we can meet many error conditions. This can be solved by
configuration. 
I believe that in the multi area case, where loose nodes are involved, we
should signal this value as well, otherwise this value will not sustain any
more. 

Anyway, I understand that I came with this late, and I'll have to push it in
the regular procedure.
Nurit.

-----Original Message-----
From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
Sent: Thursday, November 13, 2003 01:12
To: 'Adrian Farrel'; 'Nurit Sprecher'; jcucchiara@mindspring.com;
cheenu@bloomberg.net; arunv@force10networks.com
Cc: mpls@UU.NET; ccamp@ops.ietf.org
Subject: RE: MPLS Tunnel Maximum Hops


>I am unclear why this object should be writeable.

        I agree.

>As you imply, it is either something that you wish to control
>for each individual CSPF
>calculation (in which case it is a per tunnel instance
>configuration parameter) or it is a
>quality of the entire LSR and is applied to all LSPs.
>
>The current object was intended to reflect the capabilities of
>the LSR, not an operational
>requirement. Thus it cannot be changed by the operator.
>
>It would be a different thing if you want to change the LSR's
>CSPF behavior (compared with
>stating the LSR's capabilities).
>
>So *if* this was to advance I would say that it should either be:
>- a per tunnel instance object
>- a configuration parameter for CSPF.
>Personally, I do not see the requirement for the former, and
>the latter is clearly out of
>scope of the MPLS MIB modules.
>
>Note that there is an edge condition where you need to limit
>the size of ERO on some
>interfaces but not on others. In my view, this is a property
>of the interface which should
>be reported to CSPF direct, and not configured through the MPLS MIBs.
       
        I agree. The only possible option would be to add
another object to reflect the configured value.

        --Tom


>
>Cheers,
>Adrian
>
>----- Original Message -----
>From: "Nurit Sprecher" <nurit.sprecher@SeabridgeNetworks.com>
>To: <jcucchiara@mindspring.com>; "Nurit Sprecher"
><nurit.sprecher@SeabridgeNetworks.com>;
><tnadeau@cisco.com>; <cheenu@bloomberg.net>;
><arunv@force10networks.com>
>Cc: <mpls@UU.NET>; <ccamp@ops.ietf.org>
>Sent: Wednesday, November 12, 2003 7:52 PM
>Subject: RE: MPLS Tunnel Maximum Hops
>
>
>> Hi Joan,
>> Thanks for the response.
>> 1. What is the procedure to push it to the standard right
>now when the draft
>> is in a last call?
>> 2. Do you agree that this should be configurable? Otherwise
>how can you
>> determine on the value?
>> 3. Do you agree that it may be required also to configure it
>per tunnel (but
>> have a default value)?
>> Until now I have just got e-mails on the procedure but not
>on the idea
>> itself.
>> I'll appreciate your response, Nurit.
>>
>>
>> -----Original Message-----
>> From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com]
>> Sent: Wednesday, November 12, 2003 19:32
>> To: Nurit Sprecher; 'tnadeau@cisco.com'; Nurit Sprecher;
>> cheenu@bloomberg.net; arunv@force10networks.com
>> Cc: mpls@UU.NET; ccamp@ops.ietf.org
>> Subject: RE: MPLS Tunnel Maximum Hops
>>
>>
>> Hi Nurit,
>>
>> I can understand you wanting this change, but that is why
>> we had working group last calls in June and an IETF last
>> call in Aug/Sep.  That is the opportunity for
>> folks to give their comments,  knowing that the MIB can only
>> have minor edits after that.
>>
>> The most minimal way I see to make this change (and this is
>> just my opinion) is:
>>
>> * change the mplsTunnelMaxHops object to read-write
>> * agree upon a DEFVAL (default value upon startup, which can
>>    be set to a different value by an operator)
>> * add to the conformance statement that this may be supported
>>    as a read-only
>>
>> So, in addition to making the object read-write, think it needs a
>> DEFVAL, and this would need to be discussed and agreed upon by
>> the working group.   This is more than minor editing in my opinion.
>> I am in agreement with Loa and Tom and would like to see
>> the MIBs move forward.
>>
>>   -Thanks,
>>     -Joan
>>
>> -----Original Message-----
>> From: Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>
>> Sent: Nov 12, 2003 11:25 AM
>> To: "'tnadeau@cisco.com'" <tnadeau@cisco.com>,
>>         Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>,
>>         cheenu@bloomberg.net, arunv@force10networks.com
>> Cc: mpls@UU.NET, ccamp@ops.ietf.org
>> Subject: RE: MPLS Tunnel Maximum Hops
>>
>> Thanks Tom for responding me.
>> I understand that this is in a last call state, but this
>issue should be
>> addressed somehow?
>> I am surprised that such an attribute that is provided to
>the CSPF algorithm
>> is not configurable. How can you determine its value?
>Hard-coded? Doesn't it
>> have to do with network topology?
>> I think it should be configurable and we should see how we
>could add it to
>> the draft.
>> Nurit.
>>
>> -----Original Message-----
>> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
>> Sent: Wednesday, November 12, 2003 18:14
>> To: 'Nurit Sprecher'; cheenu@bloomberg.net; arunv@force10networks.com
>> Cc: mpls@uu.net; ccamp@ops.ietf.org
>> Subject: RE: MPLS Tunnel Maximum Hops
>>
>>
>> >Any response to the bellow?
>>
>>         The MIB is well past IETF last call, so
>> I don't believe we can make any further changes
>> at this time.
>>
>>         --Tom
>>
>>
>>
>> >Hi,
>> >I have a question  regarding the mplsTunnelMaxHops scalar that
>> >indicates the
>> >maximum number of hops that can be specified on each tunnel
>> >supported by the
>> >LSR.
>> >This scalar is a read only attribute but I can find it very
>> >useful to let
>> >configure it as well.
>> >One of the CSPF constraints is the maximum number of hops the
>> >LSP may follow
>> >through. The limitation on the maximum number for example can
>> >result from
>> >the maximum packet size when fragmentation is not supported.
>> >In such a case
>> >the maximum number of hops can depend on the network nature
>> >(numbered/unnumbered). Instead of hard coding it with the
>> >worst case number,
>> >let the network administrator, that is aware  of the network nature,
>> >configure it.
>> >Moreover, I think that the maximum hops should be configurable
>> >per tunnel.
>> >Thanks, Nurit.
>> >
>> >
>>
>>
>
>


From owner-mpls@UU.NET  Thu Nov 13 03:48: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 DAA16771
	for <mpls-archive@lists.ietf.org>; Thu, 13 Nov 2003 03:48: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 QQpopn27724
	for <mpls-archive@lists.ietf.org>; Thu, 13 Nov 2003 08:48: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 QQpopn27564;
	Thu, 13 Nov 2003 08:48:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpopl18211
	for mpls-outgoing; Thu, 13 Nov 2003 08:25: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 QQpopl18199
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Nov 2003 08:25: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 QQpopl16360
	for <mpls@uu.net>; Thu, 13 Nov 2003 08:24: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 QQpopl24172
	for <mpls@uu.net>; Thu, 13 Nov 2003 08:24:35 GMT
Received: from imo-d02.mx.aol.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imo-d02.mx.aol.com [205.188.157.34])
	id QQpopl24162
	for <mpls@uu.net>; Thu, 13 Nov 2003 08:24:35 GMT
Received: from NtscpUsrLoa@netscape.net
	by imo-d02.mx.aol.com (mail_out_v36_r1.1.) id 1.4.ad7814a (22682);
	Thu, 13 Nov 2003 03:24:30 -0500 (EST)
Received: from  netscape.net (tla-loa.ietf58.ietf.org [130.129.131.229]) by air-in04.mx.aol.com (v97.8) with ESMTP id MAILININ43-589a3fb33fbe3bb; Thu, 13 Nov 2003 03:24:30 -0500
Message-ID: <3FB33FB9.6050605@netscape.net>
Date: Thu, 13 Nov 2003 09:24:25 +0100
From: Loa Andersson <NtscpUsrLoa@netscape.net>
Reply-To: loa@pi.se
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MPLS wg <mpls@UU.NET>, George Swallow <swallow@cisco.com>
Subject: the feed and query drafts - existing implementations?
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-AOL-IP: 130.129.131.229
X-Mailer: Unknown (No Version)
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Working group,

we have two working group documents that has been
hanging around for a long time.

draft-ietf-mpls-lsp-query-09.txt
draft-ietf-mpls-te-feed-06.txt

Before sending them to the IESG for review and publication
we would like to ask for existing inplementation of these
drafts.

Note that RFC1264 requires (among other things) existing
implementitations before it is possible to progress
the drafts.

At the same time we would like to ask for if there are
any interest to progress these drafts, our (limited).
efforts to document interest has largely failed.

Please respond to the the list or to the chairs directly.

/Loa



From owner-mpls@UU.NET  Thu Nov 13 10:38: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 KAA03361
	for <mpls-archive@lists.ietf.org>; Thu, 13 Nov 2003 10:38: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 QQpoqo15104
	for <mpls-archive@lists.ietf.org>; Thu, 13 Nov 2003 15:38:34 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 QQpoqo14863;
	Thu, 13 Nov 2003 15:38:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoqn05251
	for mpls-outgoing; Thu, 13 Nov 2003 15:15: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 QQpoqn05244
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Nov 2003 15:15: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 QQpoqm18878
	for <mpls@uu.net>; Thu, 13 Nov 2003 15:14: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 QQpoqm12605
	for <mpls@uu.net>; Thu, 13 Nov 2003 15:14:49 GMT
Received: from sj-iport-4.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-4.cisco.com [171.68.10.86])
	id QQpoqm12587
	for <mpls@uu.net>; Thu, 13 Nov 2003 15:14:48 GMT
Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hADFEbDM007883;
	Thu, 13 Nov 2003 10:14:37 -0500 (EST)
Message-Id: <200311131514.hADFEbDM007883@rtp-core-2.cisco.com>
To: curtis@fictitious.org
cc: Shahram Davari <Shahram_Davari@pmc-sierra.com>,
        David Allan <dallan@nortelnetworks.com>, "'loa@pi.se'" <loa@pi.se>,
        MPLS wg <mpls@UU.NET>, George Swallow <swallow@cisco.com>,
        Alex Zinin <zinin@psg.com>
Subject: Re: on the mpls oam framework 
In-reply-to: Your message of Tue, 11 Nov 2003 13:07:28 -0500.
             <200311111807.hABI7ShO031954@workhorse.fictitious.org> 
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.3
 (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, 13 Nov 2003 10:14:37 -0500
From: Eric Rosen <erosen@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


Curtis> I think the draft as is could be submitted as an informational draft
Curtis> submitted by Dave outside the work group.

Curtis> As a framework for OAM it is a diversion from progress rather than a
Curtis> step toward progress.

Very well put!  I agree completely. 



From owner-mpls@UU.NET  Sat Nov 15 01:38:36 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 BAA15749
	for <mpls-archive@lists.ietf.org>; Sat, 15 Nov 2003 01:38: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 QQpowo20094
	for <mpls-archive@lists.ietf.org>; Sat, 15 Nov 2003 06:38: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 QQpowo20029;
	Sat, 15 Nov 2003 06:38:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpown04296
	for mpls-outgoing; Sat, 15 Nov 2003 06:16:03 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 QQpown04196
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 15 Nov 2003 06:15:48 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 QQpown21704
	for <mpls@UU.NET>; Sat, 15 Nov 2003 06: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 QQpown16935
	for <mpls@UU.NET>; Sat, 15 Nov 2003 06:15:09 GMT
Received: from kummer.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint2.juniper.net [207.17.136.150])
	id QQpown16922
	for <mpls@UU.NET>; Sat, 15 Nov 2003 06:15:08 GMT
Received: from kummer.juniper.net (localhost [127.0.0.1])
	by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id hAF6Edda047512;
	Fri, 14 Nov 2003 22:14:39 -0800 (PST)
	(envelope-from kireeti@juniper.net)
Received: from localhost (kireeti@localhost)
	by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id hAF6EdvY047509;
	Fri, 14 Nov 2003 22:14:39 -0800 (PST)
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
Date: Fri, 14 Nov 2003 22:14:39 -0800 (PST)
From: Kireeti Kompella <kireeti@juniper.net>
To: Loa Andersson <loa@pi.se>
cc: mpls@UU.NET, George Swallow <swallow@cisco.com>,
        Alex Zinin <zinin@psg.com>
Subject: RE: on the mpls oam framework
In-Reply-To: <0536FC9B908BEC4597EE721BE6A3538904EF2DF0@i2km07-ukbr.domain1.systemhost.net>
Message-ID: <20031114220550.F47474@kummer.juniper.net>
References: <0536FC9B908BEC4597EE721BE6A3538904EF2DF0@i2km07-ukbr.domain1.systemhost.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Loa,

On Mon, 10 Nov 2003 neil.2.harrison@bt.com wrote:

> ie one can't fix what is wrong/missing in MPLS by
> asking Dave to redo his paper...as its simply a statement of fact
> and is therefore 'right'.

As co-author of the wrong approach, I will be happy to help Tom with
his wrong OAM framework for the wrong MPLS architecture we so wrongly
have.  We would be wrong to make Dave wrong when he is so right.

Kireeti.
-------


From owner-mpls@UU.NET  Sat Nov 15 02:11: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 CAA18831
	for <mpls-archive@lists.ietf.org>; Sat, 15 Nov 2003 02:11: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 QQpowq00105
	for <mpls-archive@lists.ietf.org>; Sat, 15 Nov 2003 07:11: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 QQpowq29980;
	Sat, 15 Nov 2003 07:11:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpowp07145
	for mpls-outgoing; Sat, 15 Nov 2003 06: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 QQpowp07132
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 15 Nov 2003 06:49: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 QQpowp22193
	for <mpls@UU.NET>; Sat, 15 Nov 2003 06:47:15 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 QQpowp29708
	for <mpls@UU.NET>; Sat, 15 Nov 2003 06:47:14 GMT
Received: from kummer.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint2.juniper.net [207.17.136.150])
	id QQpowp29692
	for <mpls@UU.NET>; Sat, 15 Nov 2003 06:47:14 GMT
Received: from kummer.juniper.net (localhost [127.0.0.1])
	by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id hAF6l9da047623;
	Fri, 14 Nov 2003 22:47:09 -0800 (PST)
	(envelope-from kireeti@juniper.net)
Received: from localhost (kireeti@localhost)
	by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id hAF6l9kA047620;
	Fri, 14 Nov 2003 22:47:09 -0800 (PST)
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
Date: Fri, 14 Nov 2003 22:47:09 -0800 (PST)
From: Kireeti Kompella <kireeti@juniper.net>
To: David Allan <dallan@nortelnetworks.com>
cc: MPLS wg <mpls@UU.NET>
Subject: RE: on the mpls oam framework 
In-Reply-To: <FFFC48AEAA5F7447929F4F0D93FCC12D02B92781@zcard031.ca.nortel.com>
Message-ID: <20031114222511.N47474@kummer.juniper.net>
References: <FFFC48AEAA5F7447929F4F0D93FCC12D02B92781@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, 11 Nov 2003, David Allan wrote:

> IMHO You are persisting in ignoring what you don't want to see.

Speaking as a vendor:

On mp2p: at least 90% of the MPLS deployments I've seen use LDP.

On ECMP: many providers ask us explicitly for ECMP.  On the other
hand, no provider that I know (other than BT) of has complained
about ECMP and asked us to turn it off.

On PHP: two providers (one being BT) have complained about PHP, out
of all the providers I've talked to about MPLS (about 3%).

Kireeti.
-------

"Reality is a dagger in the heart of the starry-eyed." -- MP


From owner-mpls@UU.NET  Sat Nov 15 04:11: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 EAA01771
	for <mpls-archive@lists.ietf.org>; Sat, 15 Nov 2003 04:11: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 QQpowy19824
	for <mpls-archive@lists.ietf.org>; Sat, 15 Nov 2003 09:12: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 QQpowy19777;
	Sat, 15 Nov 2003 09:12:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpowx25306
	for mpls-outgoing; Sat, 15 Nov 2003 08:50: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 QQpowx25296
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 15 Nov 2003 08:50:25 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 QQpowx17296
	for <mpls@UU.NET>; Sat, 15 Nov 2003 08:49: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 QQpowx23725
	for <mpls@UU.NET>; Sat, 15 Nov 2003 08:49:15 GMT
Received: from web13507.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web13507.mail.yahoo.com [216.136.175.86])
	id QQpowx23711
	for <mpls@UU.NET>; Sat, 15 Nov 2003 08:49:14 GMT
Message-ID: <20031115084913.66386.qmail@web13507.mail.yahoo.com>
Received: from [68.118.70.100] by web13507.mail.yahoo.com via HTTP; Sat, 15 Nov 2003 00:49:13 PST
Date: Sat, 15 Nov 2003 00:49:13 -0800 (PST)
From: Mark Seery <m_seery@yahoo.com>
Subject: RE: on the mpls oam framework 
To: Kireeti Kompella <kireeti@juniper.net>
Cc: MPLS wg <mpls@UU.NET>
In-Reply-To: <20031114222511.N47474@kummer.juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Kireeti.

It's been a tough week eh. Flare ups all over the place! I like Minneapolis, so
I am not sure we can blame the city, of course if I find out that too many
people had a bunch Walleye, then I might have to rethink that ;-)

At any rate, hopefully we will all exit this downward cycle soon and both sides
will back of the rhetoric. It is definetly no fun to watch, and I imagine it is
even less fun to be one of the active combatants - hopefully I am not about to
experience that particular joy ;-)

Some comments below.

Hope you have a good weekend.

Best,
Mark

--- Kireeti Kompella <kireeti@juniper.net> wrote:
> Hi Dave,
> 
> On Tue, 11 Nov 2003, David Allan wrote:
> 
> > IMHO You are persisting in ignoring what you don't want to see.
> 
> Speaking as a vendor:
> 
> On mp2p: at least 90% of the MPLS deployments I've seen use LDP.

Interesting stat for the L2VPN WG to consider ;-) BTW, 90% of carriers I talk
to think that LDP is used to create a connection-oriented service. Hopefully
one day we might all agree that MPLS has created some new modes that really
defy our pre-existing notions (for better and/or worse). My point of saying
that is I feel fairly confident in asserting that there is a lot about MPLS
that many people don't understand - that's not a license for obnoxious
behavior, but it is a potential for tuning/education in many areas, over time.

Also, over the last year I've had to stand politely before many operators (in
the U.S.) while they told me that they didn't even consider the IETF a real
standards body. I can assure that is not the kind of expression that I thought
boded well for any part of our industry and the organization we all enjoy
participating in so much. So while you might be in regular contact with people
at service providers that think everything is honky dory, its my impression
there are significant schisms to be worked on out there. I don't think the
result is in doubt, but I do wonder about the timing sometimes.

> On ECMP: many providers ask us explicitly for ECMP.  On the other
> hand, no provider that I know (other than BT) of has complained
> about ECMP and asked us to turn it off.

ECMP is a natural thing to do with a SPF (non traffic-engineered) mode of
networking (IP or LDP/MPLS), that doesn't mean there were not some extra things
to be thought about when applying it in the MPLS context.

> On PHP: two providers (one being BT) have complained about PHP, out
> of all the providers I've talked to about MPLS (about 3%).

As a person working at companies implementing PHP, I have to say I never
thought it made life easier for the implementors (but obviously you are better
to comment than me) - which is not a comment on its value, just an observation.
Its not clear to me also why at this stage, why a provider using the newest
equipment in a greenfield deployment would find much value in this feature -
but happy to be educated.

In the interest of my further education, I was wondering if you could point out
the errors in the below statement.

"Connectivity verification requires testing of connectivity between all
possible ingress/egress combinations. Frequently it will not be possible to
infer the ingress LSR and specific LSP directly at the egress as such
information may be lost at merge points in mp2p LSPs or due to PHP. This is
true for both OAM messaging, and normal data plane payloads. There may be
numerous reasons why an ingress-egress pair may have a plurality of LSPs
between them, so the ability to
distinguish the source and purpose of specific probes beyond mere knowledge of
the originating LSR is required.

The ability to distinguish the ingress can be achieved via modifying the OAM
protocol to carry such information, or may be achieved via modifications to
operational procedures such as overlaying p2p connectivity."


From owner-mpls@UU.NET  Sat Nov 15 05:35: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 FAA03550
	for <mpls-archive@lists.ietf.org>; Sat, 15 Nov 2003 05:35: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 QQpoxe28187
	for <mpls-archive@lists.ietf.org>; Sat, 15 Nov 2003 10:35:32 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 QQpoxe28139;
	Sat, 15 Nov 2003 10:35:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoxd10784
	for mpls-outgoing; Sat, 15 Nov 2003 10: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 QQpoxd10777
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 15 Nov 2003 10:18: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 QQpoxd22901
	for <mpls@UU.NET>; Sat, 15 Nov 2003 10:16: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 QQpoxd03901
	for <mpls@UU.NET>; Sat, 15 Nov 2003 10:16: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 QQpoxd03884
	for <mpls@UU.NET>; Sat, 15 Nov 2003 10:16:08 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAFAFtw03769;
	Sat, 15 Nov 2003 05:15:56 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <W3H8889T>; Sat, 15 Nov 2003 05:15:56 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D02B927C8@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'Kireeti Kompella'" <kireeti@juniper.net>
Cc: MPLS wg <mpls@UU.NET>
Subject: RE: on the mpls oam framework 
Date: Sat, 15 Nov 2003 05:15:55 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Kireeti:

> > IMHO You are persisting in ignoring what you don't want to see.
> 

I understand what you're seeing in the marketplace. 

My point was that the ITU work has progressed beyond the low hanging fruit
of p2p, and (for example) Y.17fec-cv is directed at LDP/ECMP etc. and for at
least PW and VPN applications, could also work with PHP. It is when an LSR
offers a lot of FEC/label bindings at the LDP/IP layer that fec-cv would
lose precision in the PHP scenario. 

I've discussed this at conferences we've all been at, posted drafts,
presented this stuff (in SF) yet folks persist in characterizing the ITU
work as focused on an insignificant corner case. I don't think it is that
insignificant, but it is not the only thing going on....

later
Dave


From owner-mpls@UU.NET  Sat Nov 15 08:45: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 IAA07606
	for <mpls-archive@lists.ietf.org>; Sat, 15 Nov 2003 08:45:55 -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 QQpoxr20473
	for <mpls-archive@lists.ietf.org>; Sat, 15 Nov 2003 13:46: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 QQpoxr20450;
	Sat, 15 Nov 2003 13:46:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoxp23589
	for mpls-outgoing; Sat, 15 Nov 2003 13:28: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 QQpoxp23582
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 15 Nov 2003 13:28: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 QQpoxp02138
	for <mpls@uu.net>; Sat, 15 Nov 2003 13:27: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 QQpoxp25304
	for <mpls@uu.net>; Sat, 15 Nov 2003 13:27:48 GMT
Received: from sj-iport-3.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72])
	id QQpoxp25293
	for <mpls@uu.net>; Sat, 15 Nov 2003 13:27:47 GMT
Received: from cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 15 Nov 2003 05:35:13 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAFDRhtg003523
	for <mpls@uu.net>; Sat, 15 Nov 2003 05:27:44 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEA05180;
	Sat, 15 Nov 2003 08:27:43 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAFDRhL11303 for mpls@uu.net; Sat, 15 Nov 2003 08:27:43 -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 QQpoxp23525
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 15 Nov 2003 13:26:40 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 QQpoxp28833
	for <mpls@UU.NET>; Sat, 15 Nov 2003 13:26: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 QQpoxp23787
	for <mpls@UU.NET>; Sat, 15 Nov 2003 13:26:10 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 QQpoxp23769
	for <mpls@UU.NET>; Sat, 15 Nov 2003 13:26:10 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.8p1/8.12.8) with ESMTP id hAFDP6hO046450;
	Sat, 15 Nov 2003 08:25:11 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311151325.hAFDP6hO046450@workhorse.fictitious.org>
To: "Adrian Farrel" <adrian@olddog.co.uk>
cc: "'mpls@uu.net'" <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: Soft/hard pre-emption 
In-reply-to: Your message of "Tue, 11 Nov 2003 15:39:01 GMT."
             <010701c3a869$f1437bf0$db818182@Puppy> 
Date: Sat, 15 Nov 2003 08:25:05 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <010701c3a869$f1437bf0$db818182@Puppy>, "Adrian Farrel" writes:
> As my first step in resolving this issue I would like to conduct a brief surv
> ey amongst
> implementors.
> 
> Please feel free to respond to me off-list and in confidence. If you do not w
> ant your
> information shared more widely, please state that explicitly in your email.
> 
> Also, please note that this questionnaire is NOT a discussion of what is the 
> correct
> behavior. It is simply collecting information about interpretation of RFCs 22
> 05 and 3209.
> 
> Thanks,
> Adrian
> 
> Questions:
> 
> 1. When your implementation receives a PathErr message indicating pre-emption
>  for an
> established LSP, does it tear the LSP (i.e. release labels) or only release r
> esources
> (i.e. leave the LSP in place as 'best effort')?
> In other words, is your default behavior hard or soft pre-emption?
> 
> 2. When your implementation receives any other (non-notify) PathErr for an es
> tablished
> LSP, does it tear the LSP (i.e. release labels) or leave it in place?
> 
> 3. Is your code carrying live traffic, in lab tests, or in development?
> 
> 4. If deployed, can you give me a feeling for the number of LSRs in the field
>  (just an
> order of magnitude)?
> 
> Thanks,
> Adrian



I don't remember seeing a summary of answers on this.

Curtis



From owner-mpls@UU.NET  Sat Nov 15 11:23: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 LAA11917
	for <mpls-archive@lists.ietf.org>; Sat, 15 Nov 2003 11:23: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 QQpoyb27717
	for <mpls-archive@lists.ietf.org>; Sat, 15 Nov 2003 16:23: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 QQpoyb27655;
	Sat, 15 Nov 2003 16:23:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoya03100
	for mpls-outgoing; Sat, 15 Nov 2003 16:05: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 QQpoya03094
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 15 Nov 2003 16:05:25 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 QQpoya04387
	for <mpls@UU.NET>; Sat, 15 Nov 2003 16:04:18 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 QQpoya29806
	for <mpls@UU.NET>; Sat, 15 Nov 2003 16:04:17 GMT
Received: from smtp2.fre.skanova.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp2.fre.skanova.net [195.67.227.95])
	id QQpoya29779
	for <mpls@UU.NET>; Sat, 15 Nov 2003 16:04:17 GMT
Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45])
	by smtp2.fre.skanova.net (8.12.10/8.12.10) with ESMTP id hAFG4Eok028768;
	Sat, 15 Nov 2003 17:04:14 +0100 (CET)
Message-ID: <3FB64E75.7070600@pi.se>
Date: Sat, 15 Nov 2003 17:04:05 +0100
From: Loa Andersson <loa@pi.se>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MPLS wg <mpls@UU.NET>
CC: Mark Seery <m_seery@yahoo.com>, Kireeti Kompella <kireeti@juniper.net>
Subject: Re: on the mpls oam framework
References: <20031115084913.66386.qmail@web13507.mail.yahoo.com>
In-Reply-To: <20031115084913.66386.qmail@web13507.mail.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Working group, Mark and Kireeti,

it is known that irony is an hard art to pursue.
Kireeti, Mark missed the irony in your mail.
Mark, after doing that you had a go on the same method.

I think I can understand both of your stating points, however
just now it is not helpful.

Let me put the wg chair hat on and try to sort some of the
issues out.

Two issues
----------

We are really trying to sort out two different issues at
the same time, one technical and one procedural.

On the technical side I've an opinion, on the procedural I'v also
an opinion. I've not voiced my opinion on the technical solution
for MPLS OAM so far, and will not in this mail either. I pointed
out some shortcommings to the draft-allan IDs, when I explained
why I wanted to start a fresh document.

Procedures
----------

We've a number of OAM drafts currently under discussion in the
MPLS-group, the OAM framework is one of them. lsp-ping, lsr-selftest,
bfd are others.

Now from a working group and ietf perspective there is a procedure to
follow, the decisions taken earlier stands until working group consensus
to change them is teached. And if and when such a consensus is we need to
go back and change the exisisting documents that is effected.

I guess that there are similar procedures in the ITU, if I were to tell
that they are not develop things according a particular document published
by the IETF, they would change their standards, I guess that I at least
would have to write a contribution to tell them why this would be a
good idea.

Debating style
--------------

So repeating "mpls has developed beyond that point" or "this is what 
mpls is"
is not getting us anywhere. Nor is assigning points of view to other 
people.
Or claiming perfection for once own work.
We are all for an healthy development of mpls, what we have are two 
different
opinions of what that development looks like. My task here is to find a path
that leads to wg consensus.


MPLS OAM
--------

MPLS OAM are on the mpls wg charter, to my understanding we need a framework
for this area. Looking into what is going on it was (and is) my 
conslusion that
neither of the documents so far written would have a chance to become a 
docment
that we would reach a wg consensus around.

I therefore (with the support of my co-chair and the ADs) asked one
Tom and Dave to:
- start a new OAM framework document
- taking all the known ongoing work in the mpls wg and elsewhere into
  consideration,
- look into what is going on elsewhere
- carefully build on our history
- indicate necessary changes to existing documents and specifications,
  work with the authors of the documents effected
- solicit the input from people that have documents published in the
  mpls OAM area and others that they know have an interest in the area
- carefully build this so we reach the wg consensus

I simply fail to understand why this has initiated this type of discussion
on the list.

Actions
-------

The last mail I got from Dave indicated that he were willing to "give it
a shot" and I know that Tom is willing to do the same.
So let us stop the quibling around this a get down to get the work done.

draft-allan
-----------

As for the draft-allan I do not see any problem to request that it is
published as an informational RFC, though I would suggest that it is
carefully reviewed and that an applicability statement is added, preferably
in the document.

/Loa

Mark Seery wrote:

>Hi Kireeti.
>
>It's been a tough week eh. Flare ups all over the place! I like Minneapolis, so
>I am not sure we can blame the city, of course if I find out that too many
>people had a bunch Walleye, then I might have to rethink that ;-)
>
>At any rate, hopefully we will all exit this downward cycle soon and both sides
>will back of the rhetoric. It is definetly no fun to watch, and I imagine it is
>even less fun to be one of the active combatants - hopefully I am not about to
>experience that particular joy ;-)
>
>Some comments below.
>
>Hope you have a good weekend.
>
>Best,
>Mark
>
>--- Kireeti Kompella <kireeti@juniper.net> wrote:
>  
>
>>Hi Dave,
>>
>>On Tue, 11 Nov 2003, David Allan wrote:
>>
>>    
>>
>>>IMHO You are persisting in ignoring what you don't want to see.
>>>      
>>>
>>Speaking as a vendor:
>>
>>On mp2p: at least 90% of the MPLS deployments I've seen use LDP.
>>    
>>
>
>Interesting stat for the L2VPN WG to consider ;-) BTW, 90% of carriers I talk
>to think that LDP is used to create a connection-oriented service. Hopefully
>one day we might all agree that MPLS has created some new modes that really
>defy our pre-existing notions (for better and/or worse). My point of saying
>that is I feel fairly confident in asserting that there is a lot about MPLS
>that many people don't understand - that's not a license for obnoxious
>behavior, but it is a potential for tuning/education in many areas, over time.
>
>Also, over the last year I've had to stand politely before many operators (in
>the U.S.) while they told me that they didn't even consider the IETF a real
>standards body. I can assure that is not the kind of expression that I thought
>boded well for any part of our industry and the organization we all enjoy
>participating in so much. So while you might be in regular contact with people
>at service providers that think everything is honky dory, its my impression
>there are significant schisms to be worked on out there. I don't think the
>result is in doubt, but I do wonder about the timing sometimes.
>
>  
>
>>On ECMP: many providers ask us explicitly for ECMP.  On the other
>>hand, no provider that I know (other than BT) of has complained
>>about ECMP and asked us to turn it off.
>>    
>>
>
>ECMP is a natural thing to do with a SPF (non traffic-engineered) mode of
>networking (IP or LDP/MPLS), that doesn't mean there were not some extra things
>to be thought about when applying it in the MPLS context.
>
>  
>
>>On PHP: two providers (one being BT) have complained about PHP, out
>>of all the providers I've talked to about MPLS (about 3%).
>>    
>>
>
>As a person working at companies implementing PHP, I have to say I never
>thought it made life easier for the implementors (but obviously you are better
>to comment than me) - which is not a comment on its value, just an observation.
>Its not clear to me also why at this stage, why a provider using the newest
>equipment in a greenfield deployment would find much value in this feature -
>but happy to be educated.
>
>In the interest of my further education, I was wondering if you could point out
>the errors in the below statement.
>
>"Connectivity verification requires testing of connectivity between all
>possible ingress/egress combinations. Frequently it will not be possible to
>infer the ingress LSR and specific LSP directly at the egress as such
>information may be lost at merge points in mp2p LSPs or due to PHP. This is
>true for both OAM messaging, and normal data plane payloads. There may be
>numerous reasons why an ingress-egress pair may have a plurality of LSPs
>between them, so the ability to
>distinguish the source and purpose of specific probes beyond mere knowledge of
>the originating LSR is required.
>
>The ability to distinguish the ingress can be achieved via modifying the OAM
>protocol to carry such information, or may be achieved via modifications to
>operational procedures such as overlaying p2p connectivity."
>
>
>  
>

-- 

Loa Andersson

mobile +46 739 81 21 64




From owner-mpls@UU.NET  Sat Nov 15 13:06: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 NAA14373
	for <mpls-archive@lists.ietf.org>; Sat, 15 Nov 2003 13:06:03 -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 QQpoyi03029
	for <mpls-archive@lists.ietf.org>; Sat, 15 Nov 2003 18:06: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 QQpoyi02947;
	Sat, 15 Nov 2003 18:06:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoyh01792
	for mpls-outgoing; Sat, 15 Nov 2003 17:49:12 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 QQpoyh01786
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 15 Nov 2003 17:49:07 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 QQpoyh12629
	for <mpls@UU.NET>; Sat, 15 Nov 2003 17:48:30 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 QQpoyh01176
	for <mpls@UU.NET>; Sat, 15 Nov 2003 17:48:29 GMT
Received: from i2kc03-ukbr.domain1.systemhost.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp3.smtp.bt.com [217.32.164.138])
	id QQpoyh01152
	for <mpls@UU.NET>; Sat, 15 Nov 2003 17:48:29 GMT
Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by i2kc03-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713);
	 Sat, 15 Nov 2003 17:48:28 +0000
Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713);
	 Sat, 15 Nov 2003 17:48:28 +0000
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"
Content-Transfer-Encoding: quoted-printable
Subject: RE: on the mpls oam framework 
Date: Sat, 15 Nov 2003 17:48:28 -0000
Message-ID: <0536FC9B908BEC4597EE721BE6A3538904EF2E4A@i2km07-ukbr.domain1.systemhost.net>
Thread-Topic: on the mpls oam framework 
thread-index: AcOrR71S4RO/uNmiRNGlQXusRtx1xgAV9zEw
To: <kireeti@juniper.net>, <dallan@nortelnetworks.com>
Cc: <mpls@UU.NET>
X-OriginalArrivalTime: 15 Nov 2003 17:48:28.0562 (UTC) FILETIME=[AD35FF20:01C3ABA0]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Kireeti Kompella wrote 15 November 2003 06:47
> Hi Dave,
>=20
> On Tue, 11 Nov 2003, David Allan wrote:
>=20
> > IMHO You are persisting in ignoring what you don't want to see.
>=20
> Speaking as a vendor:
>=20
> On mp2p: at least 90% of the MPLS deployments I've seen use LDP.
NH=3D> Does this make it 'right' then?  If the dominant vendor 'does =
this' then your conclusions are hardly surprising.  Most of the world =
also uses MS Windows/applications too.....my PC crashes nearly every =
day....I wish I could sort/change it but I can't.  Market dominance is a =
very powerful vehicle IMO ;-)
>=20
> On ECMP: many providers ask us explicitly for ECMP.  On the other
> hand, no provider that I know (other than BT) of has complained
> about ECMP and asked us to turn it off.
NH=3D> ECMP is a *consequence* of LDP because one cannot control the =
routing.
>=20
> On PHP: two providers (one being BT) have complained about PHP, out
> of all the providers I've talked to about MPLS (about 3%).
NH=3D> You live with what you have been given by the dominant =
vendors....again this does not make it right.  Can you tell me how many =
operators actually asked for PHP (or even LDP) as a requirement in the =
1st place, as I don't know of any network/service problem it solves?

regards, Neil


From owner-mpls@UU.NET  Sat Nov 15 13:06: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 NAA14400
	for <mpls-archive@lists.ietf.org>; Sat, 15 Nov 2003 13:06:21 -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 QQpoyi04070
	for <mpls-archive@lists.ietf.org>; Sat, 15 Nov 2003 18:06: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 QQpoyi03995;
	Sat, 15 Nov 2003 18:06:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoyh01797
	for mpls-outgoing; Sat, 15 Nov 2003 17:49: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 QQpoyh01787
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 15 Nov 2003 17:49:08 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 QQpoyh12617
	for <mpls@UU.NET>; Sat, 15 Nov 2003 17:48:30 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 QQpoyh01153
	for <mpls@UU.NET>; Sat, 15 Nov 2003 17:48:29 GMT
Received: from i2kc03-ukbr.domain1.systemhost.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp3.smtp.bt.com [217.32.164.138])
	id QQpoyh01126
	for <mpls@UU.NET>; Sat, 15 Nov 2003 17:48:28 GMT
Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by i2kc03-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713);
	 Sat, 15 Nov 2003 17:48:27 +0000
Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713);
	 Sat, 15 Nov 2003 17:48:27 +0000
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"
Content-Transfer-Encoding: quoted-printable
Subject: RE: on the mpls oam framework
Date: Sat, 15 Nov 2003 17:48:27 -0000
Message-ID: <0536FC9B908BEC4597EE721BE6A3538904EF2E49@i2km07-ukbr.domain1.systemhost.net>
Thread-Topic: on the mpls oam framework
thread-index: AcOrQyHFimpQ9jxrQXaYYT99nY3mmQAWTmuQ
To: <kireeti@juniper.net>, <loa@pi.se>
Cc: <mpls@UU.NET>, <swallow@cisco.com>, <zinin@psg.com>
X-OriginalArrivalTime: 15 Nov 2003 17:48:27.0687 (UTC) FILETIME=[ACB07B70:01C3ABA0]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Kireeti wrote 15 November 2003 06:15

> On Mon, 10 Nov 2003 neil.2.harrison@bt.com wrote:
>=20
> > ie one can't fix what is wrong/missing in MPLS by
> > asking Dave to redo his paper...as its simply a statement of fact
> > and is therefore 'right'.
>=20
> As co-author of the wrong approach, I will be happy to help Tom with
> his wrong OAM framework for the wrong MPLS architecture we so wrongly
> have.  We would be wrong to make Dave wrong when he is so right.
>=20
> Kireeti.
> -------
Kireeti.....if you were serious about this I, and many folks here, would =
be grateful.  The simple fact of the matter is this:

-	a cnls mode *must* have a network-unique SA/DA pair in each traffic =
unit.  Most fundamemtal of all, this means the cnls mode always =
*multiplexes and never merges* traffic units.  This observation is =
significant, and determines how this mode is specified and how it is =
managed, eg OAM is one such facet.

-	a co-ps mode does not have a network-unique SA/DA pair in each traffic =
unit...it usually only has a link-unique 'DA' (link-connection ID) per =
hop.  These need stitching together and have to belong to some parent =
trail connection entity.....and further, until they are, the =
link-connection IDs have no network currency.  This means that only p2p =
and p2mp topologies are allowed in this mode, ie to ensure source =
uniqueness.  Sure you can do mp2p but this results in merging and means =
we lose sight of the source.  The only way to recover from the effects =
of merging is either:
	* by running a further p2p client connection entity above the mp2p =
server connection entity, or
	* by a priori knowledge that the direct client is cnls and posseses a =
network-unique DA/DA pair per traffic unit.
Again, the nature of the co-ps traffic unit has a fundamantal bearing on =
how this mode must be specified and how it requires to be managed, eg =
OAM is one such facet, and it is every different to the cnls mode.  So =
when one constructs a mp2p connection entity in the co-ps mode then one =
creates some significant traffic and fault-management problems that do =
not occur in either (i)  co-ps p2p and p2mp topologies or (ii) the cnls =
mode.

Now the above are simply facts of the 2 modes that neither I, nor you, =
can change.  To ignore them however and somehow pretend its not true or =
not significant is not very sensible IMO.

PHP is something else entirely, ie stop the trail 1-hop short of its =
true end-point.  However, moving the trail termination function like =
this does create problems as I am sure you well know.

Dave's document is merely stating the factual consequence of things like =
mp2p merging and PHP on the OAM behaviour. =20

regards, Neil


From owner-mpls@UU.NET  Sat Nov 15 14:41:43 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 OAA16391
	for <mpls-archive@lists.ietf.org>; Sat, 15 Nov 2003 14:41: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 QQpoyo14567
	for <mpls-archive@lists.ietf.org>; Sat, 15 Nov 2003 19: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 QQpoyo14542;
	Sat, 15 Nov 2003 19:41:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoyn18077
	for mpls-outgoing; Sat, 15 Nov 2003 19:24: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 QQpoyn18072
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 15 Nov 2003 19:24:52 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 QQpoyn17388
	for <mpls@UU.NET>; Sat, 15 Nov 2003 19:23: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 QQpoyn02782
	for <mpls@UU.NET>; Sat, 15 Nov 2003 19:23:27 GMT
Received: from smtp107.mail.sc5.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: smtp107.mail.sc5.yahoo.com [66.163.169.227])
	id QQpoyn02762
	for <mpls@UU.NET>; Sat, 15 Nov 2003 19:23:26 GMT
Received: from ts46-01-qdr3166.mrgnhll.ca.charter.com (HELO yahoo.com) (m?seery@68.118.70.100 with plain)
  by smtp-v1.mail.vip.sc5.yahoo.com with SMTP; 15 Nov 2003 19:23:25 -0000
Message-ID: <3FB67D2E.1080000@yahoo.com>
Date: Sat, 15 Nov 2003 11:23:26 -0800
From: mark seery <m_seery@yahoo.com>
Reply-To: m_seery@yahoo.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Loa Andersson <loa@pi.se>
CC: MPLS wg <mpls@UU.NET>, Kireeti Kompella <kireeti@juniper.net>
Subject: Re: on the mpls oam framework
References: <20031115084913.66386.qmail@web13507.mail.yahoo.com> <3FB64E75.7070600@pi.se>
In-Reply-To: <3FB64E75.7070600@pi.se>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Loa Andersson wrote:

> Working group, Mark and Kireeti,
>
> it is known that irony is an hard art to pursue.
> Kireeti, Mark missed the irony in your mail.
> Mark, after doing that you had a go on the same method.
>
> I think I can understand both of your stating points, however
> just now it is not helpful.
>
> Let me put the wg chair hat on and try to sort some of the
> issues out.
>
Loa, thankyou for putting on your wg chair hat. I appreciate and respect 
you doing so. I apologise to the group if my comments were not helpful, 
and specifically to Kireeti if he thought them to be of a personal 
nature, I have the highest respect for Kireeti.

I would like to observe that this mailing list has endured more than its 
fair share of "irony" this week, including some from at least one of the 
chairs. I would like to encourage both chairs to step on the "irony" 
brakes often, in a non-partisan way, and as soon as it appears. This, 
IMHO, will become particularly important as we move in to an era where 
chairs can suspend posting privilieges. It is great to have power, but 
power exercised in a non-partisan and impulsive way becomes tyranny. I 
would also like to encourage the chairs to consider that the IETF is a 
very open body - which many respect and believe is its fundamental 
strength (as I personally do). But all should keep in mind that it is 
open to everyone in our large community of people who believe in the 
power of networks; and that all are free to observe our comments and 
work when ever they desire. Some of these people are people who we have 
fundamental disagreements with, but none the less need to partner with 
to achieve our goals. Because of the way the structure or our industry 
evolved, it was innevitable that competitive forces would arise between 
major groups. As our industry structure continues to evolve, we 
(everyone in the industry) need to as well.

I agree with you Loa that is not helpful for anyone to assert they have 
perfect vision and would encourage all to not do this; but I would also 
observe few if any of us are free from this sin - it is the very nature 
of testing your ideas against those of your peers. It is the very nature 
of peer review. It is the very nature of having the courage of your 
convictions. Let's celebrate everyone's courage for their convictions 
while encouraging them to provide specific, relevant, and appropriate 
feedback.



From owner-mpls@UU.NET  Sat Nov 15 17:02: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 RAA21348
	for <mpls-archive@lists.ietf.org>; Sat, 15 Nov 2003 17:02: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 QQpoyy01078
	for <mpls-archive@lists.ietf.org>; Sat, 15 Nov 2003 22:02: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 QQpoyy00838;
	Sat, 15 Nov 2003 22:02:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoyw07157
	for mpls-outgoing; Sat, 15 Nov 2003 21:39: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 QQpoyw07152
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 15 Nov 2003 21:39:50 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 QQpoyw26847
	for <mpls@UU.NET>; Sat, 15 Nov 2003 21: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 QQpoyw25144
	for <mpls@UU.NET>; Sat, 15 Nov 2003 21:37:22 GMT
Received: from kummer.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint2.juniper.net [207.17.136.150])
	id QQpoyw25131
	for <mpls@UU.NET>; Sat, 15 Nov 2003 21:37:21 GMT
Received: from kummer.juniper.net (localhost [127.0.0.1])
	by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id hAFLbJda052371;
	Sat, 15 Nov 2003 13:37:19 -0800 (PST)
	(envelope-from kireeti@juniper.net)
Received: from localhost (kireeti@localhost)
	by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id hAFLbIOI052368;
	Sat, 15 Nov 2003 13:37:19 -0800 (PST)
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
Date: Sat, 15 Nov 2003 13:37:18 -0800 (PST)
From: Kireeti Kompella <kireeti@juniper.net>
To: Loa Andersson <loa@pi.se>
cc: MPLS wg <mpls@UU.NET>
Subject: Re: on the mpls oam framework
In-Reply-To: <3FB64E75.7070600@pi.se>
Message-ID: <20031115133005.J52313@kummer.juniper.net>
References: <20031115084913.66386.qmail@web13507.mail.yahoo.com>
 <3FB64E75.7070600@pi.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Loa,

On Sat, 15 Nov 2003, Loa Andersson wrote:

> I think I can understand both of your stating points, however
> just now it is not helpful.

Sorry, didn't mean to make your life harder.

> I guess that there are similar procedures in the ITU, if I were to tell
> that they are not develop things according a particular document published
> by the IETF, they would change their standards, I guess that I at least
> would have to write a contribution to tell them why this would be a
> good idea.

It's nice to think that the ITU would change their standards.  Please,
please do write such a document (or Liaison) to the ITU.

> We are all for an healthy development of mpls, what we have are two
> different
> opinions of what that development looks like. My task here is to find a path
> that leads to wg consensus.

I would like to point out (in case someone misreads Loa's email) that
MPLS development is *not* at issue here.  The issue is what we do with
the OAM framework and perhaps OAM direction.

> I simply fail to understand why this has initiated this type of discussion
> on the list.

It's too tempting :-)  But I promise to be good ... for a week, at least.

Kireeti.
-------


From owner-mpls@UU.NET  Sat Nov 15 17:29: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 RAA22248
	for <mpls-archive@lists.ietf.org>; Sat, 15 Nov 2003 17:29: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 QQpoyz06498
	for <mpls-archive@lists.ietf.org>; Sat, 15 Nov 2003 22:29: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 QQpoyz06455;
	Sat, 15 Nov 2003 22:29:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpoyy27866
	for mpls-outgoing; Sat, 15 Nov 2003 22:06: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 QQpoyy27686
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 15 Nov 2003 22:05: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 QQpoyy17328
	for <mpls@UU.NET>; Sat, 15 Nov 2003 22:03:42 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 QQpoyy29217
	for <mpls@UU.NET>; Sat, 15 Nov 2003 22:03:42 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 QQpoyy29193
	for <mpls@UU.NET>; Sat, 15 Nov 2003 22:03:41 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAFM3MF27410;
	Sat, 15 Nov 2003 17:03:22 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <W3H89AKC>; Sat, 15 Nov 2003 17:03:22 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D02B927CE@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'neil.2.harrison@bt.com'" <neil.2.harrison@bt.com>, kireeti@juniper.net,
        loa@pi.se
Cc: mpls@UU.NET, swallow@cisco.com, zinin@psg.com
Subject: RE: on the mpls oam framework
Date: Sat, 15 Nov 2003 17:03:21 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-mpls@UU.NET
Precedence: bulk

Whoa, meme merde, autre jour ;-)

One of the goals of the framework draft we brought forward was to facilitate
understanding of the implications of particular aspects of the architecture
when it came to measurement and fault detection. Some things were
impossible...end of story. We can enumerate this individually by solution if
we want to go down that route, but ultimately that analysis in some form is
required if the document is to have any semblance of intellectual and
practical honesty and be useful to the industry. Those particular aspects in
whatever form they take are important to bring forward, as simply
enumerating the solution space without "criticism" is useless. To also
pretend these things do not have impact because an extra million lines of
code, a few generations of Moores law and protocol design can sort it out is
also IMO not useful.

I have an idea of what consitutes data plane OAM, and thought that had been
delegated to the ITU with RFC 3429. I also thought Scott had a pretty clear
demarcation in viewing ping and traceroute as IETF balliwack but the other
"telco" stuff out of scope. Clearly that has changed and what that means
needs some elucidation. That the can of worms has been reopened at the IETF
is clear, and it behooves me to chime in, but I'm not clear on precisely why
it has been reopened.

We already have LSP-PING, LSR-SELF-TEST (a ping derivative), VCCV (a ping++
derivative) none of which so far would appear to have required charter
changes by the previous operating definition. We also now have BFD which is
more in the 1711 class of tools. On the other side of the house we have
Y.1710/11/12/20/fec-cv. With the exception of perhaps wrapping this stuff in
a bit of context, what extra needs doing?

cheers
Dave




From owner-mpls@UU.NET  Sat Nov 15 19:48: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 TAA27237
	for <mpls-archive@lists.ietf.org>; Sat, 15 Nov 2003 19:48: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 QQpozj08269
	for <mpls-archive@lists.ietf.org>; Sun, 16 Nov 2003 00:48: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 QQpozj08150;
	Sun, 16 Nov 2003 00:48:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpozh18226
	for mpls-outgoing; Sun, 16 Nov 2003 00:23: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 QQpozh18221
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 16 Nov 2003 00:23:41 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 QQpozh16650
	for <mpls@UU.NET>; Sun, 16 Nov 2003 00:23: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 QQpozh09305
	for <mpls@UU.NET>; Sun, 16 Nov 2003 00:23:22 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 QQpozh09293
	for <mpls@UU.NET>; Sun, 16 Nov 2003 00:23:22 GMT
Received: by newdev.harvard.edu (Postfix, from userid 501)
	id 18A467A282; Sat, 15 Nov 2003 19:22:58 -0500 (EST)
To: mpls@UU.NET
Subject: RE: on the mpls oam framework
Message-Id: <20031116002258.18A467A282@newdev.harvard.edu>
Date: Sat, 15 Nov 2003 19:22:58 -0500 (EST)
From: sob@harvard.edu (Scott Bradner)
Sender: owner-mpls@UU.NET
Precedence: bulk


> I have an idea of what consitutes data plane OAM, and thought that had been
> delegated to the ITU with RFC 3429. I also thought Scott had a pretty clear
> demarcation in viewing ping and traceroute as IETF balliwack but the other
> "telco" stuff out of scope.

out of scope mostly because it was out of interest for many in the IETF
(we had such fun discussions on the topic :-) )

Scott


From owner-mpls@UU.NET  Sun Nov 16 07:38:32 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 HAA26941
	for <mpls-archive@lists.ietf.org>; Sun, 16 Nov 2003 07:38:31 -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 QQppbe15232
	for <mpls-archive@lists.ietf.org>; Sun, 16 Nov 2003 12:38: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 QQppbe14909;
	Sun, 16 Nov 2003 12:38:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppbd05725
	for mpls-outgoing; Sun, 16 Nov 2003 12:16: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 QQppbd05720
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 16 Nov 2003 12:16: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 QQppbc28391
	for <mpls@UU.NET>; Sun, 16 Nov 2003 12:14: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 QQppbc22006
	for <mpls@UU.NET>; Sun, 16 Nov 2003 12:14:17 GMT
Received: from relay0.netfirms.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: m0.netfirms.com [209.171.43.51])
	id QQppbc21998
	for <mpls@UU.NET>; Sun, 16 Nov 2003 12:14:16 GMT
Received: (qmail 28439 invoked from network); 16 Nov 2003 12:14:07 -0000
Received: from du-069-0379.access.clara.net (HELO Puppy) (217.158.145.125)
  by 0 with SMTP; 16 Nov 2003 12:14:07 -0000
Message-ID: <021201c3ac3b$266ea820$db818182@Puppy>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <curtis@fictitious.org>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
References: <200311151325.hAFDP6hO046450@workhorse.fictitious.org>
Subject: Re: Soft/hard pre-emption 
Date: Sun, 16 Nov 2003 12:14:07 -0000
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.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Curtis,

Don't worry.
I will publish a summary as soon as people have had a chance to respond.
It only been a few days, and many people were travelling.

Additionally, I have had some problems with personal emails. If anyone responded to me
privately, can I ask them to re-send just in case.

Thanks,
Adrian
----- Original Message ----- 
From: "Curtis Villamizar" <curtis@workhorse.fictitious.org>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Sent: Saturday, November 15, 2003 1:25 PM
Subject: Re: Soft/hard pre-emption


>
> In message <010701c3a869$f1437bf0$db818182@Puppy>, "Adrian Farrel" writes:
> > As my first step in resolving this issue I would like to conduct a brief surv
> > ey amongst
> > implementors.
> >
> > Please feel free to respond to me off-list and in confidence. If you do not w
> > ant your
> > information shared more widely, please state that explicitly in your email.
> >
> > Also, please note that this questionnaire is NOT a discussion of what is the
> > correct
> > behavior. It is simply collecting information about interpretation of RFCs 22
> > 05 and 3209.
> >
> > Thanks,
> > Adrian
> >
> > Questions:
> >
> > 1. When your implementation receives a PathErr message indicating pre-emption
> >  for an
> > established LSP, does it tear the LSP (i.e. release labels) or only release r
> > esources
> > (i.e. leave the LSP in place as 'best effort')?
> > In other words, is your default behavior hard or soft pre-emption?
> >
> > 2. When your implementation receives any other (non-notify) PathErr for an es
> > tablished
> > LSP, does it tear the LSP (i.e. release labels) or leave it in place?
> >
> > 3. Is your code carrying live traffic, in lab tests, or in development?
> >
> > 4. If deployed, can you give me a feeling for the number of LSRs in the field
> >  (just an
> > order of magnitude)?
> >
> > Thanks,
> > Adrian
>
>
>
> I don't remember seeing a summary of answers on this.
>
> Curtis
>



From owner-mpls@UU.NET  Sun Nov 16 10:18: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 KAA00320
	for <mpls-archive@lists.ietf.org>; Sun, 16 Nov 2003 10:17: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 QQppbp27130
	for <mpls-archive@lists.ietf.org>; Sun, 16 Nov 2003 15:18: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 QQppbp27091;
	Sun, 16 Nov 2003 15:18:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppbn26828
	for mpls-outgoing; Sun, 16 Nov 2003 14:56: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 QQppbn26823
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 16 Nov 2003 14:56:41 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 QQppbn27175
	for <mpls@uu.net>; Sun, 16 Nov 2003 14:55: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 QQppbn01017
	for <mpls@uu.net>; Sun, 16 Nov 2003 14:55:18 GMT
Received: from sj-iport-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71])
	id QQppbn01009
	for <mpls@uu.net>; Sun, 16 Nov 2003 14:55:18 GMT
Received: from cisco.com (171.71.177.238)
  by sj-iport-2.cisco.com with ESMTP; 16 Nov 2003 06:58:25 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAGEtEtg023088
	for <mpls@uu.net>; Sun, 16 Nov 2003 06:55:14 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEA26309;
	Sun, 16 Nov 2003 09:55:13 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAGEtD525399 for mpls@uu.net; Sun, 16 Nov 2003 09:55:13 -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 QQppbn26560
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 16 Nov 2003 14:54:21 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 QQppbn22105
	for <mpls@uu.net>; Sun, 16 Nov 2003 14:53: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 QQppbn16872
	for <mpls@uu.net>; Sun, 16 Nov 2003 14:53:06 GMT
Received: from sj-iport-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71])
	id QQppbn16864
	for <mpls@uu.net>; Sun, 16 Nov 2003 14:53:05 GMT
Received: from cisco.com (171.71.177.237)
  by sj-iport-2.cisco.com with ESMTP; 16 Nov 2003 06:56:12 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAGEqlAv002510
	for <mpls@UU.NET>; Sun, 16 Nov 2003 06:53:02 -0800 (PST)
Received: from tnadeauw2k02 (che-vpn-cluster-1-120.cisco.com [10.86.240.120])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEA26287;
	Sun, 16 Nov 2003 09:52:47 -0500 (EST)
Reply-To: <tnadeau@cisco.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
To: <mpls@UU.NET>
Subject: RE: on the mpls oam framework
Date: Sun, 16 Nov 2003 09:52:34 -0500
Organization: Cisco Systems, inc.
Message-ID: <00bb01c3ac51$48921ed0$6701a8c0@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: <FFFC48AEAA5F7447929F4F0D93FCC12D02B927CE@zcard031.ca.nortel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


>We already have LSP-PING, LSR-SELF-TEST (a ping derivative), 
>VCCV (a ping++
>derivative) none of which so far would appear to have required charter
>changes by the previous operating definition. We also now have 
>BFD which is
>more in the 1711 class of tools. On the other side of the house we have
>Y.1710/11/12/20/fec-cv. With the exception of perhaps wrapping 
>this stuff in a bit of context, what extra needs doing?

	Dave, 

	Your statement seems to contain a bit of hubris if you ask
me. I remember a statement like this in the not-so-distant past 
made by (I think) Mr. Gates, "...why would you need more than 258k 
of RAM in a PC?"

	--Tom





From owner-mpls@UU.NET  Sun Nov 16 11:30: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 LAA01536
	for <mpls-archive@lists.ietf.org>; Sun, 16 Nov 2003 11:30: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 QQppbu22656
	for <mpls-archive@lists.ietf.org>; Sun, 16 Nov 2003 16:30: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 QQppbu22537;
	Sun, 16 Nov 2003 16:30:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppbs10438
	for mpls-outgoing; Sun, 16 Nov 2003 16:06: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 QQppbs10416
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 16 Nov 2003 16:06:19 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 QQppbs08871
	for <mpls@uu.net>; Sun, 16 Nov 2003 16:03: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 QQppbs03621
	for <mpls@uu.net>; Sun, 16 Nov 2003 16:03:48 GMT
Received: from sj-iport-4.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-4.cisco.com [171.68.10.86])
	id QQppbs03607
	for <mpls@uu.net>; Sun, 16 Nov 2003 16:03:48 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAGG3hw5013109
	for <mpls@uu.net>; Sun, 16 Nov 2003 08:03:44 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEA27504;
	Sun, 16 Nov 2003 11:03:42 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAGG3gO28573 for mpls@uu.net; Sun, 16 Nov 2003 11:03:42 -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 QQppbs02297
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 16 Nov 2003 16:02: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 QQppbs22667
	for <mpls@uu.net>; Sun, 16 Nov 2003 16: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 QQppbs21610
	for <mpls@uu.net>; Sun, 16 Nov 2003 16:01:44 GMT
Received: from ams-iport-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ams-iport-1.cisco.com [144.254.74.5])
	id QQppbs21589
	for <mpls@uu.net>; Sun, 16 Nov 2003 16:01:43 GMT
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 16 Nov 2003 16:59:15 +0100
Received: from xbe-ams-312.cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hAGG1Vnx025003;
	Sun, 16 Nov 2003 17:01:31 +0100 (MET)
Received: from xbe-ams-313.cisco.com ([144.254.228.203]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Sun, 16 Nov 2003 17:01:41 +0100
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: on the mpls oam framework
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Date: Sun, 16 Nov 2003 17:01:40 +0100
Message-ID: <3C775706078CA347A8653E03E1469106016C1FBF@xbe-ams-313.cisco.com>
Thread-Topic: on the mpls oam framework
Thread-Index: AcOryFRCI18pDfw5S3a1SvOm8C26sgAkPTEg
From: "Monique Morrow (mmorrow)" <mmorrow@cisco.com>
To: "David Allan" <dallan@nortelnetworks.com>
Cc: <mpls@UU.NET>, "George Swallow (swallow)" <swallow@cisco.com>,
        <zinin@psg.com>, <neil.2.harrison@bt.com>, <kireeti@juniper.net>,
        <loa@pi.se>
X-OriginalArrivalTime: 16 Nov 2003 16:01:41.0670 (UTC) FILETIME=[ECD19C60:01C3AC5A]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

"Whoa, meme merde, autre jour ;-)"

C'est quoi comme langage cher David??

"We already have LSP-PING, LSR-SELF-TEST (a ping derivative), VCCV (a =
ping++
derivative) none of which so far would appear to have required charter
changes by the previous operating definition. We also now have BFD which =
is
more in the 1711 class of tools. On the other side of the house we have
Y.1710/11/12/20/fec-cv. With the exception of perhaps wrapping this =
stuff in
a bit of context, what extra needs doing?"

One minor nit:  y.1712, fec-cv are currently draft ITU-T recommendations =
and have not yet attained approved recommendation status yet as these =
are still being discussed -- certainly shall be this week at the interim =
ITU-T meeting in Geneva - should also add same for y.1711 revised btw.

Amicalement,

/monique



-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of David =
Allan
Sent: 15 November 2003 23:03
To: 'neil.2.harrison@bt.com'; kireeti@juniper.net; loa@pi.se
Cc: mpls@UU.NET; George Swallow (swallow); zinin@psg.com
Subject: RE: on the mpls oam framework


Whoa, meme merde, autre jour ;-)

One of the goals of the framework draft we brought forward was to =
facilitate
understanding of the implications of particular aspects of the =
architecture
when it came to measurement and fault detection. Some things were
impossible...end of story. We can enumerate this individually by =
solution if
we want to go down that route, but ultimately that analysis in some form =
is
required if the document is to have any semblance of intellectual and
practical honesty and be useful to the industry. Those particular =
aspects in
whatever form they take are important to bring forward, as simply
enumerating the solution space without "criticism" is useless. To also
pretend these things do not have impact because an extra million lines =
of
code, a few generations of Moores law and protocol design can sort it =
out is
also IMO not useful.

I have an idea of what consitutes data plane OAM, and thought that had =
been
delegated to the ITU with RFC 3429. I also thought Scott had a pretty =
clear
demarcation in viewing ping and traceroute as IETF balliwack but the =
other
"telco" stuff out of scope. Clearly that has changed and what that means
needs some elucidation. That the can of worms has been reopened at the =
IETF
is clear, and it behooves me to chime in, but I'm not clear on precisely =
why
it has been reopened.

We already have LSP-PING, LSR-SELF-TEST (a ping derivative), VCCV (a =
ping++
derivative) none of which so far would appear to have required charter
changes by the previous operating definition. We also now have BFD which =
is
more in the 1711 class of tools. On the other side of the house we have
Y.1710/11/12/20/fec-cv. With the exception of perhaps wrapping this =
stuff in
a bit of context, what extra needs doing?

cheers
Dave




From owner-mpls@UU.NET  Sun Nov 16 13:12: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 NAA03106
	for <mpls-archive@lists.ietf.org>; Sun, 16 Nov 2003 13:12: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 QQppca12070
	for <mpls-archive@lists.ietf.org>; Sun, 16 Nov 2003 18:12: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 QQppca11985;
	Sun, 16 Nov 2003 18:12:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppbz09373
	for mpls-outgoing; Sun, 16 Nov 2003 17:50: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 QQppbz09368
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 16 Nov 2003 17:50: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 QQppbz12835
	for <mpls@UU.NET>; Sun, 16 Nov 2003 17:50: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 QQppbz13416
	for <mpls@UU.NET>; Sun, 16 Nov 2003 17:50:18 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 QQppbz13400
	for <mpls@UU.NET>; Sun, 16 Nov 2003 17:50:17 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAGHnqG17915;
	Sun, 16 Nov 2003 12:49:52 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <W3H89D7A>; Sun, 16 Nov 2003 12:49:53 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D02B927D2@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'Monique Morrow (mmorrow)'" <mmorrow@cisco.com>
Cc: mpls@UU.NET, "George Swallow (swallow)" <swallow@cisco.com>, zinin@psg.com,
        neil.2.harrison@bt.com, kireeti@juniper.net, loa@pi.se
Subject: RE: on the mpls oam framework
Date: Sun, 16 Nov 2003 12:49:49 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-mpls@UU.NET
Precedence: bulk

Bonjour Monique:

> "Whoa, meme merde, autre jour ;-)"
> 
> C'est quoi comme langage cher David??

Comes from a long Euro-travel cycle ;-)


> One minor nit:  y.1712, fec-cv are currently draft ITU-T 
> recommendations and have not yet attained approved 
> recommendation status yet as these are still being discussed 

Still up in the air like everything else on the list ;-)

> certainly shall be this week at the interim ITU-T meeting in Geneva

I'm already there....

rgds
Dave


> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf 
> Of David Allan
> Sent: 15 November 2003 23:03
> To: 'neil.2.harrison@bt.com'; kireeti@juniper.net; loa@pi.se
> Cc: mpls@UU.NET; George Swallow (swallow); zinin@psg.com
> Subject: RE: on the mpls oam framework
> 
> 
> Whoa, meme merde, autre jour ;-)
> 
> One of the goals of the framework draft we brought forward 
> was to facilitate understanding of the implications of 
> particular aspects of the architecture when it came to 
> measurement and fault detection. Some things were 
> impossible...end of story. We can enumerate this individually 
> by solution if we want to go down that route, but ultimately 
> that analysis in some form is required if the document is to 
> have any semblance of intellectual and practical honesty and 
> be useful to the industry. Those particular aspects in 
> whatever form they take are important to bring forward, as 
> simply enumerating the solution space without "criticism" is 
> useless. To also pretend these things do not have impact 
> because an extra million lines of code, a few generations of 
> Moores law and protocol design can sort it out is also IMO not useful.
> 
> I have an idea of what consitutes data plane OAM, and thought 
> that had been delegated to the ITU with RFC 3429. I also 
> thought Scott had a pretty clear demarcation in viewing ping 
> and traceroute as IETF balliwack but the other "telco" stuff 
> out of scope. Clearly that has changed and what that means 
> needs some elucidation. That the can of worms has been 
> reopened at the IETF is clear, and it behooves me to chime 
> in, but I'm not clear on precisely why it has been reopened.
> 
> We already have LSP-PING, LSR-SELF-TEST (a ping derivative), 
> VCCV (a ping++
> derivative) none of which so far would appear to have 
> required charter changes by the previous operating 
> definition. We also now have BFD which is more in the 1711 
> class of tools. On the other side of the house we have 
> Y.1710/11/12/20/fec-cv. With the exception of perhaps 
> wrapping this stuff in a bit of context, what extra needs doing?
> 
> cheers
> Dave
> 
> 
> 


From owner-mpls@UU.NET  Sun Nov 16 17:52: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 RAA09713
	for <mpls-archive@lists.ietf.org>; Sun, 16 Nov 2003 17:52:28 -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 QQppct25814
	for <mpls-archive@lists.ietf.org>; Sun, 16 Nov 2003 22:52:40 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 QQppct25748;
	Sun, 16 Nov 2003 22:52:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppcr07476
	for mpls-outgoing; Sun, 16 Nov 2003 22:29: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 QQppcr07464
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 16 Nov 2003 22:29: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 QQppcr03618
	for <mpls@uu.net>; Sun, 16 Nov 2003 22:26: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 QQppcr09129
	for <mpls@uu.net>; Sun, 16 Nov 2003 22:26:57 GMT
Received: from sj-iport-5.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-5.cisco.com [171.68.10.87])
	id QQppcr09115
	for <mpls@uu.net>; Sun, 16 Nov 2003 22:26:57 GMT
Received: from cisco.com (64.102.124.13)
  by sj-iport-5.cisco.com with ESMTP; 16 Nov 2003 14:27:46 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAGMQrDM009556
	for <mpls@uu.net>; Sun, 16 Nov 2003 17:26:53 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEA32690;
	Sun, 16 Nov 2003 17:26:52 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAGMQqQ03827 for mpls@uu.net; Sun, 16 Nov 2003 17:26: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 QQppcr07161
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 16 Nov 2003 22:25: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 QQppcr18807
	for <mpls@UU.NET>; Sun, 16 Nov 2003 22:23:50 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 QQppcr14360
	for <mpls@UU.NET>; Sun, 16 Nov 2003 22:23: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 QQppcr14335
	for <mpls@UU.NET>; Sun, 16 Nov 2003 22:23:48 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.8p1/8.12.8) with ESMTP id hAGMOPf1002678;
	Sun, 16 Nov 2003 17:24:25 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311162224.hAGMOPf1002678@workhorse.fictitious.org>
To: neil.2.harrison@bt.com
cc: kireeti@juniper.net, dallan@nortelnetworks.com, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: on the mpls oam framework 
In-reply-to: Your message of "Sat, 15 Nov 2003 17:48:28 GMT."
             <0536FC9B908BEC4597EE721BE6A3538904EF2E4A@i2km07-ukbr.domain1.systemhost.net> 
Date: Sun, 16 Nov 2003 17:24:25 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <0536FC9B908BEC4597EE721BE6A3538904EF2E4A@i2km07-ukbr.domain1.system
host.net>, neil.2.harrison@bt.com writes:
> Kireeti Kompella wrote 15 November 2003 06:47
> > Hi Dave,
> > 
> > On Tue, 11 Nov 2003, David Allan wrote:
> > 
> > > IMHO You are persisting in ignoring what you don't want to see.
> > 
> > Speaking as a vendor:
> > 
> > On mp2p: at least 90% of the MPLS deployments I've seen use LDP.
> NH=> Does this make it 'right' then?  If the dominant vendor 'does this' then
>  your conclusions are hardly surprising.  Most of the world also uses MS Wind
> ows/applications too.....my PC crashes nearly every day....I wish I could sor
> t/change it but I can't.  Market dominance is a very powerful vehicle IMO ;-)
> > 
> > On ECMP: many providers ask us explicitly for ECMP.  On the other
> > hand, no provider that I know (other than BT) of has complained
> > about ECMP and asked us to turn it off.
> NH=> ECMP is a *consequence* of LDP because one cannot control the routing.
> > 
> > On PHP: two providers (one being BT) have complained about PHP, out
> > of all the providers I've talked to about MPLS (about 3%).
> NH=> You live with what you have been given by the dominant vendors....again 
> this does not make it right.  Can you tell me how many operators actually ask
> ed for PHP (or even LDP) as a requirement in the 1st place, as I don't know o
> f any network/service problem it solves?
> 
> regards, Neil


They are needed for other technical reasons that are out of scope for
the OAM framework.  As far as the OAM framework is concerned, they are
part of the architecture and widely deployed so they must be supported
by OAM tools.  It simply means that working with PHP and ECMP are
requirements for OAM.

You seem to have things backwards.  You have an OAM solution in mind
that doesn't work well with ECMP and PHP and want a OAM framework that
claims these are bad features.

This exercise includes stating requirements - and like it or not ECMP
and PHP are requirements for OAM and so is not requiring changes to
the forwarding plane.  The framework can then discuss a set of
solutions and their tradeoffs.  If a single solution (or set of
solutions) covers all requirements well, then any additional partial
solutions will be redundant.

Curtis



From owner-mpls@UU.NET  Sun Nov 16 18:09:23 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 SAA10663
	for <mpls-archive@lists.ietf.org>; Sun, 16 Nov 2003 18:09: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 QQppcu10225
	for <mpls-archive@lists.ietf.org>; Sun, 16 Nov 2003 23:09:31 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 QQppcu10066;
	Sun, 16 Nov 2003 23:09:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppct09176
	for mpls-outgoing; Sun, 16 Nov 2003 22:45: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 QQppct09170
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 16 Nov 2003 22:45:35 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 QQppcs24498
	for <mpls@uu.net>; Sun, 16 Nov 2003 22:43: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 QQppcs15638
	for <mpls@uu.net>; Sun, 16 Nov 2003 22:43:26 GMT
Received: from sj-iport-3.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72])
	id QQppcs15628
	for <mpls@uu.net>; Sun, 16 Nov 2003 22:43:25 GMT
Received: from cisco.com (171.71.177.237)
  by sj-iport-3.cisco.com with ESMTP; 16 Nov 2003 14:51:11 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAGMhMAt009528
	for <mpls@uu.net>; Sun, 16 Nov 2003 14:43:22 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEA33056;
	Sun, 16 Nov 2003 17:43:21 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAGMhLl04844 for mpls@uu.net; Sun, 16 Nov 2003 17:43: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 QQppcs08537
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 16 Nov 2003 22:41: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 QQppcs29613
	for <mpls@UU.NET>; Sun, 16 Nov 2003 22:41: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 QQppcs06337
	for <mpls@UU.NET>; Sun, 16 Nov 2003 22:41: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 QQppcs06316
	for <mpls@UU.NET>; Sun, 16 Nov 2003 22:41:30 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.8p1/8.12.8) with ESMTP id hAGMeUf1002720;
	Sun, 16 Nov 2003 17:40:30 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311162240.hAGMeUf1002720@workhorse.fictitious.org>
To: "David Allan" <dallan@nortelnetworks.com>
cc: "'neil.2.harrison@bt.com'" <neil.2.harrison@bt.com>, kireeti@juniper.net,
        loa@pi.se, mpls@UU.NET, swallow@cisco.com, zinin@psg.com
Reply-To: curtis@fictitious.org
Subject: Re: on the mpls oam framework 
In-reply-to: Your message of "Sat, 15 Nov 2003 17:03:21 EST."
             <FFFC48AEAA5F7447929F4F0D93FCC12D02B927CE@zcard031.ca.nortel.com> 
Date: Sun, 16 Nov 2003 17:40:30 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <FFFC48AEAA5F7447929F4F0D93FCC12D02B927CE@zcard031.ca.nortel.com>, "
David Allan" writes:
> Whoa, meme merde, autre jour ;-)
> 
> One of the goals of the framework draft we brought forward was to facilitate
> understanding of the implications of particular aspects of the architecture
> when it came to measurement and fault detection. Some things were
> impossible...end of story. We can enumerate this individually by solution if
> we want to go down that route, but ultimately that analysis in some form is
> required if the document is to have any semblance of intellectual and
> practical honesty and be useful to the industry. Those particular aspects in
> whatever form they take are important to bring forward, as simply
> enumerating the solution space without "criticism" is useless. To also
> pretend these things do not have impact because an extra million lines of
> code, a few generations of Moores law and protocol design can sort it out is
> also IMO not useful.
> 
> I have an idea of what consitutes data plane OAM, and thought that had been
> delegated to the ITU with RFC 3429. I also thought Scott had a pretty clear
> demarcation in viewing ping and traceroute as IETF balliwack but the other
> "telco" stuff out of scope. Clearly that has changed and what that means
> needs some elucidation. That the can of worms has been reopened at the IETF
> is clear, and it behooves me to chime in, but I'm not clear on precisely why
> it has been reopened.
> 
> We already have LSP-PING, LSR-SELF-TEST (a ping derivative), VCCV (a ping++
> derivative) none of which so far would appear to have required charter
> changes by the previous operating definition. We also now have BFD which is
> more in the 1711 class of tools. On the other side of the house we have
> Y.1710/11/12/20/fec-cv. With the exception of perhaps wrapping this stuff in
> a bit of context, what extra needs doing?
> 
> cheers
> Dave


Dave,

I never understood RFC3429 to be an endorsement of Y.1711 by the IETF
but rather an individual Informational RFC informing the community of
the ITU work and the IANA assignment only indicates that the IETF
would not stand in the way of the ITU work by failing to assign a
number.  You do recall that there was significant opposition to the
ITU approach which is why the original authors took the work out of
the IETF to the ITU and then later considerable discussion as to
whether to assign the reserved label number at all.

Curtis



From owner-mpls@UU.NET  Mon Nov 17 03:41: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 DAA05462
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 03:41: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 QQppeg21571
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 08:41: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 QQppeg21516;
	Mon, 17 Nov 2003 08:41:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppef08809
	for mpls-outgoing; Mon, 17 Nov 2003 08:21: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 QQppef08802
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 08:21: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 QQppef24750
	for <mpls@UU.NET>; Mon, 17 Nov 2003 08:20: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 QQppef24128
	for <mpls@UU.NET>; Mon, 17 Nov 2003 08:20:58 GMT
Received: from spear.nn.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [213.38.44.66])
	id QQppef24111
	for <mpls@UU.NET>; Mon, 17 Nov 2003 08:20:57 GMT
content-class: urn:content-classes:message
Subject: CR-LDP
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3ACE3.CAF84DFD"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Mon, 17 Nov 2003 08:21:25 -0000
Message-ID: <489D5170A085A145AA767008F5BCCD451FF140@spear.nn.com>
Thread-Topic: CR-LDP
Thread-Index: AcOs49q7QoEL3UyRSwO/9LgkN6im7g==
From: "David Wilkinson" <David.Wilkinson@nativenetworks.com>
To: <mpls@UU.NET>
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01C3ACE3.CAF84DFD
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

All,
=20
Can anyone give me a very quick update on the current status of CR-LDP - =
are we still looking at CR-LDP as a viable TE signaling protocol - I =
appear to have missed something
=20
Cheers,
=20
Dave


------_=_NextPart_001_01C3ACE3.CAF84DFD
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 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D541042008-17112003><FONT face=3DArial=20
size=3D2>All,</FONT></SPAN></DIV>
<DIV><SPAN class=3D541042008-17112003><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D541042008-17112003><FONT face=3DArial size=3D2>Can =
anyone give me a=20
very quick update on the current status of CR-LDP - are we still looking =
at=20
CR-LDP as a viable TE signaling protocol - I appear to have missed=20
something</FONT></SPAN></DIV>
<DIV><SPAN class=3D541042008-17112003><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D541042008-17112003><FONT face=3DArial=20
size=3D2>Cheers,</FONT></SPAN></DIV>
<DIV><SPAN class=3D541042008-17112003><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D541042008-17112003><FONT face=3DArial=20
size=3D2>Dave</FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT=20
face=3D"Times New Roman"><STRONG><SPAN=20
style=3D"FONT-SIZE: 11pt; mso-bidi-font-size: =
10.0pt"></SPAN></STRONG></FONT></P></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C3ACE3.CAF84DFD--


From owner-mpls@UU.NET  Mon Nov 17 03:48:15 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 DAA05638
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 03:48:15 -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 QQppeh18324
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 08:48: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 QQppeh18261;
	Mon, 17 Nov 2003 08:48:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppef09190
	for mpls-outgoing; Mon, 17 Nov 2003 08:26: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 QQppef09180
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 08:26: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 QQppef25282
	for <mpls@UU.NET>; Mon, 17 Nov 2003 08:26: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 QQppef00139
	for <mpls@UU.NET>; Mon, 17 Nov 2003 08:26:14 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 QQppef00127
	for <mpls@UU.NET>; Mon, 17 Nov 2003 08:26:13 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAH8Pu325268;
	Mon, 17 Nov 2003 03:25:56 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <W3H89HZT>; Mon, 17 Nov 2003 03:25:56 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D02B927D4@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>
Cc: "'neil.2.harrison@bt.com'" <neil.2.harrison@bt.com>, kireeti@juniper.net,
        loa@pi.se, mpls@UU.NET, swallow@cisco.com, zinin@psg.com
Subject: RE: on the mpls oam framework 
Date: Mon, 17 Nov 2003 03:25:51 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Curtis:

I wouldn't describe it as a ringing endorsement ;-). More a reflection of
the schimsm that the MPLS WG was not going to reach any sort of consensus on
OAM at the time as most folks considered it to be not required, did not
necessarily like the solutions etc. etc. etc. Now this topic seems to have
come forward to some degree and the question is what do we do.....

IMHO 1711 and 17fec-cv should be useful candidates. I understand some
concerns with the dataplane, and it would be useful if some of those issues
could be addressed. The key issue being primarily on how payload is
identified. The PW PID is an example of how this can be addressed without
fundamentally undoing the work, IMHO other options exist. 

cheers
Dave

> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] 
> Sent: Sunday, November 16, 2003 5:41 PM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: 'neil.2.harrison@bt.com'; kireeti@juniper.net; loa@pi.se; 
> mpls@UU.NET; swallow@cisco.com; zinin@psg.com
> Subject: Re: on the mpls oam framework 
> 
> 
> 
> In message 
> <FFFC48AEAA5F7447929F4F0D93FCC12D02B927CE@zcard031.ca.nortel.c
> om>, " David Allan" writes:
> > Whoa, meme merde, autre jour ;-)
> > 
> > One of the goals of the framework draft we brought forward was to 
> > facilitate understanding of the implications of particular 
> aspects of 
> > the architecture when it came to measurement and fault 
> detection. Some 
> > things were impossible...end of story. We can enumerate this 
> > individually by solution if we want to go down that route, but 
> > ultimately that analysis in some form is required if the 
> document is 
> > to have any semblance of intellectual and practical honesty and be 
> > useful to the industry. Those particular aspects in 
> whatever form they 
> > take are important to bring forward, as simply enumerating the 
> > solution space without "criticism" is useless. To also 
> pretend these 
> > things do not have impact because an extra million lines of code, a 
> > few generations of Moores law and protocol design can sort 
> it out is 
> > also IMO not useful.
> > 
> > I have an idea of what consitutes data plane OAM, and 
> thought that had 
> > been delegated to the ITU with RFC 3429. I also thought Scott had a 
> > pretty clear demarcation in viewing ping and traceroute as IETF 
> > balliwack but the other "telco" stuff out of scope. Clearly 
> that has 
> > changed and what that means needs some elucidation. That the can of 
> > worms has been reopened at the IETF is clear, and it behooves me to 
> > chime in, but I'm not clear on precisely why it has been reopened.
> > 
> > We already have LSP-PING, LSR-SELF-TEST (a ping 
> derivative), VCCV (a 
> > ping++
> > derivative) none of which so far would appear to have 
> required charter
> > changes by the previous operating definition. We also now 
> have BFD which is
> > more in the 1711 class of tools. On the other side of the 
> house we have
> > Y.1710/11/12/20/fec-cv. With the exception of perhaps 
> wrapping this stuff in
> > a bit of context, what extra needs doing?
> > 
> > cheers
> > Dave
> 
> 
> Dave,
> 
> I never understood RFC3429 to be an endorsement of Y.1711 by 
> the IETF but rather an individual Informational RFC informing 
> the community of the ITU work and the IANA assignment only 
> indicates that the IETF would not stand in the way of the ITU 
> work by failing to assign a number.  You do recall that there 
> was significant opposition to the ITU approach which is why 
> the original authors took the work out of the IETF to the ITU 
> and then later considerable discussion as to whether to 
> assign the reserved label number at all.
> 
> Curtis
> 


From owner-mpls@UU.NET  Mon Nov 17 05:38: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 FAA07614
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 05:38: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 QQppeo04111
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 10:38: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 QQppeo04090;
	Mon, 17 Nov 2003 10:38:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppen27057
	for mpls-outgoing; Mon, 17 Nov 2003 10:19: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 QQppen27052
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 10:19: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 QQppen09934
	for <mpls@UU.NET>; Mon, 17 Nov 2003 10:17:21 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 QQppen09358
	for <mpls@UU.NET>; Mon, 17 Nov 2003 10:17:20 GMT
Received: from i2kc04-ukbr.domain1.systemhost.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp4.smtp.bt.com [217.32.164.151])
	id QQppen09345
	for <mpls@UU.NET>; Mon, 17 Nov 2003 10:17:20 GMT
Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 17 Nov 2003 10:17:15 +0000
Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 17 Nov 2003 10:17:14 +0000
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"
Content-Transfer-Encoding: quoted-printable
Subject: RE: on the mpls oam framework 
Date: Mon, 17 Nov 2003 10:17:13 -0000
Message-ID: <0536FC9B908BEC4597EE721BE6A3538904EF2E54@i2km07-ukbr.domain1.systemhost.net>
Thread-Topic: on the mpls oam framework 
Thread-Index: AcOskEr0I9PDnTmIRjaqlueZ4358WABQQ1wg
To: <curtis@fictitious.org>
Cc: <kireeti@juniper.net>, <dallan@nortelnetworks.com>, <mpls@UU.NET>
X-OriginalArrivalTime: 17 Nov 2003 10:17:14.0278 (UTC) FILETIME=[F8819C60:01C3ACF3]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Curtis,
Curtis Villamizar wrote 16 November 2003 22:24
> In message=20
> <0536FC9B908BEC4597EE721BE6A3538904EF2E4A@i2km07-ukbr.domain1.system
> host.net>, neil.2.harrison@bt.com writes:
> > Kireeti Kompella wrote 15 November 2003 06:47
> > > Hi Dave,
> > >=20
> > > On Tue, 11 Nov 2003, David Allan wrote:
> > >=20
> > > > IMHO You are persisting in ignoring what you don't want to see.
> > >=20
> > > Speaking as a vendor:
> > >=20
> > > On mp2p: at least 90% of the MPLS deployments I've seen use LDP.
> > NH=3D> Does this make it 'right' then?  If the dominant=20
> vendor 'does this' then
> >  your conclusions are hardly surprising.  Most of the world=20
> also uses MS Wind
> > ows/applications too.....my PC crashes nearly every=20
> day....I wish I could sor
> > t/change it but I can't.  Market dominance is a very=20
> powerful vehicle IMO ;-)
> > >=20
> > > On ECMP: many providers ask us explicitly for ECMP.  On the other
> > > hand, no provider that I know (other than BT) of has complained
> > > about ECMP and asked us to turn it off.
> > NH=3D> ECMP is a *consequence* of LDP because one cannot=20
> control the routing.
> > >=20
> > > On PHP: two providers (one being BT) have complained=20
> about PHP, out
> > > of all the providers I've talked to about MPLS (about 3%).
> > NH=3D> You live with what you have been given by the dominant=20
> vendors....again=20
> > this does not make it right.  Can you tell me how many=20
> operators actually ask
> > ed for PHP (or even LDP) as a requirement in the 1st place,=20
> as I don't know o
> > f any network/service problem it solves?
> >=20
> > regards, Neil
>=20
>=20
> They are needed for other technical reasons that are out of scope for
> the OAM framework.
NH=3D> I'd like to hear of the operational/service reasons as to how =
this benefits operators.

>  As far as the OAM framework is concerned, they are
> part of the architecture
NH=3D> With all due respect, I don't really see any 'architecture'.  I =
see a technology that worries about its implications later, eg the =
recent ECMP-hack/PWE3 aliasing problem.  G.805 and G.809 define formal =
functional architectures for the co-cs, co-ps and cnls modes.  And they =
have been proved very useful for >10 years now.

> and widely deployed so they must be supported
> by OAM tools.
NH=3D> This is true ....and yes I fully accept we have to live with this =
stuff whilst it is still in-service.

> It simply means that working with PHP and ECMP are
> requirements for OAM.
> You seem to have things backwards.  You have an OAM solution in mind
> that doesn't work well with ECMP and PHP and want a OAM framework that
> claims these are bad features.
NH=3D> Well that's an interesting view.  I could easily re-spin this =
remark and say you have a technology in-mind and will worry about its =
implications later.  If you cast your mind back a year or so, we were =
told (paraphrased) 'if you are having problems then buy kit from a =
decent supplier, don't fix it with adding OAM'.  Things seems to have a =
changed a bit since then ;-)

I have an OAM solution in mind that is designed to work with topological =
constructs that are valid for a co-ps (ie label swapping) forwarding =
mode.....to be perfectly honest with you Y.1710 (requirements) and =
Y.1711 (mechanisms) were written to apply to *any* co-ps technology, =
they were not specifically penned for MPLS.  I see nothing wrong with =
that....in fact if it did not meet this then it would be wrong.  In any =
case, the OAM solution is only one consequential facet of this =
observation....traffic and performance considerations are also impacted.

Architecturally it is simply a fact that merging loses resolution of the =
source, and this has nothing to do with OAM per se but it sure impacts =
it.....if you want any-any behaviour the right modal choice is cnls as =
that never merges only muxes.  How on earth you can tell me =
straight-faced this is not true beats me.

One of my colleagues is about to formally model MPLS as-is using the =
functional architecture language of G.805 (yes I know you probably think =
this is all wrong too, but we need it to develop management information =
models), and this will clearly show that mp2p and PHP are violations of =
the co-ps mode.  I cannot do anything about this, and this has nothing =
to do with my OAM solution for valid co-ps constructs....it is simply a =
fact.
>=20
> This exercise includes stating requirements - and like it or not ECMP
> and PHP are requirements for OAM and so is not requiring changes to
> the forwarding plane.
NH=3D> Its nothing to do with whether I 'like it or not'.  There are =
certain network architectural truths and there are violations of these.  =
Pointing out the consequences of these (as per Dave's paper) should not =
be scolded as heresy....I'd say it should be welcomed by open-minded =
people.  But as noted earlier, please note I am also *not* saying we can =
ignore what has been done simply because we have recognised in hindsight =
doing certain things were not very good ideas.  We have to find ways of =
coping with these things (as they are now done and we cannot undo =
them).....but that is not the same as saying they are right from here on =
in.

> The framework can then discuss a set of
> solutions and their tradeoffs.  If a single solution (or set of
> solutions) covers all requirements well, then any additional partial
> solutions will be redundant.
NH=3D> Not if the super-set that encompasses arch violations still does =
not meet our service and operational requirements at the right =
complexity/cost it doesn't.  After what 2-3 years?, I still don't see =
any formal definitions of MPLS defects and their automatic detection and =
handling (in terms of consistent entry/exit criteria and consequent =
actions) in any IDs yet.  However, simple and complete solutions are =
given in Y.1711.  Given MPLS figures on most vendors and operators =
road-maps, and that opex reduction is a primary consideration for all =
operators these days, if we do not provide simple automatic defect =
detection/handling this will not be not acceptable to us going forward.  =
However, this is not in the least surprising since I have no idea how to =
do this directly for a mp2p entity.....except by using indirect =
techniques like Dave has suggested in the current framework paper, eg =
run p2p LSPs using Y.1711 above the mp2p entities....which you need to =
anyway for non-cnls clients as its the only way to demerge.  I don't see =
what is wrong with suggestions like this, and if you want to re-spin =
Dave's paper to remove this type of observation then I think you are =
doing the larger community a dis-service.

Note - I intend to make this my last posting on this topic as I simply =
cannot see any point in continuing to try and argue the case here, the =
logic of what I have stated above is self-evident IMO and I cannot think =
what more can be said.

regards, Neil


From owner-mpls@UU.NET  Mon Nov 17 08:28: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 IAA11041
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 08:28: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 QQppez08712
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 13:28:19 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 QQppez08681;
	Mon, 17 Nov 2003 13:28:18 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppey07134
	for mpls-outgoing; Mon, 17 Nov 2003 13:05:14 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 QQppey07129
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 13:05: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 QQppey23631
	for <mpls@UU.NET>; Mon, 17 Nov 2003 13:04: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 QQppey04172
	for <mpls@UU.NET>; Mon, 17 Nov 2003 13:04:21 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 QQppey04166
	for <mpls@UU.NET>; Mon, 17 Nov 2003 13:04:21 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAHD46326203;
	Mon, 17 Nov 2003 08:04:06 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <W3H8920A>; Mon, 17 Nov 2003 08:04:06 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D02B927DC@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Subject: RE: on the mpls oam framework
Date: Mon, 17 Nov 2003 08:04:02 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Tom:

My observation would be more along the lines that the set of protocols exist
to handle the lions share of data plane issues in just about any degree of
authority you could care to name. Are they 100% complete and perfect,
probably not but they are getting there on their own. If we pin down the
applicability of each toolset's space relative to each other, that would be
the most useful piece of specific extra effort that is required.

cheers
Dave

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] 
> Sent: Sunday, November 16, 2003 9:53 AM
> To: mpls@UU.NET
> Subject: RE: on the mpls oam framework
> 
> 
> 
> >We already have LSP-PING, LSR-SELF-TEST (a ping derivative),
> >VCCV (a ping++
> >derivative) none of which so far would appear to have 
> required charter
> >changes by the previous operating definition. We also now have 
> >BFD which is
> >more in the 1711 class of tools. On the other side of the 
> house we have
> >Y.1710/11/12/20/fec-cv. With the exception of perhaps wrapping 
> >this stuff in a bit of context, what extra needs doing?
> 
> 	Dave, 
> 
> 	Your statement seems to contain a bit of hubris if you ask
> me. I remember a statement like this in the not-so-distant past 
> made by (I think) Mr. Gates, "...why would you need more than 258k 
> of RAM in a PC?"
> 
> 	--Tom
> 
> 
> 
> 


From owner-mpls@UU.NET  Mon Nov 17 09:26: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 JAA12624
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 09:26: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 QQppfd08004
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 14:26: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 QQppfd07889;
	Mon, 17 Nov 2003 14:26:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppfa11016
	for mpls-outgoing; Mon, 17 Nov 2003 13:38: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 QQppfa11011
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 13:38: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 QQppfa13937
	for <mpls@uu.net>; Mon, 17 Nov 2003 13:37:52 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 QQppfa20490
	for <mpls@uu.net>; Mon, 17 Nov 2003 13:37:52 GMT
Received: from sj-iport-4.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-4.cisco.com [171.68.10.86])
	id QQppfa20471
	for <mpls@uu.net>; Mon, 17 Nov 2003 13:37:51 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAHDbiw7029329
	for <mpls@uu.net>; Mon, 17 Nov 2003 05:37:48 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEA50929;
	Mon, 17 Nov 2003 08:37:43 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAHDbhP15391 for mpls@uu.net; Mon, 17 Nov 2003 08:37:43 -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 QQppfa10928
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 13:36: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 QQppfa04824
	for <mpls@uu.net>; Mon, 17 Nov 2003 13:34: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 QQppfa15994
	for <mpls@uu.net>; Mon, 17 Nov 2003 13:34:37 GMT
Received: from sj-iport-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72])
	id QQppfa15984
	for <mpls@uu.net>; Mon, 17 Nov 2003 13:34:36 GMT
Received: from cisco.com (171.71.177.237)
  by sj-iport-3.cisco.com with ESMTP; 17 Nov 2003 05:42:34 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAHDYXAt014250;
	Mon, 17 Nov 2003 05:34:33 -0800 (PST)
Received: from tnadeauw2k02 (che-vpn-cluster-1-120.cisco.com [10.86.240.120])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEA50782;
	Mon, 17 Nov 2003 08:33:26 -0500 (EST)
Reply-To: <tnadeau@cisco.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
To: "'David Allan'" <dallan@nortelnetworks.com>, <mpls@UU.NET>
Subject: RE: on the mpls oam framework
Date: Mon, 17 Nov 2003 08:33:20 -0500
Organization: Cisco Systems, inc.
Message-ID: <017c01c3ad0f$5ef2c8f0$6701a8c0@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: <FFFC48AEAA5F7447929F4F0D93FCC12D02B927DC@zcard031.ca.nortel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

	I am not disagreing that this isn't a
good start, but there are probably other
things that will pop up. My point is that we
should not expect this to be the sum of the
work to be done; I expect some more.

	--Tom

>-----Original Message-----
>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf 
>Of David Allan
>Sent: Monday, November 17, 2003 8:04 AM
>To: 'tnadeau@cisco.com'; mpls@UU.NET
>Subject: RE: on the mpls oam framework
>
>
>Hi Tom:
>
>My observation would be more along the lines that the set of 
>protocols exist
>to handle the lions share of data plane issues in just about 
>any degree of
>authority you could care to name. Are they 100% complete and perfect,
>probably not but they are getting there on their own. If we 
>pin down the
>applicability of each toolset's space relative to each other, 
>that would be
>the most useful piece of specific extra effort that is required.
>
>cheers
>Dave
>
>> -----Original Message-----
>> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] 
>> Sent: Sunday, November 16, 2003 9:53 AM
>> To: mpls@UU.NET
>> Subject: RE: on the mpls oam framework
>> 
>> 
>> 
>> >We already have LSP-PING, LSR-SELF-TEST (a ping derivative),
>> >VCCV (a ping++
>> >derivative) none of which so far would appear to have 
>> required charter
>> >changes by the previous operating definition. We also now have 
>> >BFD which is
>> >more in the 1711 class of tools. On the other side of the 
>> house we have
>> >Y.1710/11/12/20/fec-cv. With the exception of perhaps wrapping 
>> >this stuff in a bit of context, what extra needs doing?
>> 
>> 	Dave, 
>> 
>> 	Your statement seems to contain a bit of hubris if you ask
>> me. I remember a statement like this in the not-so-distant past 
>> made by (I think) Mr. Gates, "...why would you need more than 258k 
>> of RAM in a PC?"
>> 
>> 	--Tom
>> 
>> 
>> 
>> 
>




From owner-mpls@UU.NET  Mon Nov 17 09:33: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 JAA12786
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 09:33:41 -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 QQppfe03431
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 14:33:51 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 QQppfe03364;
	Mon, 17 Nov 2003 14:33:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppfc02424
	for mpls-outgoing; Mon, 17 Nov 2003 14:12: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 QQppfc02396
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 14:12:20 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 QQppfc02846
	for <mpls@uu.net>; Mon, 17 Nov 2003 14:04: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 QQppfc24078
	for <mpls@uu.net>; Mon, 17 Nov 2003 14:03:35 GMT
Received: from sj-iport-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72])
	id QQppfc24021
	for <mpls@uu.net>; Mon, 17 Nov 2003 14:03:33 GMT
Received: from cisco.com (171.71.177.254)
  by sj-iport-3.cisco.com with ESMTP; 17 Nov 2003 06:11:29 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAHE3Qw5016777
	for <mpls@uu.net>; Mon, 17 Nov 2003 06:03:27 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEA52338;
	Mon, 17 Nov 2003 09:03:25 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAHE3Pe16270 for mpls@uu.net; Mon, 17 Nov 2003 09:03:25 -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 QQppfb12338
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 13:55:21 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 QQppfb14171
	for <mpls@uu.net>; Mon, 17 Nov 2003 13:53: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 QQppfb11221
	for <mpls@uu.net>; Mon, 17 Nov 2003 13:53:03 GMT
Received: from sj-iport-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70])
	id QQppfb11172
	for <mpls@uu.net>; Mon, 17 Nov 2003 13:53:01 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAHDpWtg017435;
	Mon, 17 Nov 2003 05:51:33 -0800 (PST)
Received: from tnadeauw2k02 (che-vpn-cluster-1-120.cisco.com [10.86.240.120])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEA51740;
	Mon, 17 Nov 2003 08:51:32 -0500 (EST)
Reply-To: <tnadeau@cisco.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
To: <curtis@fictitious.org>, <neil.2.harrison@bt.com>
Cc: <kireeti@juniper.net>, <dallan@nortelnetworks.com>, <mpls@UU.NET>
Subject: RE: on the mpls oam framework 
Date: Mon, 17 Nov 2003 08:51:20 -0500
Organization: Cisco Systems, inc.
Message-ID: <01aa01c3ad11$e672ac30$6701a8c0@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: <200311162224.hAGMOPf1002678@workhorse.fictitious.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
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 Curtis Villamizar
>Sent: Sunday, November 16, 2003 5:24 PM
>To: neil.2.harrison@bt.com
>Cc: kireeti@juniper.net; dallan@nortelnetworks.com; mpls@UU.NET
>Subject: Re: on the mpls oam framework 
>
>
>
>In message 
><0536FC9B908BEC4597EE721BE6A3538904EF2E4A@i2km07-ukbr.domain1.system
>host.net>, neil.2.harrison@bt.com writes:
>> Kireeti Kompella wrote 15 November 2003 06:47
>> > Hi Dave,
>> > 
>> > On Tue, 11 Nov 2003, David Allan wrote:
>> > 
>> > > IMHO You are persisting in ignoring what you don't want to see.
>> > 
>> > Speaking as a vendor:
>> > 
>> > On mp2p: at least 90% of the MPLS deployments I've seen use LDP.
>> NH=> Does this make it 'right' then?  If the dominant vendor 
>'does this' then
>>  your conclusions are hardly surprising.  Most of the world 
>also uses MS Wind
>> ows/applications too.....my PC crashes nearly every day....I 
>wish I could sor
>> t/change it but I can't.  Market dominance is a very 
>powerful vehicle IMO ;-)
>> > 
>> > On ECMP: many providers ask us explicitly for ECMP.  On the other
>> > hand, no provider that I know (other than BT) of has complained
>> > about ECMP and asked us to turn it off.
>> NH=> ECMP is a *consequence* of LDP because one cannot 
>control the routing.
>> > 
>> > On PHP: two providers (one being BT) have complained about PHP, out
>> > of all the providers I've talked to about MPLS (about 3%).
>> NH=> You live with what you have been given by the dominant 
>vendors....again 
>> this does not make it right.  Can you tell me how many 
>operators actually ask
>> ed for PHP (or even LDP) as a requirement in the 1st place, 
>as I don't know o
>> f any network/service problem it solves?
>> 
>> regards, Neil
>
>
>They are needed for other technical reasons that are out of scope for
>the OAM framework.  As far as the OAM framework is concerned, they are
>part of the architecture and widely deployed so they must be supported
>by OAM tools.  It simply means that working with PHP and ECMP are
>requirements for OAM.

	One thing that seems to be out of sight of this
dicussion is that the OAM framework MUST provide a 
framework that works based on the requirements stipulated
in the MPLS OAM Requirements draft; it cannot make new things up.
There are a dozen operators that have officially provided
input into this document (and many more unofficially), so 
I think it is a good idea to listen to these requirements.
Handling of ECMP is definitely specified in the aforementioned 
draft.

>You seem to have things backwards.  You have an OAM solution in mind
>that doesn't work well with ECMP and PHP and want a OAM framework that
>claims these are bad features.
>
>This exercise includes stating requirements - and like it or not ECMP
>and PHP are requirements for OAM and so is not requiring changes to
>the forwarding plane.  
	
	We already have:  draft-ietf-mpls-oam-requirements-02.txt

	--Tom


> The framework can then discuss a set of
>solutions and their tradeoffs.  If a single solution (or set of
>solutions) covers all requirements well, then any additional partial
>solutions will be redundant.
>
>Curtis
>
>




From owner-mpls@UU.NET  Mon Nov 17 09:36: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 JAA12834
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 09:36: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 QQppfe27621
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 14:36: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 QQppfe27375;
	Mon, 17 Nov 2003 14:36:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppfc02695
	for mpls-outgoing; Mon, 17 Nov 2003 14:14: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 QQppfc02616
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 14:13: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 QQppfc08872
	for <mpls@uu.net>; Mon, 17 Nov 2003 14:03: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 QQppfc07424
	for <mpls@uu.net>; Mon, 17 Nov 2003 14:03:38 GMT
Received: from sj-iport-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71])
	id QQppfc07359
	for <mpls@uu.net>; Mon, 17 Nov 2003 14:03:36 GMT
Received: from cisco.com (171.71.177.254)
  by sj-iport-2.cisco.com with ESMTP; 17 Nov 2003 06:06:46 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAHE3Lw5016702
	for <mpls@uu.net>; Mon, 17 Nov 2003 06:03:22 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEA52329;
	Mon, 17 Nov 2003 09:03:20 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAHE3Kw16262 for mpls@uu.net; Mon, 17 Nov 2003 09:03:20 -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 QQppev15609
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 12:25:20 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 QQppev29305
	for <mpls@uu.net>; Mon, 17 Nov 2003 12:24: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 QQppev12757
	for <mpls@uu.net>; Mon, 17 Nov 2003 12:24:22 GMT
Received: from sj-iport-5.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-5.cisco.com [171.68.10.87])
	id QQppev12743
	for <mpls@uu.net>; Mon, 17 Nov 2003 12:24:22 GMT
Received: from employees.org (171.68.223.138)
  by sj-iport-5.cisco.com with ESMTP; 17 Nov 2003 04:25:23 -0800
Received: from cisco.com (sjc-vpn2-460.cisco.com [10.21.113.204])
	by sj-core-4.cisco.com (8.12.6/8.12.6) with SMTP id hAHCOIiN027984;
	Mon, 17 Nov 2003 04:24:19 -0800 (PST)
Received: by cisco.com (sSMTP sendmail emulation); Mon, 17 Nov 2003 07:24:11 -0500
Date: Mon, 17 Nov 2003 07:24:11 -0500
From: Scott W Brim <swb@employees.org>
To: David Wilkinson <David.Wilkinson@nativenetworks.com>
Cc: mpls@UU.NET
Subject: Re: CR-LDP
Message-ID: <20031117122411.GI2748@sbrim-w2k01>
Mail-Followup-To: Scott W Brim <swb@employees.org>,
	David Wilkinson <David.Wilkinson@nativenetworks.com>, mpls@UU.NET
References: <489D5170A085A145AA767008F5BCCD451FF140@spear.nn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <489D5170A085A145AA767008F5BCCD451FF140@spear.nn.com>
User-Agent: Mutt/1.4.1i
Sender: owner-mpls@UU.NET
Precedence: bulk

On Mon, Nov 17, 2003 08:21:25AM -0000, David Wilkinson allegedly wrote:
> All,
>  
> Can anyone give me a very quick update on the current status of CR-LDP - are we still looking at CR-LDP as a viable TE signaling protocol - I appear to have missed something

Try RFC 3468.



From owner-mpls@UU.NET  Mon Nov 17 09:41: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 JAA12992
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 09:41: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 QQppfe07378
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 14: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 QQppfe07250;
	Mon, 17 Nov 2003 14:41:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppfd03737
	for mpls-outgoing; Mon, 17 Nov 2003 14: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 QQppfd03730
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 14:19:42 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 QQppfd19132
	for <mpls@UU.NET>; Mon, 17 Nov 2003 14:17:56 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 QQppfd18985
	for <mpls@UU.NET>; Mon, 17 Nov 2003 14:17:56 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 QQppfd18966
	for <mpls@UU.NET>; Mon, 17 Nov 2003 14:17:55 GMT
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAHEHqw11303
	for <mpls@UU.NET>; Mon, 17 Nov 2003 08:17:52 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59)
	id <WMXR565L>; Mon, 17 Nov 2003 15:17:17 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502EB01CA@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: David Wilkinson <David.Wilkinson@nativenetworks.com>, mpls@UU.NET
Subject: RE: CR-LDP
Date: Mon, 17 Nov 2003 15:17:17 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3AD15.812053A6"
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_01C3AD15.812053A6
Content-Type: text/plain;
	charset="iso-8859-1"

See RFC3468
 

Thanks,
Bert 

-----Original Message-----
From: David Wilkinson [mailto:David.Wilkinson@nativenetworks.com]
Sent: maandag 17 november 2003 9:21
To: mpls@UU.NET
Subject: CR-LDP


All,
 
Can anyone give me a very quick update on the current status of CR-LDP - are we still looking at CR-LDP as a viable TE signaling protocol - I appear to have missed something
 
Cheers,
 
Dave



------_=_NextPart_001_01C3AD15.812053A6
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><SPAN class=529351614-17112003><FONT face=Arial color=#0000ff size=2>See 
RFC3468</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<P><FONT size=2>Thanks,<BR>Bert </FONT></P>
<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> David Wilkinson 
  [mailto:David.Wilkinson@nativenetworks.com]<BR><B>Sent:</B> maandag 17 
  november 2003 9:21<BR><B>To:</B> mpls@UU.NET<BR><B>Subject:</B> 
  CR-LDP<BR><BR></FONT></DIV>
  <DIV><SPAN class=541042008-17112003><FONT face=Arial 
  size=2>All,</FONT></SPAN></DIV>
  <DIV><SPAN class=541042008-17112003><FONT face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=541042008-17112003><FONT face=Arial size=2>Can anyone give me 
  a very quick update on the current status of CR-LDP - are we still looking at 
  CR-LDP as a viable TE signaling protocol - I appear to have missed 
  something</FONT></SPAN></DIV>
  <DIV><SPAN class=541042008-17112003><FONT face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=541042008-17112003><FONT face=Arial 
  size=2>Cheers,</FONT></SPAN></DIV>
  <DIV><SPAN class=541042008-17112003><FONT face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=541042008-17112003><FONT face=Arial 
  size=2>Dave</FONT></SPAN></DIV>
  <DIV><FONT face=Arial size=2>
  <P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><FONT 
  face="Times New Roman"><STRONG><SPAN 
  style="FONT-SIZE: 11pt; mso-bidi-font-size: 10.0pt"></SPAN></STRONG></FONT></P></FONT></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3AD15.812053A6--


From owner-mpls@UU.NET  Mon Nov 17 09:44: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 JAA13067
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 09:44: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 QQppfe07534
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 14:44: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 QQppfe07122;
	Mon, 17 Nov 2003 14:44:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppfd04269
	for mpls-outgoing; Mon, 17 Nov 2003 14:23: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 QQppfd04196
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 14: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 QQppfd04074
	for <mpls@UU.NET>; Mon, 17 Nov 2003 14:17: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 QQppfd17984
	for <mpls@UU.NET>; Mon, 17 Nov 2003 14:17: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 QQppfd17957
	for <mpls@UU.NET>; Mon, 17 Nov 2003 14:17:29 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAHEGph10084;
	Mon, 17 Nov 2003 09:16:51 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <W3H89K61>; Mon, 17 Nov 2003 09:16:51 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D02B927DE@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'tnadeau@cisco.com'" <tnadeau@cisco.com>, curtis@fictitious.org,
        neil.2.harrison@bt.com
Cc: kireeti@juniper.net, mpls@UU.NET
Subject: RE: on the mpls oam framework 
Date: Mon, 17 Nov 2003 09:16:47 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-mpls@UU.NET
Precedence: bulk

Tom:

I have to admit, the whole ECMP thing provides me with endless amusement.
Pull a proprietary rabbit out of your hat and then paint those previously
ignorant of your "feature" as clueless. If you'd been upfront with the fact
that there was a problem literally "years ago", a lot of creative energy in
OAM and PWs would not have been wasted.

Meanwhile we have the PW PID which seems to level the playing field across
the board as an OAM channel for PWs that can carry just about anything
without getting confused by already deployed ECMP mechanisms, we've also
given ECMP a lot of thought and an approach is documented in 17fec-cv for
the LDP layer. IMHO just about everything on the table at this point has
taken ECMP into account or at least ECMP as well as it is "commonly"
understood at this point.

I'm curious, is the ECMP that must be supported exclusively your
implementation? T'would be nice if the vendors who've deployed ECMP
documented what they've done in sufficent detail such that we could all
innovate in this space and knew all variations we needed to comply with.
Normally defining data plane OAM requires an agreed characterization of the
data plane. The situation as it stands is intolerable.....

cheers
Dave

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] 
> Sent: Monday, November 17, 2003 8:51 AM
> To: curtis@fictitious.org; neil.2.harrison@bt.com
> Cc: kireeti@juniper.net; Allan, David [CAR:NS00:EXCH]; mpls@UU.NET
> Subject: RE: on the mpls oam framework 
> 
> 
> 
> 
> >-----Original Message-----
> >From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf
> >Of Curtis Villamizar
> >Sent: Sunday, November 16, 2003 5:24 PM
> >To: neil.2.harrison@bt.com
> >Cc: kireeti@juniper.net; dallan@nortelnetworks.com; mpls@UU.NET
> >Subject: Re: on the mpls oam framework 
> >
> >
> >
> >In message
> ><0536FC9B908BEC4597EE721BE6A3538904EF2E4A@i2km07-ukbr.domain1.system
> >host.net>, neil.2.harrison@bt.com writes:
> >> Kireeti Kompella wrote 15 November 2003 06:47
> >> > Hi Dave,
> >> > 
> >> > On Tue, 11 Nov 2003, David Allan wrote:
> >> > 
> >> > > IMHO You are persisting in ignoring what you don't want to see.
> >> > 
> >> > Speaking as a vendor:
> >> > 
> >> > On mp2p: at least 90% of the MPLS deployments I've seen use LDP.
> >> NH=> Does this make it 'right' then?  If the dominant vendor
> >'does this' then
> >>  your conclusions are hardly surprising.  Most of the world
> >also uses MS Wind
> >> ows/applications too.....my PC crashes nearly every day....I
> >wish I could sor
> >> t/change it but I can't.  Market dominance is a very
> >powerful vehicle IMO ;-)
> >> > 
> >> > On ECMP: many providers ask us explicitly for ECMP.  On 
> the other 
> >> > hand, no provider that I know (other than BT) of has complained 
> >> > about ECMP and asked us to turn it off.
> >> NH=> ECMP is a *consequence* of LDP because one cannot
> >control the routing.
> >> > 
> >> > On PHP: two providers (one being BT) have complained 
> about PHP, out 
> >> > of all the providers I've talked to about MPLS (about 3%).
> >> NH=> You live with what you have been given by the dominant
> >vendors....again
> >> this does not make it right.  Can you tell me how many
> >operators actually ask
> >> ed for PHP (or even LDP) as a requirement in the 1st place,
> >as I don't know o
> >> f any network/service problem it solves?
> >> 
> >> regards, Neil
> >
> >
> >They are needed for other technical reasons that are out of 
> scope for 
> >the OAM framework.  As far as the OAM framework is 
> concerned, they are 
> >part of the architecture and widely deployed so they must be 
> supported 
> >by OAM tools.  It simply means that working with PHP and ECMP are 
> >requirements for OAM.
> 
> 	One thing that seems to be out of sight of this
> dicussion is that the OAM framework MUST provide a 
> framework that works based on the requirements stipulated
> in the MPLS OAM Requirements draft; it cannot make new things 
> up. There are a dozen operators that have officially provided 
> input into this document (and many more unofficially), so 
> I think it is a good idea to listen to these requirements. 
> Handling of ECMP is definitely specified in the aforementioned 
> draft.
> 
> >You seem to have things backwards.  You have an OAM solution in mind 
> >that doesn't work well with ECMP and PHP and want a OAM 
> framework that 
> >claims these are bad features.
> >
> >This exercise includes stating requirements - and like it or 
> not ECMP 
> >and PHP are requirements for OAM and so is not requiring 
> changes to the 
> >forwarding plane.
> 	
> 	We already have:  draft-ietf-mpls-oam-requirements-02.txt
> 
> 	--Tom
> 
> 
> > The framework can then discuss a set of
> >solutions and their tradeoffs.  If a single solution (or set of
> >solutions) covers all requirements well, then any additional partial 
> >solutions will be redundant.
> >
> >Curtis
> >
> >
> 
> 
> 


From owner-mpls@UU.NET  Mon Nov 17 10:28: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 KAA15694
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 10:28: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 QQppfh14116
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 15:28: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 QQppfh13724;
	Mon, 17 Nov 2003 15:28:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppfg28246
	for mpls-outgoing; Mon, 17 Nov 2003 15:12: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 QQppfg28241
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 15:12:05 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 QQppfg10119
	for <mpls@uu.net>; Mon, 17 Nov 2003 15:11: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 QQppfg16261
	for <mpls@uu.net>; Mon, 17 Nov 2003 15:11:26 GMT
Received: from sj-iport-3.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72])
	id QQppfg16238
	for <mpls@uu.net>; Mon, 17 Nov 2003 15:11:26 GMT
Received: from cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 17 Nov 2003 07:19:25 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAHFBMtg010088
	for <mpls@uu.net>; Mon, 17 Nov 2003 07:11:22 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEA58741;
	Mon, 17 Nov 2003 10:11:21 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAHFBLF25581 for mpls@uu.net; Mon, 17 Nov 2003 10:11: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 QQppfg27684
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 15:10:03 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 QQppfg10144
	for <mpls@uu.net>; Mon, 17 Nov 2003 15:09: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 QQppfg24091
	for <mpls@uu.net>; Mon, 17 Nov 2003 15:09:11 GMT
Received: from sj-iport-4.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-4.cisco.com [171.68.10.86])
	id QQppfg24080
	for <mpls@uu.net>; Mon, 17 Nov 2003 15:09:11 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAHF96xg014077;
	Mon, 17 Nov 2003 10:09:07 -0500 (EST)
Received: from tnadeauw2k02 ([161.44.71.146])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEA58565;
	Mon, 17 Nov 2003 10:09:06 -0500 (EST)
Reply-To: <tnadeau@cisco.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
To: "'David Allan'" <dallan@nortelnetworks.com>, <curtis@fictitious.org>,
        <neil.2.harrison@bt.com>
Cc: <kireeti@juniper.net>, <mpls@UU.NET>
Subject: RE: on the mpls oam framework 
Date: Mon, 17 Nov 2003 10:08:56 -0500
Organization: Cisco Systems, inc.
Message-ID: <01c101c3ad1c$bcab2c50$6701a8c0@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: <FFFC48AEAA5F7447929F4F0D93FCC12D02B927DE@zcard031.ca.nortel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



>-----Original Message-----
>From: David Allan [mailto:dallan@nortelnetworks.com] 
>Sent: Monday, November 17, 2003 9:17 AM
>To: 'tnadeau@cisco.com'; curtis@fictitious.org; neil.2.harrison@bt.com
>Cc: kireeti@juniper.net; mpls@UU.NET
>Subject: RE: on the mpls oam framework 
>
>
>Tom:
>
>I have to admit, the whole ECMP thing provides me with endless 
>amusement.
>Pull a proprietary rabbit out of your hat and then paint those 
>previously
>ignorant of your "feature" as clueless. If you'd been upfront 
>with the fact
>that there was a problem literally "years ago", a lot of 
>creative energy in OAM and PWs would not have been wasted.
	
	Sure, we can keep crying about the past, but I think
we should just move forward with what we have.

>Meanwhile we have the PW PID which seems to level the playing 
>field across
>the board as an OAM channel for PWs that can carry just about anything
>without getting confused by already deployed ECMP mechanisms, 
>we've also
>given ECMP a lot of thought and an approach is documented in 
>17fec-cv for
>the LDP layer. IMHO just about everything on the table at this 
>point has
>taken ECMP into account or at least ECMP as well as it is "commonly"
>understood at this point.
>
>I'm curious, is the ECMP that must be supported exclusively your
>implementation? 

	I would love for that to be the case. Great proposal! *)

> T'would be nice if the vendors who've deployed ECMP
>documented what they've done in sufficent detail such that we could all
>innovate in this space and knew all variations we needed to 
>comply with.
>Normally defining data plane OAM requires an agreed 
>characterization of the
>data plane. The situation as it stands is intolerable.....

	I do not believe that my algorithm(s) are documented anywhere,
nor do I think that Kireeti's, Curtis' or otherwise.  I think this 
is why tools/techniques we produce need to be flexible in this
area to support all types.  Throwing away what exists today is
not an option.

	--Tom




>cheers
>Dave
>
>> -----Original Message-----
>> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] 
>> Sent: Monday, November 17, 2003 8:51 AM
>> To: curtis@fictitious.org; neil.2.harrison@bt.com
>> Cc: kireeti@juniper.net; Allan, David [CAR:NS00:EXCH]; mpls@UU.NET
>> Subject: RE: on the mpls oam framework 
>> 
>> 
>> 
>> 
>> >-----Original Message-----
>> >From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf
>> >Of Curtis Villamizar
>> >Sent: Sunday, November 16, 2003 5:24 PM
>> >To: neil.2.harrison@bt.com
>> >Cc: kireeti@juniper.net; dallan@nortelnetworks.com; mpls@UU.NET
>> >Subject: Re: on the mpls oam framework 
>> >
>> >
>> >
>> >In message
>> ><0536FC9B908BEC4597EE721BE6A3538904EF2E4A@i2km07-ukbr.domain1.system
>> >host.net>, neil.2.harrison@bt.com writes:
>> >> Kireeti Kompella wrote 15 November 2003 06:47
>> >> > Hi Dave,
>> >> > 
>> >> > On Tue, 11 Nov 2003, David Allan wrote:
>> >> > 
>> >> > > IMHO You are persisting in ignoring what you don't 
>want to see.
>> >> > 
>> >> > Speaking as a vendor:
>> >> > 
>> >> > On mp2p: at least 90% of the MPLS deployments I've seen use LDP.
>> >> NH=> Does this make it 'right' then?  If the dominant vendor
>> >'does this' then
>> >>  your conclusions are hardly surprising.  Most of the world
>> >also uses MS Wind
>> >> ows/applications too.....my PC crashes nearly every day....I
>> >wish I could sor
>> >> t/change it but I can't.  Market dominance is a very
>> >powerful vehicle IMO ;-)
>> >> > 
>> >> > On ECMP: many providers ask us explicitly for ECMP.  On 
>> the other 
>> >> > hand, no provider that I know (other than BT) of has complained 
>> >> > about ECMP and asked us to turn it off.
>> >> NH=> ECMP is a *consequence* of LDP because one cannot
>> >control the routing.
>> >> > 
>> >> > On PHP: two providers (one being BT) have complained 
>> about PHP, out 
>> >> > of all the providers I've talked to about MPLS (about 3%).
>> >> NH=> You live with what you have been given by the dominant
>> >vendors....again
>> >> this does not make it right.  Can you tell me how many
>> >operators actually ask
>> >> ed for PHP (or even LDP) as a requirement in the 1st place,
>> >as I don't know o
>> >> f any network/service problem it solves?
>> >> 
>> >> regards, Neil
>> >
>> >
>> >They are needed for other technical reasons that are out of 
>> scope for 
>> >the OAM framework.  As far as the OAM framework is 
>> concerned, they are 
>> >part of the architecture and widely deployed so they must be 
>> supported 
>> >by OAM tools.  It simply means that working with PHP and ECMP are 
>> >requirements for OAM.
>> 
>> 	One thing that seems to be out of sight of this
>> dicussion is that the OAM framework MUST provide a 
>> framework that works based on the requirements stipulated
>> in the MPLS OAM Requirements draft; it cannot make new things 
>> up. There are a dozen operators that have officially provided 
>> input into this document (and many more unofficially), so 
>> I think it is a good idea to listen to these requirements. 
>> Handling of ECMP is definitely specified in the aforementioned 
>> draft.
>> 
>> >You seem to have things backwards.  You have an OAM 
>solution in mind 
>> >that doesn't work well with ECMP and PHP and want a OAM 
>> framework that 
>> >claims these are bad features.
>> >
>> >This exercise includes stating requirements - and like it or 
>> not ECMP 
>> >and PHP are requirements for OAM and so is not requiring 
>> changes to the 
>> >forwarding plane.
>> 	
>> 	We already have:  draft-ietf-mpls-oam-requirements-02.txt
>> 
>> 	--Tom
>> 
>> 
>> > The framework can then discuss a set of
>> >solutions and their tradeoffs.  If a single solution (or set of
>> >solutions) covers all requirements well, then any 
>additional partial 
>> >solutions will be redundant.
>> >
>> >Curtis
>> >
>> >
>> 
>> 
>> 
>




From owner-mpls@UU.NET  Mon Nov 17 10:42: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 KAA16466
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 10:42: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 QQppfi14585
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 15:42: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 QQppfi14152;
	Mon, 17 Nov 2003 15:42:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppfh29749
	for mpls-outgoing; Mon, 17 Nov 2003 15:22: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 QQppfh29669
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 15:22: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 QQppfh20516
	for <mpls@UU.NET>; Mon, 17 Nov 2003 15:18: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 QQppfh25986
	for <mpls@UU.NET>; Mon, 17 Nov 2003 15:18:06 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 QQppfh25971
	for <mpls@UU.NET>; Mon, 17 Nov 2003 15:18:06 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAHFGp305080;
	Mon, 17 Nov 2003 10:16:51 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <W3H89NDR>; Mon, 17 Nov 2003 10:16:51 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D02B927DF@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'tnadeau@cisco.com'" <tnadeau@cisco.com>, curtis@fictitious.org,
        neil.2.harrison@bt.com
Cc: kireeti@juniper.net, mpls@UU.NET
Subject: RE: on the mpls oam framework 
Date: Mon, 17 Nov 2003 10:16:43 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Tom:

<snipped>
> 	Sure, we can keep crying about the past, but I think
> we should just move forward with what we have.

I'm not. I'm sure I'm not the only person who has noted the oxymoron
inherent to the requirement "must support undocumented proprietary feature".
I'm suggesting it MUST be documented in order to proceed.

<snip>
> 	I do not believe that my algorithm(s) are documented 
> anywhere, nor do I think that Kireeti's, Curtis' or 
> otherwise.  I think this 
> is why tools/techniques we produce need to be flexible in 
> this area to support all types.  Throwing away what exists 
> today is not an option.

That's not the suggestion. The suggestion is that we only support what we
can see. Document what exists today so we can all participate in innovation.
We'll otherwise waste a lot of time figuring out what is redundant and what
is not. I'm not interested in wasting my time proposing solutions for some
"star chamber" to pick and choose from....

cheers
Dave


From owner-mpls@UU.NET  Mon Nov 17 10:56: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 KAA17027
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 10:56: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 QQppfj01528
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 15:57: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 QQppfj01124;
	Mon, 17 Nov 2003 15:56:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppfi01252
	for mpls-outgoing; Mon, 17 Nov 2003 15:38: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 QQppfi01235
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 15:37: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 QQppfi14244
	for <mpls@uu.net>; Mon, 17 Nov 2003 15:37: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 QQppfi27019
	for <mpls@uu.net>; Mon, 17 Nov 2003 15:37:06 GMT
Received: from sj-iport-5.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-5.cisco.com [171.68.10.87])
	id QQppfi26961
	for <mpls@uu.net>; Mon, 17 Nov 2003 15:37:05 GMT
Received: from cisco.com (171.71.177.254)
  by sj-iport-5.cisco.com with ESMTP; 17 Nov 2003 07:38:09 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAHFb0w7024858
	for <mpls@uu.net>; Mon, 17 Nov 2003 07:37:02 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEA61238;
	Mon, 17 Nov 2003 10:36:59 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAHFaxC28508 for mpls@uu.net; Mon, 17 Nov 2003 10:36:59 -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 QQppfi00936
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 15:35: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 QQppfi12166
	for <mpls@uu.net>; Mon, 17 Nov 2003 15:33: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 QQppfi24411
	for <mpls@uu.net>; Mon, 17 Nov 2003 15:33:22 GMT
Received: from sj-iport-4.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-4.cisco.com [171.68.10.86])
	id QQppfi24401
	for <mpls@uu.net>; Mon, 17 Nov 2003 15:33:21 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAHFXIDM024461
	for <mpls@UU.NET>; Mon, 17 Nov 2003 10:33:18 -0500 (EST)
Received: from tnadeauw2k02 ([161.44.71.146])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEA60893;
	Mon, 17 Nov 2003 10:33:17 -0500 (EST)
Reply-To: <tnadeau@cisco.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
To: <mpls@UU.NET>
Subject: RE: on the mpls oam framework 
Date: Mon, 17 Nov 2003 10:33:08 -0500
Organization: Cisco Systems, inc.
Message-ID: <01cf01c3ad20$1da8b420$6701a8c0@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: <FFFC48AEAA5F7447929F4F0D93FCC12D02B927DF@zcard031.ca.nortel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



>-----Original Message-----
>From: David Allan [mailto:dallan@nortelnetworks.com] 
>Sent: Monday, November 17, 2003 10:17 AM
>To: 'tnadeau@cisco.com'; curtis@fictitious.org; neil.2.harrison@bt.com
>Cc: kireeti@juniper.net; mpls@UU.NET
>Subject: RE: on the mpls oam framework 
>
>
>Hi Tom:
>
><snipped>
>> 	Sure, we can keep crying about the past, but I think
>> we should just move forward with what we have.
>
>I'm not. I'm sure I'm not the only person who has noted the oxymoron
>inherent to the requirement "must support undocumented 
>proprietary feature".
>I'm suggesting it MUST be documented in order to proceed.

	I am suggesting that doing so is not a scalable
problem to solve.  Also practically speaking, I doubt
that anyone is going to divulge their exact algorithm.
It might be an interesting informational draft to 
produce such a compendium from anonymous sources, but
this always leaves open the door for one more algorithm.

><snip>
>> 	I do not believe that my algorithm(s) are documented 
>> anywhere, nor do I think that Kireeti's, Curtis' or 
>> otherwise.  I think this 
>> is why tools/techniques we produce need to be flexible in 
>> this area to support all types.  Throwing away what exists 
>> today is not an option.
>
>That's not the suggestion. The suggestion is that we only 
>support what we can see. 

	That sounds like you want connection-oriented
constructs only too. *)

> Document what exists today so we can all participate 
>in innovation.
>We'll otherwise waste a lot of time figuring out what is 
>redundant and what
>is not. I'm not interested in wasting my time proposing 
>solutions for some "star chamber" to pick and choose from....

	While I would of course agree that knowing all of the
algorithms would make things easier, I disagree that we cannot
move forward with solutions today. I think that solutions can be 
created to manage what is deployed today. There is clear evidence
of this already.

	--Tom






From owner-mpls@UU.NET  Mon Nov 17 11:38: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 LAA19313
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 11:38: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 QQppfm10994
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 16:38: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 QQppfm10694;
	Mon, 17 Nov 2003 16:38:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppfk23889
	for mpls-outgoing; Mon, 17 Nov 2003 16: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 QQppfk23882
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 16:14: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 QQppfk22635
	for <mpls@UU.NET>; Mon, 17 Nov 2003 16:13: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 QQppfk25948
	for <mpls@UU.NET>; Mon, 17 Nov 2003 16:13:24 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 QQppfk25920
	for <mpls@UU.NET>; Mon, 17 Nov 2003 16:13:24 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAHGBnh13477;
	Mon, 17 Nov 2003 11:11:49 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <W3H89PD7>; Mon, 17 Nov 2003 11:11:49 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D02B927E3@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Subject: RE: on the mpls oam framework 
Date: Mon, 17 Nov 2003 11:11:39 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi again:
<snipped>
> >I'm not. I'm sure I'm not the only person who has noted the oxymoron 
> >inherent to the requirement "must support undocumented proprietary 
> >feature". I'm suggesting it MUST be documented in order to proceed.
> 
> 	I am suggesting that doing so is not a scalable
> problem to solve.  

Not parsing?

> Also practically speaking, I doubt
> that anyone is going to divulge their exact algorithm.
> It might be an interesting informational draft to 
> produce such a compendium from anonymous sources, but
> this always leaves open the door for one more algorithm.

Then that's tough for those who do not share. If you want interoperable OAM,
you have to play. IMHO the minimum requirement is exact what fields are
examined, how much of the stack, interface IDs etc. I'm less concerned about
whether it is CRC-32 or BIP-16 or whatever. 

<snipped>
> >That's not the suggestion. The suggestion is that we only
> >support what we can see. 
> 
> 	That sounds like you want connection-oriented
> constructs only too. *)

Is this comment relevant?

<snipped>
> 	While I would of course agree that knowing all of the 
> algorithms would make things easier, I disagree that we 
> cannot move forward with solutions today. I think that 
> solutions can be 
> created to manage what is deployed today. There is clear 
> evidence of this already.

As I say, we all need to be able to innovate in this space. At the moment
the majority of the list is disenfranchized. This is a problem. Either the
WG sticks with the decision that this is not specified and recognizes that
the quality of what it gets for interoperable OAM is unknowable, or people
at least 'fess up informationally and we can all participate. Which version
do you think is the IETF way....

BTW, would be nice to get some other opinions, IMHO this is rather
fundamental....

cheers
Dave



From owner-mpls@UU.NET  Mon Nov 17 12:00: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 MAA21259
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 12:00: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 QQppfo15719
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 17:00: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 QQppfo15495;
	Mon, 17 Nov 2003 17:00:46 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppfm26384
	for mpls-outgoing; Mon, 17 Nov 2003 16:42: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 QQppfm26373
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 16:42:27 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 QQppfm02356
	for <mpls@uu.net>; Mon, 17 Nov 2003 16:39: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 QQppfm10930
	for <mpls@uu.net>; Mon, 17 Nov 2003 16:39:10 GMT
Received: from sj-iport-5.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-5.cisco.com [171.68.10.87])
	id QQppfm10915
	for <mpls@uu.net>; Mon, 17 Nov 2003 16:39:10 GMT
Received: from cisco.com (64.102.124.12)
  by sj-iport-5.cisco.com with ESMTP; 17 Nov 2003 08:40:14 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAHGd6xg007163
	for <mpls@uu.net>; Mon, 17 Nov 2003 11:39:06 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEA67857;
	Mon, 17 Nov 2003 11:39:04 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAHGd4j02992 for mpls@uu.net; Mon, 17 Nov 2003 11: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 QQppfm25965
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 16:36:43 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 QQppfm27129
	for <mpls@UU.NET>; Mon, 17 Nov 2003 16:34: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 QQppfm04424
	for <mpls@UU.NET>; Mon, 17 Nov 2003 16:34: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 QQppfm04400
	for <mpls@UU.NET>; Mon, 17 Nov 2003 16:34:47 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hAHGZTL7001539;
	Mon, 17 Nov 2003 11:35:29 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311171635.hAHGZTL7001539@workhorse.fictitious.org>
To: "David Allan" <dallan@nortelnetworks.com>
cc: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "'neil.2.harrison@bt.com'" <neil.2.harrison@bt.com>,
        kireeti@juniper.net, loa@pi.se, mpls@UU.NET, swallow@cisco.com,
        zinin@psg.com
Reply-To: curtis@fictitious.org
Subject: Re: on the mpls oam framework 
In-reply-to: Your message of "Mon, 17 Nov 2003 03:25:51 EST."
             <FFFC48AEAA5F7447929F4F0D93FCC12D02B927D4@zcard031.ca.nortel.com> 
Date: Mon, 17 Nov 2003 11:35:29 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <FFFC48AEAA5F7447929F4F0D93FCC12D02B927D4@zcard031.ca.nortel.com>, "
David Allan" writes:
> Hi Curtis:
> 
> I wouldn't describe it as a ringing endorsement ;-). More a reflection of
> the schimsm that the MPLS WG was not going to reach any sort of consensus on
> OAM at the time as most folks considered it to be not required, did not
> necessarily like the solutions etc. etc. etc. Now this topic seems to have
> come forward to some degree and the question is what do we do.....
> 
> IMHO 1711 and 17fec-cv should be useful candidates. I understand some
> concerns with the dataplane, and it would be useful if some of those issues
> could be addressed. The key issue being primarily on how payload is
> identified. The PW PID is an example of how this can be addressed without
> fundamentally undoing the work, IMHO other options exist. 
> 
> cheers
> Dave


I agree that 1711 and 17fec-cv should be candidates.  However we are
at the framework stage and crafting the framework to describe those
conditions that impact a particular approach more difficult is not the
way this WG should approach the problem.

The framework draft should start with requirements independent of any
proposed solution and discuss how various solutions fit into the
requirement space, not how the requirement space fits into a paricular
solution.

Curtis



From owner-mpls@UU.NET  Mon Nov 17 12:03: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 MAA21488
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 12:03: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 QQppfo21082
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 17:04: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 QQppfo20846;
	Mon, 17 Nov 2003 17:03:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppfn27379
	for mpls-outgoing; Mon, 17 Nov 2003 16:48: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 QQppfn27372
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 16:48: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 QQppfn17235
	for <mpls@UU.NET>; Mon, 17 Nov 2003 16:47:33 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 QQppfn23145
	for <mpls@UU.NET>; Mon, 17 Nov 2003 16:47:33 GMT
Received: from mxsf15.cluster1.charter.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mxsf15.cluster1.charter.net [209.225.28.215])
	id QQppfn23134
	for <mpls@UU.NET>; Mon, 17 Nov 2003 16:47:32 GMT
Received: from interflect.com (ts46-01-qdr3166.mrgnhll.ca.charter.com [68.118.70.100])
	by mxsf15.cluster1.charter.net (8.12.10/8.12.8) with ESMTP id hAHGcxoa016392;
	Mon, 17 Nov 2003 11:39:00 -0500 (EST)
	(envelope-from mark@interflect.com)
Message-ID: <3FB8F9A5.5010306@interflect.com>
Date: Mon, 17 Nov 2003 08:39:01 -0800
From: mark seery <mark@interflect.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Allan <dallan@nortelnetworks.com>
CC: "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Subject: Re: on the mpls oam framework
References: <FFFC48AEAA5F7447929F4F0D93FCC12D02B927E3@zcard031.ca.nortel.com>
In-Reply-To: <FFFC48AEAA5F7447929F4F0D93FCC12D02B927E3@zcard031.ca.nortel.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 Allan wrote:

>BTW, would be nice to get some other opinions, IMHO this is rather
>fundamental....
>
One of the fundamental precepts of routing, is that each node 
understands the routing decisions each other node makes, this is to 
prevent black holing among other things. So for example, the SPF 
algorithm is not a secret, precisely so that each router in a network 
can make consistent decisions. As ECMP algorithms impact the forwarding 
direction of packets, then I would suggest while not on the same level 
of criticality as SPF, there is a similar logic that could be applied to 
this case. I have similar thoughts about end-to-end QoS (but that's way 
OT, just sited as another example).

In addition, having worked at a vendor trying to work out the best way 
to do ECMP (which is not easy task in an MPLS environment) it sure would 
have been nice to have an industry-agreed way of doing this. While I 
realise 802.1ad have gotten away with not agreeing to alogorithms, that 
is on a point-to-point basis. When an algorithm impacts end-to-end 
(within an area/AS at least) then I think the need to have an agreed 
upon standard is more important.

So bottom line is I would have to agree that two routers from different 
vendors can not communicate in the same network using ECMP unless the 
algorithm is known by both. So if ECMP is in an architecture or 
framework document, then it is not a proprietary feature, and therefore 
it should be standardized.


my 2 cents....

Mark



From owner-mpls@UU.NET  Mon Nov 17 13: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 NAA27374
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 13:38: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 QQppfu03379
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 18:38: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 QQppfu03215;
	Mon, 17 Nov 2003 18:38:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppft13825
	for mpls-outgoing; Mon, 17 Nov 2003 18:21: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 QQppft13820
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 18:21: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 QQppft07413
	for <mpls@uu.net>; Mon, 17 Nov 2003 18:20: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 QQppft08689
	for <mpls@uu.net>; Mon, 17 Nov 2003 18:20:23 GMT
Received: from sj-iport-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70])
	id QQppft08673
	for <mpls@uu.net>; Mon, 17 Nov 2003 18:20:22 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAHIKJtg004790
	for <mpls@uu.net>; Mon, 17 Nov 2003 10:20:19 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEA78342;
	Mon, 17 Nov 2003 13:20:17 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAHIKHX07444 for mpls@uu.net; Mon, 17 Nov 2003 13:20:17 -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 QQppft13720
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 18:18:30 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 QQppft00136
	for <mpls@UU.NET>; Mon, 17 Nov 2003 18:15: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 QQppft23166
	for <mpls@UU.NET>; Mon, 17 Nov 2003 18:15:40 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 QQppft23132
	for <mpls@UU.NET>; Mon, 17 Nov 2003 18:15:39 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hAHIDXL7001782;
	Mon, 17 Nov 2003 13:13:34 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311171813.hAHIDXL7001782@workhorse.fictitious.org>
To: "David Allan" <dallan@nortelnetworks.com>
cc: "'tnadeau@cisco.com'" <tnadeau@cisco.com>, curtis@fictitious.org,
        neil.2.harrison@bt.com, kireeti@juniper.net, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: on the mpls oam framework 
In-reply-to: Your message of "Mon, 17 Nov 2003 09:16:47 EST."
             <FFFC48AEAA5F7447929F4F0D93FCC12D02B927DE@zcard031.ca.nortel.com> 
Date: Mon, 17 Nov 2003 13:13:33 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <FFFC48AEAA5F7447929F4F0D93FCC12D02B927DE@zcard031.ca.nortel.com>, "
David Allan" writes:
> Tom:
> 
> I have to admit, the whole ECMP thing provides me with endless amusement.
> Pull a proprietary rabbit out of your hat and then paint those previously
> ignorant of your "feature" as clueless. If you'd been upfront with the fact
> that there was a problem literally "years ago", a lot of creative energy in
> OAM and PWs would not have been wasted.

We been here before.  ECMP has been around in everything from IGPs to
BGP to MPLS.  In IGPs it goes back 15 years.  In BGP 10 years or
more.  In RSVP/TE it was implemented very early on and was no secret.
And ECMP has also been stated as a customer requirement for LDP,
implemented, and deployed there too.

> Meanwhile we have the PW PID which seems to level the playing field across
> the board as an OAM channel for PWs that can carry just about anything
> without getting confused by already deployed ECMP mechanisms, we've also
> given ECMP a lot of thought and an approach is documented in 17fec-cv for
> the LDP layer. IMHO just about everything on the table at this point has
> taken ECMP into account or at least ECMP as well as it is "commonly"
> understood at this point.
> 
> I'm curious, is the ECMP that must be supported exclusively your
> implementation? T'would be nice if the vendors who've deployed ECMP
> documented what they've done in sufficent detail such that we could all
> innovate in this space and knew all variations we needed to comply with.
> Normally defining data plane OAM requires an agreed characterization of the
> data plane. The situation as it stands is intolerable.....
> 
> cheers
> Dave

There really is no secret to how ECMP is done.  There was discussion
on multipath in RFC2991 and RFC2992 and plenty of discussion on this
list and on PWE3.  The PWE3 architecuture
(draft-ietf-pwe3-arch-06.txt) might be insufficient for what you are
looking for because it just covers not breaking this functionality for
PW.  It does indicate that this ECMP stuff is a poorly guarded secret
at worst.

Its true that the only statement tying this to MPLS is "Some router
implementations also allow equal-cost multipath usage with RIP and
other routing protocols."  However, it is a very poorly kept industry
secret that every router from the PC-RT based NSF T1-NSS of late 1980s
vintage until now have used source/destination based hashing for IP
traffic no matter how it has been moved.  This includes concatonated
physical interfaces (a form of bundling), RSVP/TE from ingress, LDP,
and any form of RSVP/TE hierarchy (for example, LDP over RSVP/TE where
the underlying RSVP/TE uses multipath).

Currently draft-ietf-mpls-oam-requirements-02.txt references
draft-allan-mpls-loadbal-01.txt which has expired.  The problem may be
that draft-allan-mpls-loadbal-0x.txt doesn't reflect reality.  Recall
that the objections to this draft were because it did not cover
existing practice.  Perhaps we should start with a load balancing
internet-draft that referenced RFC2991 and RFC2992 and explicitly
referenced the definition of the PW PID (currently in
draft-ietf-pwe3-arch-06.txt).

Curtis



From owner-mpls@UU.NET  Mon Nov 17 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 PAA02535
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 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 QQppga21431
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 20:12:18 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 QQppga21374;
	Mon, 17 Nov 2003 20:12:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppfz11353
	for mpls-outgoing; Mon, 17 Nov 2003 19:54: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 QQppfz11348
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 19:54: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 QQppfz17884
	for <mpls@UU.NET>; Mon, 17 Nov 2003 19:53: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 QQppfz04926
	for <mpls@UU.NET>; Mon, 17 Nov 2003 19:53:53 GMT
Received: from colo-dns-ext2.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: colo-dns-ext2.juniper.net [207.17.137.64])
	id QQppfz04909
	for <mpls@UU.NET>; Mon, 17 Nov 2003 19:53:53 GMT
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	by colo-dns-ext2.juniper.net (8.11.5/8.9.3) with ESMTP id hAHJpTF99752;
	Mon, 17 Nov 2003 11:51:39 -0800 (PST)
	(envelope-from rahul@juniper.net)
Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id hAHJpNt97162;
	Mon, 17 Nov 2003 11:51:23 -0800 (PST)
	(envelope-from rahul@juniper.net)
Received: from localhost (rahul@localhost)
	by sapphire.juniper.net (8.11.6/8.11.3) with ESMTP id hAHJpNL10135;
	Mon, 17 Nov 2003 11:51:23 -0800 (PST)
	(envelope-from rahul@juniper.net)
X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs
Date: Mon, 17 Nov 2003 11:51:22 -0800 (PST)
From: Rahul Aggarwal <rahul@juniper.net>
To: David Allan <dallan@nortelnetworks.com>
cc: "'tnadeau@cisco.com'" <tnadeau@cisco.com>, "" <mpls@UU.NET>
Subject: RE: on the mpls oam framework 
In-Reply-To: <FFFC48AEAA5F7447929F4F0D93FCC12D02B927E3@zcard031.ca.nortel.com>
Message-ID: <20031117113917.K3860@sapphire.juniper.net>
References: <FFFC48AEAA5F7447929F4F0D93FCC12D02B927E3@zcard031.ca.nortel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi Dave,

>
> BTW, would be nice to get some other opinions, IMHO this is rather
> fundamental....
>

To reiterate what has already been said on this thread. A MPLS OAM
framework document must a) Follow the MPLS architecture and b) Discuss
an OAM framework that concerns *practical* problems seen in MPLS deployments.

If folks have issues with MPLS architecture/usage, it should be documented
elsewhere, not in the OAM framework document.

Regards,
rahul


> cheers
> Dave
>
>


From owner-mpls@UU.NET  Mon Nov 17 15:27: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 PAA03527
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 15:27: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 QQppgb16390
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 20:27: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 QQppgb16310;
	Mon, 17 Nov 2003 20:27:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppga01664
	for mpls-outgoing; Mon, 17 Nov 2003 20:11:09 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 QQppga01606
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 20:11:06 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 QQppga00217
	for <mpls@UU.NET>; Mon, 17 Nov 2003 20:10: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 QQppga03230
	for <mpls@UU.NET>; Mon, 17 Nov 2003 20:10:33 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 QQppga03216
	for <mpls@UU.NET>; Mon, 17 Nov 2003 20:10:32 GMT
Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19)
	id <RHZKM8SV>; Mon, 17 Nov 2003 12:10:24 -0800
Message-ID: <9D42C6E086250248810DCADA39CE7EFC01048DA7@nimbus.chromisys.com>
From: John Drake <jdrake@calient.net>
To: "'Rahul Aggarwal'" <rahul@juniper.net>,
        David Allan
	 <dallan@nortelnetworks.com>
Cc: "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Subject: RE: on the mpls oam framework 
Date: Mon, 17 Nov 2003 12:10:23 -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

Very well put

> -----Original Message-----
> From: Rahul Aggarwal [mailto:rahul@juniper.net]
> Sent: Monday, November 17, 2003 11:51 AM
> To: David Allan
> Cc: 'tnadeau@cisco.com'; mpls@UU.NET
> Subject: RE: on the mpls oam framework 
> 
> 
> 
> Hi Dave,
> 
> >
> > BTW, would be nice to get some other opinions, IMHO this is rather
> > fundamental....
> >
> 
> To reiterate what has already been said on this thread. A MPLS OAM
> framework document must a) Follow the MPLS architecture and b) Discuss
> an OAM framework that concerns *practical* problems seen in 
> MPLS deployments.
> 
> If folks have issues with MPLS architecture/usage, it should 
> be documented
> elsewhere, not in the OAM framework document.
> 
> Regards,
> rahul
> 
> 
> > cheers
> > Dave
> >
> >
> 


From owner-mpls@UU.NET  Mon Nov 17 15:53: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 PAA04310
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 15:53: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 QQppgd00012
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 20:53: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 QQppgd29945;
	Mon, 17 Nov 2003 20:53:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppgb03715
	for mpls-outgoing; Mon, 17 Nov 2003 20:29: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 QQppgb03705
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 20:29: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 QQppgb25393
	for <mpls@uu.net>; Mon, 17 Nov 2003 20:28: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 QQppgb00770
	for <mpls@uu.net>; Mon, 17 Nov 2003 20:28:45 GMT
Received: from sj-iport-5.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-5.cisco.com [171.68.10.87])
	id QQppgb00757
	for <mpls@uu.net>; Mon, 17 Nov 2003 20:28:45 GMT
Received: from cisco.com (64.102.124.13)
  by sj-iport-5.cisco.com with ESMTP; 17 Nov 2003 12:29:52 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAHKSdDM002491
	for <mpls@uu.net>; Mon, 17 Nov 2003 15:28:40 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEA92286;
	Mon, 17 Nov 2003 15:28:38 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAHKScV12299 for mpls@uu.net; Mon, 17 Nov 2003 15:28:38 -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 QQppgb03501
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 20:26:54 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 QQppgb10411
	for <mpls@UU.NET>; Mon, 17 Nov 2003 20:26:18 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 QQppgb22107
	for <mpls@UU.NET>; Mon, 17 Nov 2003 20:26:18 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 QQppgb22089
	for <mpls@UU.NET>; Mon, 17 Nov 2003 20:26:17 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hAHKQcL7002242;
	Mon, 17 Nov 2003 15:26:39 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311172026.hAHKQcL7002242@workhorse.fictitious.org>
To: "David Allan" <dallan@nortelnetworks.com>
cc: "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: on the mpls oam framework 
In-reply-to: Your message of "Mon, 17 Nov 2003 11:11:39 EST."
             <FFFC48AEAA5F7447929F4F0D93FCC12D02B927E3@zcard031.ca.nortel.com> 
Date: Mon, 17 Nov 2003 15:26:38 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <FFFC48AEAA5F7447929F4F0D93FCC12D02B927E3@zcard031.ca.nortel.com>, "
David Allan" writes:
> 
> As I say, we all need to be able to innovate in this space. At the moment
> the majority of the list is disenfranchized. This is a problem. Either the
> WG sticks with the decision that this is not specified and recognizes that
> the quality of what it gets for interoperable OAM is unknowable, or people
> at least 'fess up informationally and we can all participate. Which version
> do you think is the IETF way....
> 
> BTW, would be nice to get some other opinions, IMHO this is rather
> fundamental....
> 
> cheers
> Dave


Dave,

MPLS Ping has a means defined to determine that an ECMP branch point
exists, and a means to provide the means to exercise each branch.
This is all independent of the algorithm used to accomplished the
split, hash based or other.  That is a move forward technically.  The
alternate of randomly spraying addresses across the 127/8 space has
also been suggested as a solution that from a practical standpoint
covers the problem, though with no certainty.

This is a solved problem.  Can we stop moving backwards.  If you can
improve on the solution, that would be welcome too.  Substituting
Y.1711 for the solutions being worked on in the IETF and complaining
that Y.1711 doesn't handle ECMP is not seen as an improvement.

Curtis



From owner-mpls@UU.NET  Mon Nov 17 15:54: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 PAA04369
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 15:54: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 QQppgd19120
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 20:54: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 QQppgd19089;
	Mon, 17 Nov 2003 20:54:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppgc03977
	for mpls-outgoing; Mon, 17 Nov 2003 20:31: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 QQppgc03972
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 20:31: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 QQppgc23056
	for <mpls@UU.NET>; Mon, 17 Nov 2003 20:31: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 QQppgc20936
	for <mpls@UU.NET>; Mon, 17 Nov 2003 20:31:04 GMT
Received: from hank.bcentralhost.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hank.bcentralhost.com [205.158.155.16])
	id QQppgc20919
	for <mpls@UU.NET>; Mon, 17 Nov 2003 20:31:03 GMT
Received: (root@localhost)
	by hank.bcentralhost.com
	id PAA17260; Mon, 17 Nov 2003 15:31:00 -0500 (EST)
	[ConcentricHost SMTP Relay 1.14]
Message-ID: <200311172031.PAA17260@hank.bcentralhost.com>
From: mark seery <mark@interflect.com>
To: Rahul Aggarwal <rahul@juniper.net>
Subject: RE: on the mpls oam framework
Cc: <mpls@UU.NET>
Date: Mon, 17 Nov 2003 15:31:00 -0500 (EST)
In-Reply-To: <FFFC48AEAA5F7447929F4F0D93FCC12D02B927E3@zcard031.ca.nortel.com> from Rahul Aggarwal <rahul@juniper.net> on Mon, 17 Nov 2003 11:51:22 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



---- Rahul Aggarwal <rahul@juniper.net> wrote:
> 
> Hi Dave,
> 
> >
> > BTW, would be nice to get some other opinions, IMHO this is rather
> > fundamental....
> >
> 
> To reiterate what has already been said on this thread. A MPLS OAM
> framework document must a) Follow the MPLS architecture and b) Discuss
> an OAM framework that concerns *practical* problems seen in MPLS deployments.
> 
> If folks have issues with MPLS architecture/usage, it should be documented
> elsewhere, not in the OAM framework document.
> 
> Regards,
> rahul

Rahul,

Sounds like a fair point. But just so I am understanding you clearly, are you saying these issues should not be discussed in any OAM document, or just during the framework development stage?

Thanks,
Mark


From owner-mpls@UU.NET  Mon Nov 17 15:56: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 PAA04421
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 15:56: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 QQppgd05759
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 20:56: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 QQppgd05714;
	Mon, 17 Nov 2003 20:56:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppgc04177
	for mpls-outgoing; Mon, 17 Nov 2003 20:34: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 QQppgc04165
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 20:34:31 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 QQppgc27709
	for <mpls@UU.NET>; Mon, 17 Nov 2003 20:33: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 QQppgc24944
	for <mpls@UU.NET>; Mon, 17 Nov 2003 20:33:55 GMT
Received: from hank.bcentralhost.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hank.bcentralhost.com [205.158.155.16])
	id QQppgc24894
	for <mpls@UU.NET>; Mon, 17 Nov 2003 20:33:53 GMT
Received: (root@localhost)
	by hank.bcentralhost.com
	id PAA18768; Mon, 17 Nov 2003 15:33:47 -0500 (EST)
	[ConcentricHost SMTP Relay 1.14]
Message-ID: <200311172033.PAA18768@hank.bcentralhost.com>
From: mark seery <mark@interflect.com>
To: <curtis@fictitious.org>
Subject: Re: on the mpls oam framework
Cc: <mpls@UU.NET>
Date: Mon, 17 Nov 2003 15:33:47 -0500 (EST)
In-Reply-To: <200311172031.hAHKVBL7002274@workhorse.fictitious.org> from Curtis Villamizar <curtis@workhorse.fictitious.org> on Mon, 17 Nov 2003 15:31:11 -0500
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



---- Curtis Villamizar <curtis@workhorse.fictitious.org> wrote:
> 
> In message <3FB8F9A5.5010306@interflect.com>, mark seery writes:
> > David Allan wrote:
> > 
> > >BTW, would be nice to get some other opinions, IMHO this is rather
> > >fundamental....
> > >
> > One of the fundamental precepts of routing, is that each node 
> > understands the routing decisions each other node makes, this is to 
> > prevent black holing among other things. So for example, the SPF 
> > algorithm is not a secret, precisely so that each router in a network 
> > can make consistent decisions. As ECMP algorithms impact the forwarding 
> > direction of packets, then I would suggest while not on the same level 
> > of criticality as SPF, there is a similar logic that could be applied to 
> > this case. I have similar thoughts about end-to-end QoS (but that's way 
> > OT, just sited as another example).
> 
> That was never the case.
> 
> Each OSPF node did not have to know whether the downstream node did
> ECMP and if it did whether it was a dumb per packet split or a hash
> based, or something else.  It only had to know that the next node
> downstream kept the packet going in the direction of lower OSPF cost.

Curtis, I respect your opinion and experience, but it seems to me you keep referring back to ECMP in a native IP environment where everyone is using the same hashing algorithm.


From owner-mpls@UU.NET  Mon Nov 17 15:57: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 PAA04460
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 15:57: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 QQppgd07173
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 20:57: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 QQppgd07136;
	Mon, 17 Nov 2003 20:57:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppgc04154
	for mpls-outgoing; Mon, 17 Nov 2003 20:34: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 QQppgc04141
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 20:34: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 QQppgc19196
	for <mpls@uu.net>; Mon, 17 Nov 2003 20:32: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 QQppgc06318
	for <mpls@uu.net>; Mon, 17 Nov 2003 20:32:45 GMT
Received: from sj-iport-4.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-4.cisco.com [171.68.10.86])
	id QQppgc06288
	for <mpls@uu.net>; Mon, 17 Nov 2003 20:32:44 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAHKWfxg029854
	for <mpls@uu.net>; Mon, 17 Nov 2003 15:32:41 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEA92774;
	Mon, 17 Nov 2003 15:32:39 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAHKWdm12737 for mpls@uu.net; Mon, 17 Nov 2003 15:32:39 -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 QQppgc04000
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 20:31: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 QQppgc14308
	for <mpls@UU.NET>; Mon, 17 Nov 2003 20:30: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 QQppgc20529
	for <mpls@UU.NET>; Mon, 17 Nov 2003 20:30:43 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 QQppgc20496
	for <mpls@UU.NET>; Mon, 17 Nov 2003 20:30:42 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hAHKVBL7002274;
	Mon, 17 Nov 2003 15:31:11 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311172031.hAHKVBL7002274@workhorse.fictitious.org>
To: mark seery <mark@interflect.com>
cc: David Allan <dallan@nortelnetworks.com>,
        "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: on the mpls oam framework 
In-reply-to: Your message of "Mon, 17 Nov 2003 08:39:01 PST."
             <3FB8F9A5.5010306@interflect.com> 
Date: Mon, 17 Nov 2003 15:31:11 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <3FB8F9A5.5010306@interflect.com>, mark seery writes:
> David Allan wrote:
> 
> >BTW, would be nice to get some other opinions, IMHO this is rather
> >fundamental....
> >
> One of the fundamental precepts of routing, is that each node 
> understands the routing decisions each other node makes, this is to 
> prevent black holing among other things. So for example, the SPF 
> algorithm is not a secret, precisely so that each router in a network 
> can make consistent decisions. As ECMP algorithms impact the forwarding 
> direction of packets, then I would suggest while not on the same level 
> of criticality as SPF, there is a similar logic that could be applied to 
> this case. I have similar thoughts about end-to-end QoS (but that's way 
> OT, just sited as another example).

That was never the case.

Each OSPF node did not have to know whether the downstream node did
ECMP and if it did whether it was a dumb per packet split or a hash
based, or something else.  It only had to know that the next node
downstream kept the packet going in the direction of lower OSPF cost.

> In addition, having worked at a vendor trying to work out the best way 
> to do ECMP (which is not easy task in an MPLS environment) it sure would 
> have been nice to have an industry-agreed way of doing this. While I 
> realise 802.1ad have gotten away with not agreeing to alogorithms, that 
> is on a point-to-point basis. When an algorithm impacts end-to-end 
> (within an area/AS at least) then I think the need to have an agreed 
> upon standard is more important.
> 
> So bottom line is I would have to agree that two routers from different 
> vendors can not communicate in the same network using ECMP unless the 
> algorithm is known by both. So if ECMP is in an architecture or 
> framework document, then it is not a proprietary feature, and therefore 
> it should be standardized.

There is plenty of existance proof that contradicts the assertion in
your last paragraph.

Curtis



From owner-mpls@UU.NET  Mon Nov 17 16:24: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 QAA06170
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 16:24:45 -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 QQppgf15308
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 21:24: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 QQppgf14976;
	Mon, 17 Nov 2003 21:24:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppge26283
	for mpls-outgoing; Mon, 17 Nov 2003 21:06: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 QQppge26264
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 21:06: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 QQppge17480
	for <mpls@UU.NET>; Mon, 17 Nov 2003 21:04: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 QQppge29045
	for <mpls@UU.NET>; Mon, 17 Nov 2003 21:04:36 GMT
Received: from hank.bcentralhost.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hank.bcentralhost.com [205.158.155.16])
	id QQppge29021
	for <mpls@UU.NET>; Mon, 17 Nov 2003 21:04:35 GMT
Received: (root@localhost)
	by hank.bcentralhost.com
	id QAA03751; Mon, 17 Nov 2003 16:04:30 -0500 (EST)
	[ConcentricHost SMTP Relay 1.14]
Message-ID: <200311172104.QAA03751@hank.bcentralhost.com>
From: mark seery <mark@interflect.com>
To: <curtis@fictitious.org>
Subject: Re: on the mpls oam framework
Cc: <mpls@UU.NET>
Date: Mon, 17 Nov 2003 16:04:30 -0500 (EST)
In-Reply-To: <200311172031.hAHKVBL7002274@workhorse.fictitious.org> from Curtis Villamizar <curtis@workhorse.fictitious.org> on Mon, 17 Nov 2003 15:31:11 -0500
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



---- Curtis Villamizar <curtis@workhorse.fictitious.org> wrote:

> > So bottom line is I would have to agree that two routers from different 
> > vendors can not communicate in the same network using ECMP unless the 
> > algorithm is known by both. So if ECMP is in an architecture or 
> > framework document, then it is not a proprietary feature, and therefore 
> > it should be standardized.
> 
> There is plenty of existance proof that contradicts the assertion in
> your last paragraph.
> 
> Curtis

As soon as I sent this I knew the statement was too strong. My concern is that if two routers in the same network think the same packet is part of two different microflows because they use different algorithms, then undesireable results could emerge. I will add no more on this subject if it is the consensus of the group that either:

a) this is incorrect from a technical perspective
b) only known practical issues are worthy of discussion
c) this is not the time or place for this discussion

thanks,
mark


From owner-mpls@UU.NET  Mon Nov 17 16:28: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 QAA06339
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 16:28: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 QQppgf21840
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 21:28:31 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 QQppgf21563;
	Mon, 17 Nov 2003 21:28:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppge26705
	for mpls-outgoing; Mon, 17 Nov 2003 21:09: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 QQppge26669
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 21:09: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 QQppge15068
	for <mpls@uu.net>; Mon, 17 Nov 2003 21:09: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 QQppge04952
	for <mpls@uu.net>; Mon, 17 Nov 2003 21:09:00 GMT
Received: from sj-iport-5.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-5.cisco.com [171.68.10.87])
	id QQppge04941
	for <mpls@uu.net>; Mon, 17 Nov 2003 21:08:59 GMT
Received: from cisco.com (171.71.177.238)
  by sj-iport-5.cisco.com with ESMTP; 17 Nov 2003 13:10:07 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAHL8ptm002689
	for <mpls@uu.net>; Mon, 17 Nov 2003 13:08:57 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEA97116;
	Mon, 17 Nov 2003 16:08:50 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAHL8oO19671 for mpls@uu.net; Mon, 17 Nov 2003 16:08:50 -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 QQppge26278
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 21:06: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 QQppge17811
	for <mpls@UU.NET>; Mon, 17 Nov 2003 21:04: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 QQppge04462
	for <mpls@UU.NET>; Mon, 17 Nov 2003 21:04:49 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 QQppge04429
	for <mpls@UU.NET>; Mon, 17 Nov 2003 21:04:47 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hAHL5PL7002539;
	Mon, 17 Nov 2003 16:05:25 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311172105.hAHL5PL7002539@workhorse.fictitious.org>
To: mark seery <mark@interflect.com>
cc: curtis@fictitious.org, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: on the mpls oam framework 
In-reply-to: Your message of "Mon, 17 Nov 2003 15:33:47 EST."
             <200311172033.PAA18768@hank.bcentralhost.com> 
Date: Mon, 17 Nov 2003 16:05:25 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <200311172033.PAA18768@hank.bcentralhost.com>, mark seery writes:
> 
> 
> ---- Curtis Villamizar <curtis@workhorse.fictitious.org> wrote:
> > 
> > In message <3FB8F9A5.5010306@interflect.com>, mark seery writes:
> > > David Allan wrote:
> > > 
> > > >BTW, would be nice to get some other opinions, IMHO this is rather
> > > >fundamental....
> > > >
> > > One of the fundamental precepts of routing, is that each node 
> > > understands the routing decisions each other node makes, this is to 
> > > prevent black holing among other things. So for example, the SPF 
> > > algorithm is not a secret, precisely so that each router in a network 
> > > can make consistent decisions. As ECMP algorithms impact the forwarding 
> > > direction of packets, then I would suggest while not on the same level 
> > > of criticality as SPF, there is a similar logic that could be applied to 
> > > this case. I have similar thoughts about end-to-end QoS (but that's way 
> > > OT, just sited as another example).
> > 
> > That was never the case.
> > 
> > Each OSPF node did not have to know whether the downstream node did
> > ECMP and if it did whether it was a dumb per packet split or a hash
> > based, or something else.  It only had to know that the next node
> > downstream kept the packet going in the direction of lower OSPF cost.
>  
> Curtis, I respect your opinion and experience, but it seems to me you
> keep referring back to ECMP in a native IP environment where everyone
> is using the same hashing algorithm.

That is not true.  Early on Cisco used per packet load splitting and
did not use a hash based algorithm.  It is still not certain what hash
algorithm anyone is using for those that do a hash.  It also does not
matter whether the hash is based on src/dst only or also includes the
TCP port numbers for TCP.

Therefore it is not "one of the fundamental precepts of routing" that
each node understand the ECMP algorithms used by the other nodes.
Each router must behave within some constraints required to keep the
routing protocol loop free.

Curtis



From owner-mpls@UU.NET  Mon Nov 17 16:32: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 QAA06489
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 16:32:26 -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 QQppgg28065
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 21:32: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 QQppgg27810;
	Mon, 17 Nov 2003 21:32:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppge27174
	for mpls-outgoing; Mon, 17 Nov 2003 21:11: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 QQppge27168
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 21:11:53 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 QQppge20142
	for <mpls@UU.NET>; Mon, 17 Nov 2003 21:11: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 QQppge08216
	for <mpls@UU.NET>; Mon, 17 Nov 2003 21:11:20 GMT
Received: from hank.bcentralhost.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hank.bcentralhost.com [205.158.155.16])
	id QQppge08165
	for <mpls@UU.NET>; Mon, 17 Nov 2003 21:11:18 GMT
Received: (root@localhost)
	by hank.bcentralhost.com
	id QAA06667; Mon, 17 Nov 2003 16:11:13 -0500 (EST)
	[ConcentricHost SMTP Relay 1.14]
Message-ID: <200311172111.QAA06667@hank.bcentralhost.com>
From: mark seery <mark@interflect.com>
To: <curtis@fictitious.org>
Subject: Re: on the mpls oam framework
Cc: <mpls@UU.NET>
Date: Mon, 17 Nov 2003 16:11:13 -0500 (EST)
In-Reply-To: <200311172105.hAHL5PL7002539@workhorse.fictitious.org> from Curtis Villamizar <curtis@workhorse.fictitious.org> on Mon, 17 Nov 2003 16:05:25 -0500
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



---- Curtis Villamizar <curtis@workhorse.fictitious.org> wrote:
> Therefore it is not "one of the fundamental precepts of routing" that
> each node understand the ECMP algorithms used by the other nodes.

Curtis, it is grossly misleading to restate what I said in that way. I find that a little disappointing. But I accept your point that there is an existence proof that different algorithms can work in the same network. We will see if this holds true when multi-protocol traffic is routed between different vendors as well, perhaps as you say it will.

Mark.


From owner-mpls@UU.NET  Mon Nov 17 16:42: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 QAA07132
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 16:42: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 QQppgg01232
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 21:42:19 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 QQppgg00953;
	Mon, 17 Nov 2003 21:42:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppgf28907
	for mpls-outgoing; Mon, 17 Nov 2003 21:22:45 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 QQppgf28897
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 21:22:42 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 QQppgf06937
	for <mpls@uu.net>; Mon, 17 Nov 2003 21:18: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 QQppgf24625
	for <mpls@uu.net>; Mon, 17 Nov 2003 21:18:39 GMT
Received: from sj-iport-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71])
	id QQppgf24603
	for <mpls@uu.net>; Mon, 17 Nov 2003 21:18:39 GMT
Received: from cisco.com (171.71.177.237)
  by sj-iport-2.cisco.com with ESMTP; 17 Nov 2003 13:22:03 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAHLIaAt008378
	for <mpls@uu.net>; Mon, 17 Nov 2003 13:18:36 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEA98048;
	Mon, 17 Nov 2003 16:18:35 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAHLIZ820360 for mpls@uu.net; Mon, 17 Nov 2003 16:18:35 -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 QQppgf28487
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 21:17:33 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 QQppgf24241
	for <mpls@UU.NET>; Mon, 17 Nov 2003 21:17: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 QQppgf16995
	for <mpls@UU.NET>; Mon, 17 Nov 2003 21:16:59 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 QQppgf16967
	for <mpls@UU.NET>; Mon, 17 Nov 2003 21:16:58 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hAHLHbL7002752;
	Mon, 17 Nov 2003 16:17:37 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311172117.hAHLHbL7002752@workhorse.fictitious.org>
To: mark seery <mark@interflect.com>
cc: curtis@fictitious.org, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: on the mpls oam framework 
In-reply-to: Your message of "Mon, 17 Nov 2003 16:04:30 EST."
             <200311172104.QAA03751@hank.bcentralhost.com> 
Date: Mon, 17 Nov 2003 16:17:37 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <200311172104.QAA03751@hank.bcentralhost.com>, mark seery writes:
> 
> 
> ---- Curtis Villamizar <curtis@workhorse.fictitious.org> wrote:
> 
> > > So bottom line is I would have to agree that two routers from different 
> > > vendors can not communicate in the same network using ECMP unless the 
> > > algorithm is known by both. So if ECMP is in an architecture or 
> > > framework document, then it is not a proprietary feature, and therefore 
> > > it should be standardized.
> > 
> > There is plenty of existance proof that contradicts the assertion in
> > your last paragraph.
> > 
> > Curtis
> 
> As soon as I sent this I knew the statement was too strong. My concern is tha
> t if two routers in the same network think the same packet is part of two dif
> ferent microflows because they use different algorithms, then undesireable re
> sults could emerge. I will add no more on this subject if it is the consensus
>  of the group that either:
> 
> a) this is incorrect from a technical perspective
> b) only known practical issues are worthy of discussion
> c) this is not the time or place for this discussion
> 
> thanks,
> mark


If two routers in a path do a split (happens in IGP, LDP or heirarchy
in RSVP/TE) and use an identical hash, then the downstream split will
always see microflows filtered by the first split.  If both are 2:1
splits, then the second becomes a NOOP because all of the packets
falling into one side of the hash have already been removed.

It is therefore a requirement that the hash be seeded independently by
each node in the topology.  This hash seeding is usually random with
input from addressing and things such as time of day in fine
granularity (usec or nsec) or other pseudorandom seed.  No node knows
how any other nodes have seeded the hash.  Nothing breaks as a result
of this.

[That would be a) above.]

I think enough has been said about Dave's "fundamental precept of
routing".  Next topic please.

Curtis



From owner-mpls@UU.NET  Mon Nov 17 17:07: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 RAA08771
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 17:07: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 QQppgi06585
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 22:07: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 QQppgi06402;
	Mon, 17 Nov 2003 22:07:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppgh01826
	for mpls-outgoing; Mon, 17 Nov 2003 21:49: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 QQppgh01818
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 21:49: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 QQppgh12440
	for <mpls@uu.net>; Mon, 17 Nov 2003 21:48: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 QQppgh19853
	for <mpls@uu.net>; Mon, 17 Nov 2003 21:48:56 GMT
Received: from sj-iport-5.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-5.cisco.com [171.68.10.87])
	id QQppgh19837
	for <mpls@uu.net>; Mon, 17 Nov 2003 21:48:56 GMT
Received: from cisco.com (64.102.124.13)
  by sj-iport-5.cisco.com with ESMTP; 17 Nov 2003 13:50:04 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAHLmoDO017615
	for <mpls@uu.net>; Mon, 17 Nov 2003 16:48:53 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEB01750;
	Mon, 17 Nov 2003 16:48:50 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAHLmoZ26071 for mpls@uu.net; Mon, 17 Nov 2003 16:48:50 -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 QQppgh01747
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 21:47: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 QQppgh06694
	for <mpls@UU.NET>; Mon, 17 Nov 2003 21: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 QQppgh04721
	for <mpls@UU.NET>; Mon, 17 Nov 2003 21:46: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 QQppgh04703
	for <mpls@UU.NET>; Mon, 17 Nov 2003 21:46:38 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hAHLlGL7002935;
	Mon, 17 Nov 2003 16:47:16 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311172147.hAHLlGL7002935@workhorse.fictitious.org>
To: mark seery <mark@interflect.com>
cc: curtis@fictitious.org, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: on the mpls oam framework 
In-reply-to: Your message of "Mon, 17 Nov 2003 16:11:13 EST."
             <200311172111.QAA06667@hank.bcentralhost.com> 
Date: Mon, 17 Nov 2003 16:47:16 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <200311172111.QAA06667@hank.bcentralhost.com>, mark seery writes:
> 
> 
> > Therefore it is not "one of the fundamental precepts of routing" that
> > each node understand the ECMP algorithms used by the other nodes.
> 
> Curtis, it is grossly misleading to restate what I said in that way. I find t
> hat a little disappointing. But I accept your point that there is an existenc
> e proof that different algorithms can work in the same network. We will see i
> f this holds true when multi-protocol traffic is routed between different ven
> dors as well, perhaps as you say it will.
> 
> Mark.


Multiprotocol traffic is already being routed in multivendor networks
with ECMP.  It isn't pretty, but looking for a valid IP header and
falling back to per label split works.

All that is required is that each node recognize that traffic which
contains identifiable microflows, doesn't split traffic that does not
contain identifiable microflows, and that for traffic containing
identifiable microflows any given microflow takes a single path.
The PW PID formalizes the means to determine the traffic type.

Curtis



From owner-mpls@UU.NET  Mon Nov 17 17:36: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 RAA10336
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 17: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 QQppgk27387
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 22:36: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 QQppgk27110;
	Mon, 17 Nov 2003 22:36:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppgj23691
	for mpls-outgoing; Mon, 17 Nov 2003 22:17: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 QQppgj23686
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 22:17:50 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 QQppgj27757
	for <mpls@UU.NET>; Mon, 17 Nov 2003 22:16: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 QQppgj16886
	for <mpls@UU.NET>; Mon, 17 Nov 2003 22:16:44 GMT
Received: from hank.bcentralhost.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hank.bcentralhost.com [205.158.155.16])
	id QQppgj16872
	for <mpls@UU.NET>; Mon, 17 Nov 2003 22:16:43 GMT
Received: (root@localhost)
	by hank.bcentralhost.com
	id RAA06099; Mon, 17 Nov 2003 17:16:38 -0500 (EST)
	[ConcentricHost SMTP Relay 1.14]
Message-ID: <200311172216.RAA06099@hank.bcentralhost.com>
From: mark seery <mark@interflect.com>
To: <curtis@fictitious.org>
Subject: Re: on the mpls oam framework
Cc: <mpls@UU.NET>
Date: Mon, 17 Nov 2003 17:16:38 -0500 (EST)
In-Reply-To: <200311172147.hAHLlGL7002935@workhorse.fictitious.org> from Curtis Villamizar <curtis@workhorse.fictitious.org> on Mon, 17 Nov 2003 16:47:16 -0500
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Curtis, I appreciate the time you have taken to fill in the holes.

Some last comments below.

Mark

---- Curtis Villamizar <curtis@workhorse.fictitious.org> wrote:

> Multiprotocol traffic is already being routed in multivendor networks
> with ECMP.  It isn't pretty, but looking for a valid IP header and
> falling back to per label split works.
> 
> All that is required is that each node recognize that traffic which
> contains identifiable microflows, doesn't split traffic that does not
> contain identifiable microflows, and that for traffic containing
> identifiable microflows any given microflow takes a single path.

That makes a great deal of sense when there is an agreed upon mechanism to do this,........

> The PW PID formalizes the means to determine the traffic type.

....and this is the agreed upon mechanism, thanks. I had not made the leap that all MPLS traffic that wanted to make use of ECMP was now going to be PW-based; the lack of a PID being the key historical reason why I had trouble with this.

thanks again.
mark


From owner-mpls@UU.NET  Mon Nov 17 17:46: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 RAA10837
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 17:46: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 QQppgl11513
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 22:47: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 QQppgl11329;
	Mon, 17 Nov 2003 22:46:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppgj24405
	for mpls-outgoing; Mon, 17 Nov 2003 22:28: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 QQppgj24396
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 22:28: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 QQppgj20174
	for <mpls@UU.NET>; Mon, 17 Nov 2003 22:27: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 QQppgj03144
	for <mpls@UU.NET>; Mon, 17 Nov 2003 22:27:48 GMT
Received: from mailhost.avici.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [12.38.212.174])
	id QQppgj03130
	for <mpls@UU.NET>; Mon, 17 Nov 2003 22:27:47 GMT
Received: from aatlas-lt2.avici.com (b2-pc109.avici.com [10.2.100.109])
	by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id hAHMO6EA027212;
	Mon, 17 Nov 2003 17:24:06 -0500
Message-Id: <5.1.0.14.2.20031117172429.01d56a18@mailhost.avici.com>
X-Sender: aatlas@mailhost.avici.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 17 Nov 2003 17:27:23 -0500
To: mark seery <mark@interflect.com>
From: Alia Atlas <aatlas@avici.com>
Subject: Re: on the mpls oam framework
Cc: <curtis@fictitious.org>, <mpls@UU.NET>
In-Reply-To: <200311172104.QAA03751@hank.bcentralhost.com>
References: <200311172031.hAHKVBL7002274@workhorse.fictitious.org>
 <curtis@workhorse.fictitious.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 04:04 PM 11/17/2003, mark seery wrote:
>As soon as I sent this I knew the statement was too strong. My concern is 
>that if two routers in the same network think the same packet is part of 
>two different microflows because they use different algorithms, then 
>undesireable results could emerge. I will add no more on this subject if 
>it is the consensus of the group that either:

It is in fact extremely desirable for two routers to think of micro-flows 
differently, as long as they don't break up a micro-flow from the 
end-system perspective.  If two routers classify all packets identically 
into a set of micro-flows, then if router A sends micro-flow 1 to router B, 
router B can only send it on as a single micro-flow to one of its primary 
neighbors, instead of breaking it into different micro-flows and sending 
different micro-flows to each of B's primary neighbors.

Alia

>a) this is incorrect from a technical perspective
>b) only known practical issues are worthy of discussion
>c) this is not the time or place for this discussion
>
>thanks,
>mark




From owner-mpls@UU.NET  Mon Nov 17 19:14: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 TAA15008
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 19:14: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 QQppgr13391
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 00:15: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 QQppgq13067;
	Tue, 18 Nov 2003 00:14:59 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppgp21224
	for mpls-outgoing; Mon, 17 Nov 2003 23:56: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 QQppgp21215
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Nov 2003 23:56:15 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 QQppgp05330
	for <mpls@UU.NET>; Mon, 17 Nov 2003 23:55: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 QQppgp26319
	for <mpls@UU.NET>; Mon, 17 Nov 2003 23:55:25 GMT
Received: from hank.bcentralhost.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hank.bcentralhost.com [205.158.155.16])
	id QQppgp26297
	for <mpls@UU.NET>; Mon, 17 Nov 2003 23:55:24 GMT
Received: (root@localhost)
	by hank.bcentralhost.com
	id SAA16153; Mon, 17 Nov 2003 18:55:12 -0500 (EST)
	[ConcentricHost SMTP Relay 1.14]
Message-ID: <200311172355.SAA16153@hank.bcentralhost.com>
From: mark seery <mark@interflect.com>
To: Alia Atlas <aatlas@avici.com>
Subject: Re: on the mpls oam framework
Cc: <mpls@UU.NET>
Date: Mon, 17 Nov 2003 18:55:12 -0500 (EST)
In-Reply-To: <200311172031.hAHKVBL7002274@workhorse.fictitious.org> <curtis@workhorse.fictitious.org> from Alia Atlas <aatlas@avici.com> on Mon, 17 Nov 2003 17:27:23 -0500
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



---- Alia Atlas <aatlas@avici.com> wrote:
> At 04:04 PM 11/17/2003, mark seery wrote:
> >As soon as I sent this I knew the statement was too strong. My concern is 
> >that if two routers in the same network think the same packet is part of 
> >two different microflows because they use different algorithms, then 
> >undesireable results could emerge. I will add no more on this subject if 
> >it is the consensus of the group that either:
> 
> It is in fact extremely desirable for two routers to think of micro-flows 
> differently, as long as they don't break up a micro-flow from the 
> end-system perspective.  If two routers classify all packets identically 
> into a set of micro-flows, then if router A sends micro-flow 1 to router B, 
> router B can only send it on as a single micro-flow to one of its primary 
> neighbors, instead of breaking it into different micro-flows and sending 
> different micro-flows to each of B's primary neighbors.
> 
> Alia

Hi Alia, that is a very good point and I understand what you are saying. My only point would be that the classification mechanism would ideally be consistent, leading to not only "as long as they don't break up a micro-flow from the end-system perspective" but also from a network perspective, i.e. in a way that no loops form, or even simply in such a way that traffic flows according to expectations. I am satisfied that the use of PID, as Curtis described, is constructive in reaching this goal.

My apologies to the group if this was wasted bandwidth.

Thanks,
Mark


From owner-mpls@UU.NET  Mon Nov 17 19: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 TAA15135
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 19:20: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 QQppgr20501
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 00:20: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 QQppgr20366;
	Tue, 18 Nov 2003 00:20:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppgq09646
	for mpls-outgoing; Tue, 18 Nov 2003 00:05: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 QQppgq09631
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 00:05:12 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 QQppgq22189
	for <mpls@UU.NET>; Tue, 18 Nov 2003 00:04: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 QQppgq06028
	for <mpls@UU.NET>; Tue, 18 Nov 2003 00:04:45 GMT
Received: from kummer.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint2.juniper.net [207.17.136.150])
	id QQppgq06008
	for <mpls@UU.NET>; Tue, 18 Nov 2003 00:04:44 GMT
Received: from kummer.juniper.net (localhost [127.0.0.1])
	by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id hAI04hda065084;
	Mon, 17 Nov 2003 16:04:43 -0800 (PST)
	(envelope-from kireeti@juniper.net)
Received: from localhost (kireeti@localhost)
	by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id hAI04glP065081;
	Mon, 17 Nov 2003 16:04:43 -0800 (PST)
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
Date: Mon, 17 Nov 2003 16:04:42 -0800 (PST)
From: Kireeti Kompella <kireeti@juniper.net>
To: mark seery <mark@interflect.com>
cc: mpls@UU.NET
Subject: On ECMP
In-Reply-To: <3FB8F9A5.5010306@interflect.com>
Message-ID: <20031117151304.T64147@kummer.juniper.net>
References: <FFFC48AEAA5F7447929F4F0D93FCC12D02B927E3@zcard031.ca.nortel.com>
 <3FB8F9A5.5010306@interflect.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Mark,

(Please note change of subject.)

On Mon, 17 Nov 2003, mark seery wrote:

> One of the fundamental precepts of routing, is that each node
> understands the routing decisions each other node makes,

I don't agree.  For a simple example: in RIP, a router has no idea
what the next hop will do.  Another (before y'all jump on me for
saying that RIP is a routing protocol) is BGP.  Link state protocols
are different -- in a sense, they give you too much information.

> this is to
> prevent black holing among other things.

This is the job of routing protocols, not individual routers.

> So for example, the SPF
> algorithm is not a secret,

Actually, the SPF *algorithm* can be a secret.  The result (a shortest
path dag) is not a secret.  It can be (and has been) proven that if
each router computes a spdag based on the same topology info, then no
black holes arise.

> As ECMP algorithms impact the forwarding
> direction of packets, then I would suggest while not on the same level
> of criticality as SPF, there is a similar logic that could be applied to
> this case.

Different ECMP algorithms have happily co-existed in networks for a
long time now.  The algorithms can be different, but there must be a
consisten result; in this case, packets in a 'flow', whatever that is,
must not be reordered.

There are both IP and MPLS networks with multi-vendor equipment with
ECMP and they work just fine.

> In addition, having worked at a vendor trying to work out the best way
> to do ECMP

Whole 'nuther ball game.  Very very hard question.  If I had an
answer, I sure wouldn't share it :-)

> So bottom line is I would have to agree that two routers from different
> vendors can not communicate in the same network using ECMP unless the
> algorithm is known by both.

See above.

This is easy to see if you consider that an ECMP path is a set of
choices in the data plane that *could* correctly have been made
instead in the control plane; and that the set of choices is stable
for a given packet flow.

Kireeti.
-------


From owner-mpls@UU.NET  Mon Nov 17 20:11: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 UAA16777
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 20:11: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 QQppgu03724
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 01:11: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 QQppgu03560;
	Tue, 18 Nov 2003 01:11:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppgt14889
	for mpls-outgoing; Tue, 18 Nov 2003 00:48: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 QQppgt14884
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 00:48:46 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 QQppgt25651
	for <mpls@UU.NET>; Tue, 18 Nov 2003 00:46: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 QQppgt29393
	for <mpls@UU.NET>; Tue, 18 Nov 2003 00:46:22 GMT
Received: from hank.bcentralhost.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hank.bcentralhost.com [205.158.155.16])
	id QQppgs22099
	for <mpls@UU.NET>; Tue, 18 Nov 2003 00:43:25 GMT
Received: (root@localhost)
	by hank.bcentralhost.com
	id TAA03664; Mon, 17 Nov 2003 19:43:12 -0500 (EST)
	[ConcentricHost SMTP Relay 1.14]
Message-ID: <200311180043.TAA03664@hank.bcentralhost.com>
From: mark seery <mark@interflect.com>
To: Kireeti Kompella <kireeti@juniper.net>
Subject: Re: On ECMP
Cc: <mpls@UU.NET>
Date: Mon, 17 Nov 2003 19:43:12 -0500 (EST)
In-Reply-To: <FFFC48AEAA5F7447929F4F0D93FCC12D02B927E3@zcard031.ca.nortel.com> <3FB8F9A5.5010306@interflect.com> from Kireeti Kompella <kireeti@juniper.net> on Mon, 17 Nov 2003 16:04:42 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Kireeti,

---- Kireeti Kompella <kireeti@juniper.net> wrote:
> Hi Mark,
> 
> (Please note change of subject.)

Noted - good idea, should have been done earlier, agreed.
> 
> On Mon, 17 Nov 2003, mark seery wrote:
> 
> > One of the fundamental precepts of routing, is that each node
> > understands the routing decisions each other node makes,
> 
> I don't agree.  For a simple example: in RIP, a router has no idea
> what the next hop will do.  Another (before y'all jump on me for
> saying that RIP is a routing protocol) is BGP.  Link state protocols
> are different -- in a sense, they give you too much information.

Oh yeah, thanks for reminding me of the conistency of topology knowledge in those other protocols ;-) (clearly a case of sarcasm).

Seriously, if I am wrong that OSPF and IS-IS assume every router in an area are using the same algorithm, then would appreciate being corrected. That path and distance vector algorithms advertise routes and select best routes based on policy etc. is different than the case when a common algorithm is being used. In those cases (well certainly in BGPs) there are mechanisms to prevent looping that are added to the protocol - it just doesn't happen, you have to do something to prevent it. If your point is that you could build a non algorithmic network then I concede your point. If your point is that you can have a non-algorithmic solution in a network that is already heavily algorithmically based, then I guess I would probably need some further discussion with you.

> 
> > this is to
> > prevent black holing among other things.
> 
> This is the job of routing protocols, not individual routers.

I think we would have a semantic debate if I responded to this, so let's not.

> 
> > So for example, the SPF
> > algorithm is not a secret,
> 
> Actually, the SPF *algorithm* can be a secret.  The result (a shortest
> path dag) is not a secret.  It can be (and has been) proven that if
> each router computes a spdag based on the same topology info, then no
> black holes arise.

Don't understand how the same topology would lead to the same result if there was not some common assumptions about how to get there. I understand at the implementation level you might want to do incremental stuff or do something innovative at the coding level, but not sure if that means that Dijkstra's isn't still the fundamental essence of what you are doing (in the case of OSPF or IS-IS). If you can point me to some reading on the use of different algorithms to achieve the same result I would appreciate it.

> 
> > As ECMP algorithms impact the forwarding
> > direction of packets, then I would suggest while not on the same level
> > of criticality as SPF, there is a similar logic that could be applied to
> > this case.
> 
> Different ECMP algorithms have happily co-existed in networks for a
> long time now.  The algorithms can be different, but there must be a
> consisten result; in this case, packets in a 'flow', whatever that is,
> must not be reordered.
> 
> There are both IP and MPLS networks with multi-vendor equipment with
> ECMP and they work just fine.

That is a good data point, thanks. Was there any interaction between the respective engineering teams to get it working?

> > In addition, having worked at a vendor trying to work out the best way
> > to do ECMP
> 
> Whole 'nuther ball game.  Very very hard question.  If I had an
> answer, I sure wouldn't share it :-)

Answer assumed ;-) You've worked with some of them so be careful now ;-)

Additionally, if it is true that at some time in history Juniper and Cisco chose a different hash, then it might not be as obvious as your playful comment suggests. Also at the time there was no existence of a PID. Since the existence of a PID has since been argued to be useful......

> > So bottom line is I would have to agree that two routers from different
> > vendors can not communicate in the same network using ECMP unless the
> > algorithm is known by both.
> 
> See above.
> 
> This is easy to see if you consider that an ECMP path is a set of
> choices in the data plane that *could* correctly have been made
> instead in the control plane; and that the set of choices is stable
> for a given packet flow.

You know there is nothing in this paragraph that I disagree which makes me wonder what the discussion is about. I obviously was missing an understanding on how to achieve "..the set of choices is stable for a given packet flow". I am not sure if it is a standard yet, but at least I understand the fundamentals better.


From owner-mpls@UU.NET  Mon Nov 17 21:44: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 VAA19359
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 21:44:09 -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 QQppha19101
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 02:44: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 QQppha18866;
	Tue, 18 Nov 2003 02:44:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppgz01487
	for mpls-outgoing; Tue, 18 Nov 2003 02:27: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 QQppgz01480
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 02:27:58 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 QQppgz12490
	for <mpls@UU.NET>; Tue, 18 Nov 2003 02:27: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 QQppgz28972
	for <mpls@UU.NET>; Tue, 18 Nov 2003 02:27:22 GMT
Received: from colo-dns-ext1.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: colo-dns-ext1.juniper.net [207.17.137.57])
	id QQppgz28963
	for <mpls@UU.NET>; Tue, 18 Nov 2003 02:27:21 GMT
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id hAI2RKl44271;
	Mon, 17 Nov 2003 18:27:20 -0800 (PST)
	(envelope-from yakov@juniper.net)
Received: from juniper.net (garnet.juniper.net [172.17.28.17])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id hAI2RFt52024;
	Mon, 17 Nov 2003 18:27:15 -0800 (PST)
	(envelope-from yakov@juniper.net)
Message-Id: <200311180227.hAI2RFt52024@merlot.juniper.net>
To: mark seery <mark@interflect.com>
cc: Kireeti Kompella <kireeti@juniper.net>, mpls@UU.NET
Subject: Re: On ECMP 
In-Reply-To: Your message of "Mon, 17 Nov 2003 19:43:12 EST."
             <200311180043.TAA03664@hank.bcentralhost.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <47728.1069122435.1@juniper.net>
Date: Mon, 17 Nov 2003 18:27:15 -0800
From: Yakov Rekhter <yakov@juniper.net>
Sender: owner-mpls@UU.NET
Precedence: bulk

Mark,

> > On Mon, 17 Nov 2003, mark seery wrote:
> > 
> > > One of the fundamental precepts of routing, is that each node
> > > understands the routing decisions each other node makes,
> > 
> > I don't agree.  For a simple example: in RIP, a router has no idea
> > what the next hop will do.  Another (before y'all jump on me for
> > saying that RIP is a routing protocol) is BGP.  Link state protocols
> > are different -- in a sense, they give you too much information.
> 
> Oh yeah, thanks for reminding me of the conistency of topology knowledge in 
> those other protocols ;-) (clearly a case of sarcasm).
> 
> Seriously, if I am wrong that OSPF and IS-IS assume every router
> in an area are using the same algorithm, then would appreciate
> being corrected. 

As Kireeti mentioned before, both OSPF and ISIS assume that each
router computes shortest path (wrt OSPF/ISIS metric) from itself
to all other nodes in the network. Neither OSPF nor ISIS require a
*specific* single source all destinations shortest path algorithm to
be used for such computation.  There is *more than one* algorithm
to compute single source all destinations shortest path (see below
for the list of books that describe some of these algorithms).

> That path and distance vector algorithms advertise
> routes and select best routes based on policy etc. is different
> than the case when a common algorithm is being used. In those cases
> (well certainly in BGPs) there are mechanisms to prevent looping
> that are added to the protocol - it just doesn't happen, you have
> to do something to prevent it. If your point is that you could
> build a non algorithmic network then I concede your point. If your
> point is that you can have a non-algorithmic solution in a network
> that is already heavily algorithmically based, then I guess I would
> probably need some further discussion with you.

I think Kireeti's point is that assuming that there is one and only
one single source all destinations shortest path algorithm doesn't
match current reality.

> > > this is to prevent black holing among other things.
> > 
> > This is the job of routing protocols, not individual routers.
> 
> I think we would have a semantic debate if I responded to this, so let's not.
> 
> > 
> > > So for example, the SPF algorithm is not a secret,
> > 
> > Actually, the SPF *algorithm* can be a secret.  The result (a shortest
> > path dag) is not a secret.  It can be (and has been) proven that if
> > each router computes a spdag based on the same topology info, then no
> > black holes arise.
> 
> Don't understand how the same topology would lead to the same result
> if there was not some common assumptions about how to get there. I
> understand at the implementation level you might want to do
> incremental stuff or do something innovative at the coding level,
> but not sure if that means that Dijkstra's isn't still the fundamental
> essence of what you are doing (in the case of OSPF or IS-IS).
> If you can point me to some reading on the use of different algorithms to 
> achieve the same result I would appreciate it.

Here are few books that describe various shortest path algorithms 
(with Dijksta being one of them):

  1. "Network Flows" by Ahuja, Magnanti, Orlin.
  2. "Graphs and Algorithms" by Gondran and Minoux
  3. "Linear Network Optimization" by Bertsekas.

Yakov.


From owner-mpls@UU.NET  Mon Nov 17 22:00: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 WAA20241
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 22:00: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 QQpphc18602
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 03:00: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 QQpphc18398;
	Tue, 18 Nov 2003 03:00:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppha02576
	for mpls-outgoing; Tue, 18 Nov 2003 02:37:26 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 QQppha02571
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 02: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 QQppha16609
	for <mpls@UU.NET>; Tue, 18 Nov 2003 02:36: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 QQppha07156
	for <mpls@UU.NET>; Tue, 18 Nov 2003 02:36:09 GMT
Received: from hank.bcentralhost.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hank.bcentralhost.com [205.158.155.16])
	id QQppha07113
	for <mpls@UU.NET>; Tue, 18 Nov 2003 02:36:08 GMT
Received: (root@localhost)
	by hank.bcentralhost.com
	id VAA11342; Mon, 17 Nov 2003 21:36:00 -0500 (EST)
	[ConcentricHost SMTP Relay 1.14]
Message-ID: <200311180236.VAA11342@hank.bcentralhost.com>
From: mark seery <mark@interflect.com>
To: Yakov Rekhter <yakov@juniper.net>
Subject: Re: On ECMP
Cc: <mpls@UU.NET>
Date: Mon, 17 Nov 2003 21:35:59 -0500 (EST)
In-Reply-To: <200311180227.hAI2RFt52024@merlot.juniper.net> from Yakov Rekhter <yakov@juniper.net> on Mon, 17 Nov 2003 18:27:15 -0800
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



---- Yakov Rekhter <yakov@juniper.net> wrote:
> Here are few books that describe various shortest path algorithms 
> (with Dijksta being one of them):
> 
>   1. "Network Flows" by Ahuja, Magnanti, Orlin.
>   2. "Graphs and Algorithms" by Gondran and Minoux
>   3. "Linear Network Optimization" by Bertsekas.
> 
> Yakov.

Yakov, thanks for the reading material and the other corrections you made to my comments. I am hopeful one of these books will discuss using two different algorithms in the same network (though I understand the essence of Curtis's point that as long as you are moving the ball forward you have done your job).

Mark


From owner-mpls@UU.NET  Mon Nov 17 22:36:36 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 WAA21038
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 22:36: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 QQpphe21167
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 03:36: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 QQpphe20742;
	Tue, 18 Nov 2003 03:36:33 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpphc24878
	for mpls-outgoing; Tue, 18 Nov 2003 03:13: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 QQpphc24852
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 03:13:46 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 QQpphc24196
	for <mpls@uu.net>; Tue, 18 Nov 2003 03:13: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 QQpphc17618
	for <mpls@uu.net>; Tue, 18 Nov 2003 03:13:08 GMT
Received: from web20708.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web20708.mail.yahoo.com [216.136.226.181])
	id QQpphc17599
	for <mpls@uu.net>; Tue, 18 Nov 2003 03:13:07 GMT
Message-ID: <20031118031307.81894.qmail@web20708.mail.yahoo.com>
Received: from [134.193.128.109] by web20708.mail.yahoo.com via HTTP; Mon, 17 Nov 2003 19:13:07 PST
Date: Mon, 17 Nov 2003 19:13:07 -0800 (PST)
From: Melvin Sam <mplswg@yahoo.com>
Subject: About the P2MP scalability
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-302273176-1069125187=:80443"
Sender: owner-mpls@UU.NET
Precedence: bulk

--0-302273176-1069125187=:80443
Content-Type: text/plain; charset=us-ascii

Sir, I have several questions to ask: 
1) how can we implement the P2MP in the non-packet network?
2) can we have some method to solve the scalability problem in P2MP implementation?
3) Can we not to put the PE1 from the sender node in the edge-node, but in the inner node in the mpls domain? I think it could enhance the scalability. Although I know we always put these functions on the edge node.
 
  Hope your reply. 



---------------------------------
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
--0-302273176-1069125187=:80443
Content-Type: text/html; charset=us-ascii

<DIV>
<DIV>Sir,&nbsp;I have&nbsp;several questions to ask: </DIV>
<DIV>1) how can we implement the P2MP in the non-packet network?</DIV>
<DIV>2)&nbsp;can we have some method to solve the scalability problem in P2MP implementation?</DIV>
<DIV>3) Can we not to put the PE1 from the sender node&nbsp;in the edge-node, but in the inner node in the mpls domain? I think it could enhance the scalability. Although I know we always put these functions on the edge node.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp; Hope your reply.&nbsp;</DIV></DIV><p><hr SIZE=1>
Do you Yahoo!?<br>
<a href="http://antispam.yahoo.com/whatsnewfree">Protect your identity with Yahoo! Mail AddressGuard</a>
--0-302273176-1069125187=:80443--


From owner-mpls@UU.NET  Mon Nov 17 22:48: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 WAA21292
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 22:48: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 QQpphf23123
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 03:49: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 QQpphf22881;
	Tue, 18 Nov 2003 03:48:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpphd26324
	for mpls-outgoing; Tue, 18 Nov 2003 03:26: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 QQpphd26317
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 03:26: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 QQpphd20772
	for <mpls@UU.NET>; Tue, 18 Nov 2003 03:25: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 QQpphd03706
	for <mpls@UU.NET>; Tue, 18 Nov 2003 03:25:09 GMT
Received: from kummer.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint2.juniper.net [207.17.136.150])
	id QQpphd03681
	for <mpls@UU.NET>; Tue, 18 Nov 2003 03:25:08 GMT
Received: from kummer.juniper.net (localhost [127.0.0.1])
	by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id hAI3P7da068264;
	Mon, 17 Nov 2003 19:25:07 -0800 (PST)
	(envelope-from kireeti@juniper.net)
Received: from localhost (kireeti@localhost)
	by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id hAI3P7pp068261;
	Mon, 17 Nov 2003 19:25:07 -0800 (PST)
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
Date: Mon, 17 Nov 2003 19:25:07 -0800 (PST)
From: Kireeti Kompella <kireeti@juniper.net>
To: mark seery <mark@interflect.com>
cc: mpls@UU.NET
Subject: Re: On ECMP
In-Reply-To: <200311180043.TAA03664@hank.bcentralhost.com>
Message-ID: <20031117185026.S67554@kummer.juniper.net>
References: <200311180043.TAA03664@hank.bcentralhost.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Mon, 17 Nov 2003, mark seery wrote:

Hi Mark,

> > I don't agree.  For a simple example: in RIP, a router has no idea
> > what the next hop will do.  Another (before y'all jump on me for
> > saying that RIP is a routing protocol) is BGP.  Link state protocols
> > are different -- in a sense, they give you too much information.
>
> Oh yeah, thanks for reminding me of the conistency of topology knowledge in those other protocols ;-) (clearly a case of sarcasm).

No sarcasm intended.  There have been proposals for less than full
topology exchange that still achieve consistent routing.

> Seriously, if I am wrong that OSPF and IS-IS assume every router in
> an area are using the same algorithm, then would appreciate being
> corrected.

Vendor 1 uses vanilla Dijkstra, vendor 2 uses incremental SPF.  Very
different algorithms.

One thing you may want to spend some cycles on: router A computes
shortest paths *from A to all others*.  Router B computes shortest
paths *from B to all others*.  Router B doesn't compute what A will do
with B's packets.  Why should this not result in routing loops?

Hint: see Curtis's mail about decreasing metrics.

> > > As ECMP algorithms impact the forwarding
> > > direction of packets, then I would suggest while not on the same level
> > > of criticality as SPF, there is a similar logic that could be applied to
> > > this case.
> >
> > Different ECMP algorithms have happily co-existed in networks for a
> > long time now.  The algorithms can be different, but there must be a
> > consisten result; in this case, packets in a 'flow', whatever that is,
> > must not be reordered.
> >
> > There are both IP and MPLS networks with multi-vendor equipment with
> > ECMP and they work just fine.
>
> That is a good data point, thanks. Was there any interaction between the respective engineering teams to get it working?

None.

> Additionally, if it is true that at some time in history Juniper
> and Cisco chose a different hash, then it might not be as obvious as
> your playful comment suggests. Also at the time there was no
> existence of a PID. Since the existence of a PID has since been
> argued to be useful......

I don't know anything whatsoever about cisco's hash, and don't have
the least interest (from a 'will routing break?' point-of-view).  I am
willing to bet that J and C (and A) have very different hash
functions.  It Just Doesn't Matter (tm).

> > This is easy to see if you consider that an ECMP path is a set of
> > choices in the data plane that *could* correctly have been made
> > instead in the control plane; and that the set of choices is stable
> > for a given packet flow.
>
> You know there is nothing in this paragraph that I disagree which
> makes me wonder what the discussion is about. I obviously was
> missing an understanding on how to achieve "..the set of choices is
> stable for a given packet flow". I am not sure if it is a standard
> yet, but at least I understand the fundamentals better.

"Stable" means that a given router doesn't change either its hash
algorithm or the fields it's hashing on.  This is very different from
saying that all routers must use the same hash algorithm or hash fields.

Kireeti.
-------


From owner-mpls@UU.NET  Mon Nov 17 23:36:13 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 XAA22245
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 23:36: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 QQpphi23934
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 04:36: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 QQpphi23596;
	Tue, 18 Nov 2003 04:36:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpphg19206
	for mpls-outgoing; Tue, 18 Nov 2003 04:14: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 QQpphg19192
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 04:14: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 QQpphg19310
	for <mpls@UU.NET>; Tue, 18 Nov 2003 04:12:52 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 QQpphg22523
	for <mpls@UU.NET>; Tue, 18 Nov 2003 04:12:52 GMT
Received: from hank.bcentralhost.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hank.bcentralhost.com [205.158.155.16])
	id QQpphg22506
	for <mpls@UU.NET>; Tue, 18 Nov 2003 04:12:51 GMT
Received: (root@localhost)
	by hank.bcentralhost.com
	id XAA11121; Mon, 17 Nov 2003 23:12:48 -0500 (EST)
	[ConcentricHost SMTP Relay 1.14]
Message-ID: <200311180412.XAA11121@hank.bcentralhost.com>
From: mark seery <mark@interflect.com>
To: Kireeti Kompella <kireeti@juniper.net>
Subject: Re: On ECMP
Cc: <mpls@UU.NET>
Date: Mon, 17 Nov 2003 23:12:47 -0500 (EST)
In-Reply-To: <200311180043.TAA03664@hank.bcentralhost.com> from Kireeti Kompella <kireeti@juniper.net> on Mon, 17 Nov 2003 19:25:07 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Kireeti,

---- Kireeti Kompella <kireeti@juniper.net> wrote:
> > Oh yeah, thanks for reminding me of the conistency of topology knowledge in those other protocols ;-) (clearly a case of sarcasm).
> 
> No sarcasm intended.  There have been proposals for less than full
> topology exchange that still achieve consistent routing.

Without seeing the proposals I can only assume that if a router has a known set of possibilities for getting to a known point, it doesn't need to know all the junk after that - just that it is headed in the right direction. But a bit of a meaningless discussion unless I know to what you refer.

Do I trust you have given this some thought and study, and are a more advanced student on this subject that I, yes - clearly. 

> > Seriously, if I am wrong that OSPF and IS-IS assume every router in
> > an area are using the same algorithm, then would appreciate being
> > corrected.
> 
> Vendor 1 uses vanilla Dijkstra, vendor 2 uses incremental SPF.  Very
> different algorithms.

But do they both have the same definition of what a shortest path is? Which is really the point I was trying to make at the beginning of this. We can argue about what an algorithm is (of course we can assert there is only one definition which wouldn't be entirely out of character for this group) or we can argue about whether some some common basis of defining a shortest path is understood. We know routing loops occur when two different routers have a different understanding of the topology. I guess the question I am asking is if two different algorithms have a different concept about what shortest path means, does that not mean in essence they have a different view of the topology?
 
> One thing you may want to spend some cycles on: router A computes
> shortest paths *from A to all others*.  Router B computes shortest
> paths *from B to all others*.  Router B doesn't compute what A will do
> with B's packets.  Why should this not result in routing loops?
> 
> Hint: see Curtis's mail about decreasing metrics

I am not sure I understand the premise. Router B is in a sense suggesting to itself that it knows what some other router (ahead of it in the path) will do. Isn't that an inference of understanding the shortest path?

But I will hunt down Curtis's email and give it some more thought. Thanks for the brain teaser.

> snipped <
> I don't know anything whatsoever about cisco's hash, and don't have
> the least interest (from a 'will routing break?' point-of-view).  I am
> willing to bet that J and C (and A) have very different hash
> functions.  It Just Doesn't Matter (tm).

If this is true, then why has the use of a PID been suggested to bring in to play at least some commonality. Now it has been suggested to me offline that some of my comments are really only relevant in a highly multi-protocol world, and that world does not exist in the real world. If this is one of the causes of the disconnect, I understand where people are coming from.

> "Stable" means that a given router doesn't change either its hash
> algorithm or the fields it's hashing on.  This is very different from
> saying that all routers must use the same hash algorithm or hash fields.

So I agree there is difference. But just like if two algorithms have a different definition of shortest path my brain says that is a problem, my brain says (yes I am hearing voices at this point) if a network has multiple definitions of what a microflow is, then that is a problem. If you are all say you are doing ECMP with Ethernet, IP, CES and alike and it is not causing you any problems (without a PID), then there is nothing more to be said. Proof of something working is obviously more powerful than theory (that old running code thing I guess).

Mark


From owner-mpls@UU.NET  Mon Nov 17 23:41:07 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 XAA22323
	for <mpls-archive@lists.ietf.org>; Mon, 17 Nov 2003 23:41:07 -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 QQpphi01206
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 04:41:19 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 QQpphi01056;
	Tue, 18 Nov 2003 04:41:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpphh19884
	for mpls-outgoing; Tue, 18 Nov 2003 04:19:54 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 QQpphh19877
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 04:19:44 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 QQpphh08944
	for <mpls@uu.net>; Tue, 18 Nov 2003 04:17: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 QQpphh27572
	for <mpls@uu.net>; Tue, 18 Nov 2003 04:16:57 GMT
Received: from web20706.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web20706.mail.yahoo.com [216.136.226.179])
	id QQpphh27555
	for <mpls@uu.net>; Tue, 18 Nov 2003 04:16:56 GMT
Message-ID: <20031118041656.16407.qmail@web20706.mail.yahoo.com>
Received: from [134.193.128.109] by web20706.mail.yahoo.com via HTTP; Mon, 17 Nov 2003 20:16:56 PST
Date: Mon, 17 Nov 2003 20:16:56 -0800 (PST)
From: Melvin Sam <mplswg@yahoo.com>
Subject: about the scalability of P2MP
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-751605524-1069129016=:16125"
Sender: owner-mpls@UU.NET
Precedence: bulk

--0-751605524-1069129016=:16125
Content-Type: text/plain; charset=us-ascii


    In the P2MP process, we put the information such as 1) Spe Address  2) Tunnel ID 3) P2MP ID into the IP v4 & v6 header, so it means we could handle the packets flexiblely. 

    In most of the subnet technologies, we always put the edge-node as the functional node. I know it is good for 1) easy management 2) less intricacy. But it still has disadvantages: 1) it is not good at scalability 2) the network status is dynamic, even it is a subnet. In the subnet, if we only define the basic operation, that will be fine. But if we want to enlarge the subnet and enrich the functions, so we have limitations.

    For example, in this P2MP case, if do not define the function at the edge node, but 1) separate the only function node into several ones, 2) put the new function nodes into the MPLS domain, it will be good at 1) Scalability. So we can define the function node at where we want. 2) Save the resource. We can depart the original one packet copy at the nearest fore node,e.g., originally : R1—PE1—R2—R3—PE2—R4, if we R1—R2--PE1—R3—PE2—R4, then we could save the  

                R2---R5---PE3---R6                                    R5---PE3---R6 

bandwidth at R2.  3) As we could define the function node in the domain, we also could enhance the ability to supervise and enlarge the network functions. I always feel that the subnet core part is fragile. 4) Reduce the workload in the edge node.   



---------------------------------
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
--0-751605524-1069129016=:16125
Content-Type: text/html; charset=us-ascii

<DIV><PRE style="TEXT-ALIGN: justify"><FONT face="Arial Unicode MS"><SPAN style="COLOR: black"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>In the <A href="mailto:P@MPprocess">P2MP process</A>, we put the information such as 1) </SPAN>Spe Address<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>2) Tunnel ID 3) P2MP ID into the IP v4 &amp; v6 header, so it means we could handle the packets flexiblely. </FONT></PRE><PRE style="TEXT-ALIGN: justify"><FONT face="Arial Unicode MS"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>In most of the subnet technologies, we always put the edge-node as the functional node. I know it is good for 1) easy management 2) less intricacy. But it still has disadvantages: 1) it is not good at scalability 2) the network status is dynamic, even it is a subnet. In the subnet, if we only define the basic operation, that will be fine. But if we want to enlarge the subnet and enrich the functions, so we have limitations.</FONT></P!
 RE><PRE
 style="TEXT-ALIGN: justify"><?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" /><v:line id=_x0000_s1027 style="Z-INDEX: 2; LEFT: 0px; POSITION: absolute; TEXT-ALIGN: left; mso-position-horizontal: absolute; mso-position-vertical: absolute" to="234pt,91.05pt" coordsize="21600,21600" from="3in,82.05pt"><FONT face="Arial Unicode MS"></FONT></v:line><v:line id=_x0000_s1026 style="Z-INDEX: 1; LEFT: 0px; POSITION: absolute; TEXT-ALIGN: left; mso-position-horizontal: absolute; mso-position-vertical: absolute" to="45pt,91.05pt" coordsize="21600,21600" from="27pt,82.05pt"><FONT face="Arial Unicode MS"></FONT></v:line><FONT face="Arial Unicode MS"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>For example, in this P2MP case, if do not define the function at the edge node, but 1) separate the only function node into several ones, 2) put the new function nodes into the MPLS domain, it will be good at 1) Scalability. So we can define the function node at where w!
 e want.
 2) Save the resource. We can depart the original one packet copy at the nearest fore node,e.g., originally : R1—PE1—R2—R3—PE2—R4, if we R1—R2--PE1—R3—PE2—R4, then we could save the <SPAN style="mso-spacerun: yes">&nbsp;</SPAN></FONT></PRE><PRE style="TEXT-ALIGN: justify; tab-stops: 45.8pt center 3.0in left 229.0pt"><FONT face="Arial Unicode MS"><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN><SPAN style="mso-spacerun: yes">&nbsp;</SPAN>R2---R5---PE3---R6 <SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN><SPAN style="mso-spacerun: yes">&nbsp;</SPAN><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>R5---PE3---R6 <SPAN style="COLOR: black"><?xml:namespace prefix = o ns =
 "urn:schemas-microsoft-com:office:office" /><o:p></o:p></SPAN></FONT></PRE><PRE style="LINE-HEIGHT: 15pt; TEXT-ALIGN: justify"><SPAN style="COLOR: black"><FONT face="Arial Unicode MS">bandwidth at R2.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN>3) As we could define the function node in the domain, we also could enhance the ability to supervise and enlarge the network functions. I always feel that the subnet core part is fragile. 4) Reduce the workload in the edge node. <SPAN style="mso-spacerun: yes">&nbsp;</SPAN><SPAN style="mso-spacerun: yes">&nbsp;</SPAN></FONT><o:p></o:p></SPAN></PRE></DIV><p><hr SIZE=1>
Do you Yahoo!?<br>
<a href="http://antispam.yahoo.com/whatsnewfree">Protect your identity with Yahoo! Mail AddressGuard</a>
--0-751605524-1069129016=:16125--


From owner-mpls@UU.NET  Tue Nov 18 00:06: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 AAA22970
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 00:06:55 -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 QQpphk02639
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 05:07: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 QQpphk02445;
	Tue, 18 Nov 2003 05:07:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpphj22517
	for mpls-outgoing; Tue, 18 Nov 2003 04:47:55 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 QQpphj22510
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 04:47:53 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 QQpphj19266
	for <mpls@UU.NET>; Tue, 18 Nov 2003 04:47:26 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 QQpphj23530
	for <mpls@UU.NET>; Tue, 18 Nov 2003 04:47:26 GMT
Received: from prattle.redback.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: prattle.redback.com [155.53.12.9])
	id QQpphj23506
	for <mpls@UU.NET>; Tue, 18 Nov 2003 04:47:25 GMT
Received: from localhost (localhost [127.0.0.1])
	by prattle.redback.com (Postfix) with ESMTP
	id 67D196F138B; Mon, 17 Nov 2003 20:47:24 -0800 (PST)
Received: from prattle.redback.com ([127.0.0.1])
 by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 25379-08; Mon, 17 Nov 2003 20:47:24 -0800 (PST)
Received: from redback.com (malt.redback.com [155.53.12.41])
	by prattle.redback.com (Postfix) with ESMTP
	id C0E196F1388; Mon, 17 Nov 2003 20:47:23 -0800 (PST)
Received: from malt (localhost [127.0.0.1])
	by redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) with ESMTP id UAA28641;
	Mon, 17 Nov 2003 20:47:23 -0800 (PST)
Message-Id: <200311180447.UAA28641@redback.com>
To: mark seery <mark@interflect.com>
Cc: Kireeti Kompella <kireeti@juniper.net>, mpls@UU.NET
Subject: Re: On ECMP 
In-reply-to: Mail from mark seery <mark@interflect.com> 
 dated Mon, 17 Nov 2003 23:12:47 EST
 <200311180412.XAA11121@hank.bcentralhost.com> 
Date: Mon, 17 Nov 2003 20:47:23 -0800
From: Naiming Shen <naiming@redback.com>
X-Virus-Scanned: by amavisd-new at redback.com
Sender: owner-mpls@UU.NET
Precedence: bulk


ECMP does not affect the result of SPF for IGP. Actually in some of the
IGP implementation, a router only announce a single adjacency in LSA even
though there are multiple ECMP adjacencies exist to the same neighbor.
This completely relies on the fact that ECMP info is only relevant to
local router. The ECMP info is needed only in TE application, where
bandwidth of each link is involved and remote router's CSPF needs to know.

cheers.

 ]Hi Kireeti,
 ]
 ]---- Kireeti Kompella <kireeti@juniper.net> wrote:
 ]> > Oh yeah, thanks for reminding me of the conistency of topology knowledge 
in those other protocols ;-) (clearly a case of sarcasm).
 ]> 
 ]> No sarcasm intended.  There have been proposals for less than full
 ]> topology exchange that still achieve consistent routing.
 ]
 ]Without seeing the proposals I can only assume that if a router has a known s
et of possibilities for getting to a known point, it doesn't need to know all t
he junk after that - just that it is headed in the right direction. But a bit o
f a meaningless discussion unless I know to what you refer.
 ]
 ]Do I trust you have given this some thought and study, and are a more advance
d student on this subject that I, yes - clearly. 
 ]
 ]> > Seriously, if I am wrong that OSPF and IS-IS assume every router in
 ]> > an area are using the same algorithm, then would appreciate being
 ]> > corrected.
 ]> 
 ]> Vendor 1 uses vanilla Dijkstra, vendor 2 uses incremental SPF.  Very
 ]> different algorithms.
 ]
 ]But do they both have the same definition of what a shortest path is? Which i
s really the point I was trying to make at the beginning of this. We can argue 
about what an algorithm is (of course we can assert there is only one definitio
n which wouldn't be entirely out of character for this group) or we can argue a
bout whether some some common basis of defining a shortest path is understood. 
We know routing loops occur when two different routers have a different underst
anding of the topology. I guess the question I am asking is if two different al
gorithms have a different concept about what shortest path means, does that not
 mean in essence they have a different view of the topology?
 ] 
 ]> One thing you may want to spend some cycles on: router A computes
 ]> shortest paths *from A to all others*.  Router B computes shortest
 ]> paths *from B to all others*.  Router B doesn't compute what A will do
 ]> with B's packets.  Why should this not result in routing loops?
 ]> 
 ]> Hint: see Curtis's mail about decreasing metrics
 ]
 ]I am not sure I understand the premise. Router B is in a sense suggesting to 
itself that it knows what some other router (ahead of it in the path) will do. 
Isn't that an inference of understanding the shortest path?
 ]
 ]But I will hunt down Curtis's email and give it some more thought. Thanks for
 the brain teaser.
 ]
 ]> snipped <
 ]> I don't know anything whatsoever about cisco's hash, and don't have
 ]> the least interest (from a 'will routing break?' point-of-view).  I am
 ]> willing to bet that J and C (and A) have very different hash
 ]> functions.  It Just Doesn't Matter (tm).
 ]
 ]If this is true, then why has the use of a PID been suggested to bring in to 
play at least some commonality. Now it has been suggested to me offline that so
me of my comments are really only relevant in a highly multi-protocol world, an
d that world does not exist in the real world. If this is one of the causes of 
the disconnect, I understand where people are coming from.
 ]
 ]> "Stable" means that a given router doesn't change either its hash
 ]> algorithm or the fields it's hashing on.  This is very different from
 ]> saying that all routers must use the same hash algorithm or hash fields.
 ]
 ]So I agree there is difference. But just like if two algorithms have a differ
ent definition of shortest path my brain says that is a problem, my brain says 
(yes I am hearing voices at this point) if a network has multiple definitions o
f what a microflow is, then that is a problem. If you are all say you are doing
 ECMP with Ethernet, IP, CES and alike and it is not causing you any problems (
without a PID), then there is nothing more to be said. Proof of something worki
ng is obviously more powerful than theory (that old running code thing I guess)
.
 ]
 ]Mark

- Naiming


From owner-mpls@UU.NET  Tue Nov 18 00:24: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 AAA23270
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 00:24: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 QQpphl13689
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 05:24: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 QQpphl13401;
	Tue, 18 Nov 2003 05:24:46 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpphk12707
	for mpls-outgoing; Tue, 18 Nov 2003 05:07:54 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 QQpphk12684
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 05:07:48 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 QQpphk14613
	for <mpls@UU.NET>; Tue, 18 Nov 2003 05:06: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 QQpphk18709
	for <mpls@UU.NET>; Tue, 18 Nov 2003 05:06:31 GMT
Received: from hank.bcentralhost.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hank.bcentralhost.com [205.158.155.16])
	id QQpphk18682
	for <mpls@UU.NET>; Tue, 18 Nov 2003 05:06:30 GMT
Received: (root@localhost)
	by hank.bcentralhost.com
	id AAA05085; Tue, 18 Nov 2003 00:06:26 -0500 (EST)
	[ConcentricHost SMTP Relay 1.14]
Message-ID: <200311180506.AAA05085@hank.bcentralhost.com>
From: mark seery <mark@interflect.com>
To: Naiming Shen <naiming@redback.com>
Subject: Re: On ECMP
Cc: <mpls@UU.NET>
Date: Tue, 18 Nov 2003 00:06:26 -0500 (EST)
In-Reply-To: <200311180447.UAA28641@redback.com> from Naiming Shen <naiming@redback.com> on Mon, 17 Nov 2003 20:47:23 -0800
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



---- Naiming Shen <naiming@redback.com> wrote:
> 
> ECMP does not affect the result of SPF for IGP. Actually in some of the
> IGP implementation, a router only announce a single adjacency in LSA even
> though there are multiple ECMP adjacencies exist to the same neighbor.
> This completely relies on the fact that ECMP info is only relevant to
> local router. The ECMP info is needed only in TE application, where
> bandwidth of each link is involved and remote router's CSPF needs to know.
> 
> cheers.
> 

Hi Naiming. Thanks for the info about ECMP and TE, that is interesting, and it is in the context of a single network using both LDP and TE that those voices in my head start getting louder ;-)

As for a router that has multiple links to the same neighbor, that is not the kind of topological construct I am thinking of when I discuss ECMP, though understand why you mention it.

Thanks again.


From owner-mpls@UU.NET  Tue Nov 18 01:04:04 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 BAA24114
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 01:04: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 QQppho04749
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 06:04: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 QQppho04391;
	Tue, 18 Nov 2003 06:04:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpphn17063
	for mpls-outgoing; Tue, 18 Nov 2003 05:48:29 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 QQpphn17058
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 05:48:27 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 QQpphn07214
	for <mpls@uu.net>; Tue, 18 Nov 2003 05:48: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 QQpphn27937
	for <mpls@uu.net>; Tue, 18 Nov 2003 05:48:09 GMT
Received: from sj-iport-5.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-5.cisco.com [171.68.10.87])
	id QQpphn27926
	for <mpls@uu.net>; Tue, 18 Nov 2003 05:48:09 GMT
Received: from cisco.com (171.71.177.237)
  by sj-iport-5.cisco.com with ESMTP; 17 Nov 2003 21:48:09 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAI5m2At013474
	for <mpls@uu.net>; Mon, 17 Nov 2003 21:48:02 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEB25594;
	Tue, 18 Nov 2003 00:48:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAI5m1Z11278 for mpls@uu.net; Tue, 18 Nov 2003 00:48: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 QQpphn16978
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 05:46: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 QQpphm01537
	for <mpls@UU.NET>; Tue, 18 Nov 2003 05:43: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 QQpphm22357
	for <mpls@UU.NET>; Tue, 18 Nov 2003 05:43:31 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 QQpphm22337
	for <mpls@UU.NET>; Tue, 18 Nov 2003 05:43:30 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hAI5i2L7004927;
	Tue, 18 Nov 2003 00:44:02 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311180544.hAI5i2L7004927@workhorse.fictitious.org>
To: mark seery <mark@interflect.com>
cc: Kireeti Kompella <kireeti@juniper.net>, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: On ECMP 
In-reply-to: Your message of "Mon, 17 Nov 2003 23:12:47 EST."
             <200311180412.XAA11121@hank.bcentralhost.com> 
Date: Tue, 18 Nov 2003 00:44:02 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <200311180412.XAA11121@hank.bcentralhost.com>, mark seery writes:
> 
> > I don't know anything whatsoever about cisco's hash, and don't have
> > the least interest (from a 'will routing break?' point-of-view).  I am
> > willing to bet that J and C (and A) have very different hash
> > functions.  It Just Doesn't Matter (tm).
> 
> If this is true, then why has the use of a PID been suggested to bring in to 
> play at least some commonality. Now it has been suggested to me offline that 
> some of my comments are really only relevant in a highly multi-protocol world
> , and that world does not exist in the real world. If this is one of the caus
> es of the disconnect, I understand where people are coming from.


Strictly speaking, a microflow is a stream of data which cannot be
reordered (without some sort of bad things happenning).  For IP a
microflow can be identified by source and destination address and TCP
(or UDP) port numbers for TCP and UDP.

If a hash is performed on an IP source and destination address
(src/dst addr), and the path selected from a set of N choices using
modulo N (simple and common technique) then each path will have a set
of microflows, generally a very large set.  Any one microflow will
take only one path and therefore packets for that microflow will not
be reordered.

If you don't know that traffic is IP, then it is not generally safe to
try to split it up.  An LSP carrying the data stream for a single
leased line cannot be load split because reordering the packets would
have dire consequences.  When this type of LSP and some IP LSPs are
put inside another LSP (hierarchical LSPs) then there are two labels
in the label stack.  In this case, it is not possible for a midpoint
to tell by looking at the labels which packets are IP and which are
not.  Load split can be done on the inner label alone (the outer label
is constant) but the quality of the load split is generally
unsatisfactory.

It is desireable to be able to load split the IP traffic based on the
IP src/dst.  If the ISP knows that any non-IP traffic will never have
what looks like an IP header in the first four bytes, the ISP can
enable ECMP in which the first four bytes are examined to see if the
packet is IP, and labels are used for the split if not, and the IP
src/dst is used for the split if it is IP.  If the vast majority of
the traffic is IP, then this yields a high quality load split.

The PW PID just provides a means to insure that for PW the above
condition is true (it insures that no non-IP traffic will have the
first four bytes that look like an IP header).  That is the only link
between PW and this discussion.

I made some comment in private email to Mark about multiprotocol.  A
lot of ISP/carriers have in their MPLS traffic IP, usually VOIP (also
IP), maybe IP VPN (also IP), and maybe FR, ATM, and TDM.  ECMP is
guarenteed to not scramble microflows if the FR, ATM, and TDM go
inside PW with PW PID (or otherwise acquire a 4 byte shim that doesn't
look like an IP header in the first four bytes or first one byte which
always contains the version number, 4 or 6).  For multiprotocol in the
real world (of wide area networking) this is about it.  OSI, X.25,
ISDN, Novell, Appletalk, Netbios, SNA, DECNET, etc, just plain don't
exist in the core.  Yes, I did mention OSI in that list, but if an ISP
needs OSI for some dribble of control packets for some archane reason
(or any of the others), then they can enscapsulate it in IP to keep
its packet ordering intact in the presence of ECMP.

Curtis



From owner-mpls@UU.NET  Tue Nov 18 01:19: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 BAA24404
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 01:19: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 QQpphp12192
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 06:19: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 QQpphp12030;
	Tue, 18 Nov 2003 06:19:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppho28889
	for mpls-outgoing; Tue, 18 Nov 2003 06:02: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 QQppho28879
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 06:02: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 QQppho07430
	for <mpls@UU.NET>; Tue, 18 Nov 2003 06:02: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 QQppho17743
	for <mpls@UU.NET>; Tue, 18 Nov 2003 06:02:29 GMT
Received: from hank.bcentralhost.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hank.bcentralhost.com [205.158.155.16])
	id QQppho17726
	for <mpls@UU.NET>; Tue, 18 Nov 2003 06:02:28 GMT
Received: (root@localhost)
	by hank.bcentralhost.com
	id BAA20459; Tue, 18 Nov 2003 01:02:18 -0500 (EST)
	[ConcentricHost SMTP Relay 1.14]
Message-ID: <200311180602.BAA20459@hank.bcentralhost.com>
From: mark seery <mark@interflect.com>
To: <curtis@fictitious.org>
Subject: Re: On ECMP
Cc: <mpls@UU.NET>
Date: Tue, 18 Nov 2003 01:02:18 -0500 (EST)
In-Reply-To: <200311180544.hAI5i2L7004927@workhorse.fictitious.org> from Curtis Villamizar <curtis@workhorse.fictitious.org> on Tue, 18 Nov 2003 00:44:02 -0500
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



---- Curtis Villamizar <curtis@workhorse.fictitious.org> wrote:
> Strictly speaking, a microflow is a stream of data which cannot be
> reordered (without some sort of bad things happenning).  For IP a
> microflow can be identified by source and destination address and TCP
> (or UDP) port numbers for TCP and UDP.
> <snipped to end>

Thanks Curtis, I appreciate you taking the time to explain it, especially if you have had to before.

Mark



From owner-mpls@UU.NET  Tue Nov 18 03:24: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 DAA09968
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 03:24: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 QQpphx16028
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 08:24: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 QQpphx15861;
	Tue, 18 Nov 2003 08:24:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpphw25683
	for mpls-outgoing; Tue, 18 Nov 2003 08:08: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 QQpphw25678
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 08:08:48 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 QQpphw04730
	for <mpls@UU.NET>; Tue, 18 Nov 2003 08:06:33 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 QQpphw29377
	for <mpls@UU.NET>; Tue, 18 Nov 2003 08:06:32 GMT
Received: from zcars04f.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57])
	id QQpphw29369
	for <mpls@UU.NET>; Tue, 18 Nov 2003 08:06:32 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAI86HJ09608;
	Tue, 18 Nov 2003 03:06:17 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <W3H898YW>; Tue, 18 Nov 2003 03:06:17 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D02B927EB@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'Rahul Aggarwal'" <rahul@juniper.net>
Cc: "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Subject: RE: documenting ECMP - was on the mpls oam framework 
Date: Tue, 18 Nov 2003 03:06:12 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-mpls@UU.NET
Precedence: bulk


Rahul:

You are missing the point, if we do not know how ECMP is implemented, we
cannot critique the solutions or participate in the design. IMHO properly
characterizing the dataplane is a pre-requisite to being able to design
maintenance procedures. For example VCCV proposes using the router alert
label as an alternative to the PW-CW **because** after much teasing out, the
proposing vendor's ECMP implementation only hashes bottom label and payload
and the RA label would be above the bottom label. Is that true of other
vendors???? Is this solution acceptable only because everyone else would
have to use the CW...(so there is an escape clause)?

IMHO the variations in ECMP that would be encountered by OAM are of
practical interest to both protocol design and independent of generating a
framework document. It is not an issue with the architecture, it is a
pre-requisite to working on it.

cheers
Dave

> -----Original Message-----
> From: Rahul Aggarwal [mailto:rahul@juniper.net] 
> Sent: Monday, November 17, 2003 2:51 PM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: 'tnadeau@cisco.com'; mpls@UU.NET
> Subject: RE: on the mpls oam framework 
> 
> 
> 
> Hi Dave,
> 
> >
> > BTW, would be nice to get some other opinions, IMHO this is rather 
> > fundamental....
> >
> 
> To reiterate what has already been said on this thread. A 
> MPLS OAM framework document must a) Follow the MPLS 
> architecture and b) Discuss an OAM framework that concerns 
> *practical* problems seen in MPLS deployments.
> 
> If folks have issues with MPLS architecture/usage, it should 
> be documented elsewhere, not in the OAM framework document.
> 
> Regards,
> rahul
> 
> 
> > cheers
> > Dave
> >
> >
> 


From owner-mpls@UU.NET  Tue Nov 18 03:39: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 DAA10281
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 03:39:05 -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 QQpphy09175
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 08:39: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 QQpphy08836;
	Tue, 18 Nov 2003 08:39:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpphx27277
	for mpls-outgoing; Tue, 18 Nov 2003 08:17: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 QQpphx27266
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 08:16:58 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 QQpphw11108
	for <mpls@UU.NET>; Tue, 18 Nov 2003 08:11: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 QQpphw26131
	for <mpls@UU.NET>; Tue, 18 Nov 2003 08:11:22 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 QQpphw26122
	for <mpls@UU.NET>; Tue, 18 Nov 2003 08:11:21 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAI8Amp27911;
	Tue, 18 Nov 2003 03:10:48 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <W3H898Y6>; Tue, 18 Nov 2003 03:10:48 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D02B927EC@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>
Cc: "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Subject: RE: on the mpls oam framework 
Date: Tue, 18 Nov 2003 03:10:37 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-mpls@UU.NET
Precedence: bulk

Curtis:

> MPLS Ping has a means defined to determine that an ECMP 
> branch point exists, and a means to provide the means to 
> exercise each branch. This is all independent of the 
> algorithm used to accomplished the split, hash based or 
> other.  That is a move forward technically.  The alternate of 
> randomly spraying addresses across the 127/8 space has also 
> been suggested as a solution that from a practical standpoint 
> covers the problem, though with no certainty.
> 
> This is a solved problem.  

Your characterization of the solution is somewhat like the dancing bear in
the Moscow circus. The wonder is that it dances at all.....

The binary characterization of "a solution", "no solution" IMHO is
insufficient and as I've noted in the comment to Rahul on VCCV, there are
other implications beyond simply the ability to test IP path permutations.

cheers
Dave


From owner-mpls@UU.NET  Tue Nov 18 05:06: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 FAA12550
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 05:06:05 -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 QQppie18693
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 10:06: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 QQppie18373;
	Tue, 18 Nov 2003 10:06:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppid24409
	for mpls-outgoing; Tue, 18 Nov 2003 09:51: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 QQppid24404
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 09:51: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 QQppid20740
	for <mpls@uu.net>; Tue, 18 Nov 2003 09:51: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 QQppid01738
	for <mpls@uu.net>; Tue, 18 Nov 2003 09:51:14 GMT
Received: from sj-iport-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71])
	id QQppid01715
	for <mpls@uu.net>; Tue, 18 Nov 2003 09:51:14 GMT
Received: from cisco.com (171.71.177.254)
  by sj-iport-2.cisco.com with ESMTP; 18 Nov 2003 01:54:43 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAI9p7w5012922
	for <mpls@uu.net>; Tue, 18 Nov 2003 01:51:08 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEB31169;
	Tue, 18 Nov 2003 04:50:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAI9o1216973 for mpls@uu.net; Tue, 18 Nov 2003 04:50: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 QQppid24179
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 09:48:57 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 QQppid14267
	for <mpls@UU.NET>; Tue, 18 Nov 2003 09:48: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 QQppid28127
	for <mpls@UU.NET>; Tue, 18 Nov 2003 09:48:04 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 QQppid28094
	for <mpls@UU.NET>; Tue, 18 Nov 2003 09:48:04 GMT
Received: (qmail 24886 invoked by uid 12059); 18 Nov 2003 09:48:03 -0000
Received: from Shahram_Davari@pmc-sierra.com by father by uid 101 with qmail-scanner-1.20rc3 
 (uvscan: v4.1.40/v4304.  Clear:RC:1:. 
 Processed in 0.798814 secs); 18 Nov 2003 09:48:03 -0000
Received: from unknown (HELO ogmios.pmc-sierra.bc.ca) (216.241.226.59)
  by father.pmc-sierra.com with SMTP; 18 Nov 2003 09:48:02 -0000
Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by ogmios.pmc-sierra.bc.ca (8.12.9/8.12.7) with ESMTP id hAI9m14x003095;
	Tue, 18 Nov 2003 01:48:01 -0800
Received: by bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59)
	id <TFVJCKG1>; Tue, 18 Nov 2003 01:48:01 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115CD03@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Subject: RE: on the mpls oam framework 
Date: Tue, 18 Nov 2003 01:48:00 -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

>	While I would of course agree that knowing all of the
>algorithms would make things easier, I disagree that we cannot
>move forward with solutions today. I think that solutions can be 
>created to manage what is deployed today. There is clear evidence
>of this already.
>
>	--Tom

How can one create solutions to manage deployed boxes, without knowing how
they behave? for example how can you design the VCCV if you don't know 
which fields in the header are used today to hash ECMP. As an example
the Alert Label (in VCCV) won't work with implementations that hash all label stack.


-Shahram



From owner-mpls@UU.NET  Tue Nov 18 05:06: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 FAA12566
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 05:06: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 QQppie18918
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 10:06: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 QQppie18707;
	Tue, 18 Nov 2003 10:06:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppid24451
	for mpls-outgoing; Tue, 18 Nov 2003 09:52:08 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 QQppid24446
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 09:52: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 QQppid09323
	for <mpls@UU.NET>; Tue, 18 Nov 2003 09:51: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 QQppid04751
	for <mpls@UU.NET>; Tue, 18 Nov 2003 09:51:06 GMT
Received: from cbibipnt05.hc.bt.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: saturn.bt.com [193.113.57.20])
	id QQppid04730
	for <mpls@UU.NET>; Tue, 18 Nov 2003 09:51:05 GMT
Received: from cbibipnt05.hc.bt.com ([147.149.196.177]) by cbibipnt05.hc.bt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id W7HXXZQB; Tue, 18 Nov 2003 09:51:08 -0000
Received: From celiborn.ip-engineering.bt.com ([132.146.100.200]) by cbibipnt05.hc.bt.com (WebShield SMTP v4.5 MR1a);
	id 1069149066871; Tue, 18 Nov 2003 09:51:06 +0000
Received: from celiborn.galadriel.bt.co.uk ([132.146.100.200] helo=ip-engineering.bt.com)
	by celiborn.ip-engineering.bt.com with esmtp (Exim 4.04)
	id 1AM2Vd-00023L-00; Tue, 18 Nov 2003 09:50:57 +0000
X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #11[UCI]
To: Rahul Aggarwal <rahul@juniper.net>
cc: David Allan <dallan@nortelnetworks.com>,
        "'tnadeau@cisco.com'" <tnadeau@cisco.com>, "" <mpls@UU.NET>
Subject: Re: on the mpls oam framework 
In-reply-to: Your message of "Mon, 17 Nov 2003 11:51:22 PST."
             <20031117113917.K3860@sapphire.juniper.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 18 Nov 2003 09:50:57 +0000
From: Peter Willis <pjw@ip-engineering.bt.com>
Message-Id: <E1AM2Vd-00023L-00@celiborn.ip-engineering.bt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

If we don't document OAM issues with MPLS in the OAM framework document where 
do they get documented? 

I think the precedent for discussing Issues with MPLS in MPLS WG framework
 documents is established in RFC3353.

Regards the "*practical*" point I can see why the MPLS WG has problems with 
the top down nature of draft-allan-mpls-oam-frmwk-05.txt. Perhaps the usual 
modus operandi of documenting implementations and waiting for customers to
request features to fix operational problems works much better?

Peter.

> 
> Hi Dave,
> 
> >
> > BTW, would be nice to get some other opinions, IMHO this is rather
> > fundamental....
> >
> 
> To reiterate what has already been said on this thread. A MPLS OAM
> framework document must a) Follow the MPLS architecture and b) Discuss
> an OAM framework that concerns *practical* problems seen in MPLS deployments.
> 
> If folks have issues with MPLS architecture/usage, it should be documented
> elsewhere, not in the OAM framework document.
> 
> Regards,
> rahul
> 
> 
> > cheers
> > Dave
> >
> >
> 




From owner-mpls@UU.NET  Tue Nov 18 08:14: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 IAA19811
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 08:14: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 QQppiq21036
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 13:14: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 QQppiq20604;
	Tue, 18 Nov 2003 13:14:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppip07462
	for mpls-outgoing; Tue, 18 Nov 2003 12:56: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 QQppip07455
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 12:56: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 QQppip13076
	for <mpls@uu.net>; Tue, 18 Nov 2003 12:55: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 QQppip24700
	for <mpls@uu.net>; Tue, 18 Nov 2003 12:55:46 GMT
Received: from sj-iport-4.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-4.cisco.com [171.68.10.86])
	id QQppip24686
	for <mpls@uu.net>; Tue, 18 Nov 2003 12:55:45 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAICtfxg028960
	for <mpls@uu.net>; Tue, 18 Nov 2003 07:55:41 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEB36325;
	Tue, 18 Nov 2003 07:55:40 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAICtel22015 for mpls@uu.net; Tue, 18 Nov 2003 07:55: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 QQppip07192
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 12:54: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 QQppip02965
	for <mpls@uu.net>; Tue, 18 Nov 2003 12:54: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 QQppip06895
	for <mpls@uu.net>; Tue, 18 Nov 2003 12:54:11 GMT
Received: from sj-iport-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70])
	id QQppip06877
	for <mpls@uu.net>; Tue, 18 Nov 2003 12:54:10 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAICs7w5008429;
	Tue, 18 Nov 2003 04:54:07 -0800 (PST)
Received: from tnadeauw2k02 (che-vpn-cluster-2-40.cisco.com [10.86.242.40])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEB36273;
	Tue, 18 Nov 2003 07:54:06 -0500 (EST)
Reply-To: <tnadeau@cisco.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
To: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>, <mpls@UU.NET>
Subject: RE: on the mpls oam framework 
Date: Tue, 18 Nov 2003 07:53:57 -0500
Organization: Cisco Systems, inc.
Message-ID: <00fc01c3add3$0b11da90$6701a8c0@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: <4B6D09F3B826D411A67300D0B706EFDE0115CD03@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



>-----Original Message-----
>From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] 
>Sent: Tuesday, November 18, 2003 4:48 AM
>To: 'tnadeau@cisco.com'; mpls@UU.NET
>Subject: RE: on the mpls oam framework 
>
>
>>	While I would of course agree that knowing all of the
>>algorithms would make things easier, I disagree that we cannot
>>move forward with solutions today. I think that solutions can be 
>>created to manage what is deployed today. There is clear evidence
>>of this already.
>>
>>	--Tom
>
>How can one create solutions to manage deployed boxes, without 
>knowing how they behave? for example how can you design the VCCV if you
don't know 
>which fields in the header are used today to hash ECMP. As an example
>the Alert Label (in VCCV) won't work with implementations that 
>hash all label stack.

	Using the example of LSP Ping, you ask the boxes 
what they are going to do. In the case of VCCV,
we don't care because we aren't tracing, just following
whatever path the data takes.

	--Tom





From owner-mpls@UU.NET  Tue Nov 18 08:21: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 IAA19919
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 08:21: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 QQppir14284
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 13:21: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 QQppir14024;
	Tue, 18 Nov 2003 13:21:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppiq18736
	for mpls-outgoing; Tue, 18 Nov 2003 13: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 QQppiq18720
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 13:03: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 QQppiq16463
	for <mpls@uu.net>; Tue, 18 Nov 2003 13:02: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 QQppiq16894
	for <mpls@uu.net>; Tue, 18 Nov 2003 13:02:31 GMT
Received: from sj-iport-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71])
	id QQppiq16879
	for <mpls@uu.net>; Tue, 18 Nov 2003 13:02:31 GMT
Received: from cisco.com (171.71.177.237)
  by sj-iport-2.cisco.com with ESMTP; 18 Nov 2003 05:06:05 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAID2QAt020231
	for <mpls@uu.net>; Tue, 18 Nov 2003 05:02:27 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEB36625;
	Tue, 18 Nov 2003 08:01:18 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAID1Ij22226 for mpls@uu.net; Tue, 18 Nov 2003 08:01:18 -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 QQppip07609
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 12:59: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 QQppip13867
	for <mpls@uu.net>; Tue, 18 Nov 2003 12:58: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 QQppip12314
	for <mpls@uu.net>; Tue, 18 Nov 2003 12:58:47 GMT
Received: from sj-iport-5.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-5.cisco.com [171.68.10.87])
	id QQppip12298
	for <mpls@uu.net>; Tue, 18 Nov 2003 12:58:47 GMT
Received: from cisco.com (171.68.223.137)
  by sj-iport-5.cisco.com with ESMTP; 18 Nov 2003 04:58:58 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hAICwhrX006230;
	Tue, 18 Nov 2003 04:58:44 -0800 (PST)
Received: from tnadeauw2k02 (che-vpn-cluster-2-40.cisco.com [10.86.242.40])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEB36471;
	Tue, 18 Nov 2003 07:58:42 -0500 (EST)
Reply-To: <tnadeau@cisco.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
To: "'Peter Willis'" <pjw@ip-engineering.bt.com>,
        "'Rahul Aggarwal'" <rahul@juniper.net>
Cc: "'David Allan'" <dallan@nortelnetworks.com>, <mpls@UU.NET>
Subject: RE: on the mpls oam framework 
Date: Tue, 18 Nov 2003 07:58:31 -0500
Organization: Cisco Systems, inc.
Message-ID: <00fd01c3add3$afa867e0$6701a8c0@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: <E1AM2Vd-00023L-00@celiborn.ip-engineering.bt.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


>If we don't document OAM issues with MPLS in the OAM framework 
>document where do they get documented? 

	Peter,

	No one is arguing that you should not have your
say in documenting your issues with MPLS. It has been
suggested numerous times now that this be put into
an informational draft.  

	--Tom

	
>I think the precedent for discussing Issues with MPLS in MPLS 
>WG framework documents is established in RFC3353.
>
>Regards the "*practical*" point I can see why the MPLS WG has 
>problems with 
>the top down nature of draft-allan-mpls-oam-frmwk-05.txt. 
>Perhaps the usual 
>modus operandi of documenting implementations and waiting for 
>customers to
>request features to fix operational problems works much better?
>
>Peter.
>
>> 
>> Hi Dave,
>> 
>> >
>> > BTW, would be nice to get some other opinions, IMHO this is rather
>> > fundamental....
>> >
>> 
>> To reiterate what has already been said on this thread. A MPLS OAM
>> framework document must a) Follow the MPLS architecture and 
>b) Discuss
>> an OAM framework that concerns *practical* problems seen in 
>MPLS deployments.
>> 
>> If folks have issues with MPLS architecture/usage, it should 
>be documented
>> elsewhere, not in the OAM framework document.
>> 
>> Regards,
>> rahul
>> 
>> 
>> > cheers
>> > Dave
>> >
>> >
>> 
>
>
>




From owner-mpls@UU.NET  Tue Nov 18 10:39: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 KAA26368
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 10:39: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 QQppja04873
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 15:40: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 QQppja04606;
	Tue, 18 Nov 2003 15:40:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppiz18244
	for mpls-outgoing; Tue, 18 Nov 2003 15:18: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 QQppiz18230
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 15:18: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 QQppiz29218
	for <mpls@UU.NET>; Tue, 18 Nov 2003 15:16: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 QQppiz22958
	for <mpls@UU.NET>; Tue, 18 Nov 2003 15:16:45 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 QQppiz22951
	for <mpls@UU.NET>; Tue, 18 Nov 2003 15:16:45 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAIFGDp26843;
	Tue, 18 Nov 2003 10:16:13 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <W3H80D2K>; Tue, 18 Nov 2003 10:16:14 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D02B92806@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'tnadeau@cisco.com'" <tnadeau@cisco.com>,
        "'Shahram Davari'"
	 <Shahram_Davari@pmc-sierra.com>, mpls@UU.NET
Subject: RE: documenting ECMP
Date: Tue, 18 Nov 2003 10:16:12 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-mpls@UU.NET
Precedence: bulk


> 	Using the example of LSP Ping, you ask the boxes 
> what they are going to do. In the case of VCCV,
> we don't care because we aren't tracing, just following 
> whatever path the data takes.

Hi Tom:

Being able to innovate in the space of fate sharing of flows so that the
"following whatever path the data takes" actually happens is the fundamental
reason for knowing what implementations do. This is a no-brainer....

Vendors who want interoperable OAM MUST publish the protocol specifics....!

cheers
Dave


From owner-mpls@UU.NET  Tue Nov 18 11: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 LAA27300
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 11: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 QQppjc03567
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 16:01: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 QQppjc03421;
	Tue, 18 Nov 2003 16:01:47 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppja20029
	for mpls-outgoing; Tue, 18 Nov 2003 15:44: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 QQppja20020
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 15:44: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 QQppja23956
	for <mpls@uu.net>; Tue, 18 Nov 2003 15:43:33 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 QQppja04937
	for <mpls@uu.net>; Tue, 18 Nov 2003 15:43:32 GMT
Received: from sj-iport-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71])
	id QQppja04926
	for <mpls@uu.net>; Tue, 18 Nov 2003 15:43:32 GMT
Received: from cisco.com (171.71.177.254)
  by sj-iport-2.cisco.com with ESMTP; 18 Nov 2003 07:47:07 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAIFhTw5019111
	for <mpls@uu.net>; Tue, 18 Nov 2003 07:43:29 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEB51079;
	Tue, 18 Nov 2003 10:43:28 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAIFhSG29257 for mpls@uu.net; Tue, 18 Nov 2003 10:43:28 -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 QQppja19951
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 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 QQppja13833
	for <mpls@UU.NET>; Tue, 18 Nov 2003 15:38: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 QQppja22721
	for <mpls@UU.NET>; Tue, 18 Nov 2003 15:38: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 QQppja22683
	for <mpls@UU.NET>; Tue, 18 Nov 2003 15:38:54 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hAIFccL7006212;
	Tue, 18 Nov 2003 10:38:38 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311181538.hAIFccL7006212@workhorse.fictitious.org>
To: "David Allan" <dallan@nortelnetworks.com>
cc: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: on the mpls oam framework 
In-reply-to: Your message of "Tue, 18 Nov 2003 03:10:37 EST."
             <FFFC48AEAA5F7447929F4F0D93FCC12D02B927EC@zcard031.ca.nortel.com> 
Date: Tue, 18 Nov 2003 10:38:38 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <FFFC48AEAA5F7447929F4F0D93FCC12D02B927EC@zcard031.ca.nortel.com>, "
David Allan" writes:
> Curtis:
> 
> > MPLS Ping has a means defined to determine that an ECMP 
> > branch point exists, and a means to provide the means to 
> > exercise each branch. This is all independent of the 
> > algorithm used to accomplished the split, hash based or 
> > other.  That is a move forward technically.  The alternate of 
> > randomly spraying addresses across the 127/8 space has also 
> > been suggested as a solution that from a practical standpoint 
> > covers the problem, though with no certainty.
> > 
> > This is a solved problem.  
> 
> Your characterization of the solution is somewhat like the dancing bear in
> the Moscow circus. The wonder is that it dances at all.....
> 
> The binary characterization of "a solution", "no solution" IMHO is
> insufficient and as I've noted in the comment to Rahul on VCCV, there are
> other implications beyond simply the ability to test IP path permutations.
> 
> cheers
> Dave


You chopped off my next sentence.  My next two sentences were "Can we
stop moving backwards.  If you can improve on the solution, that would
be welcome too."  But you prefer to remove that statement.

This is the path the IETF is currently taking and if you want to
contribute to it, please help it move forward.  If you don't want any
part of it, don't be an obstructionist.  There was and is no
obstruction to your work in the ITU, just no acceptance of it.

There are many cases in which more than one solution is pursued, OSPF
and ISIS, RSVP/TE and CR-LDP, etc (anyone remember Classic IP-over-ATM
and Conventional IP-over-ATM).  The rule of politeness when this
occurs is you don't ostruct the other work and see which one gets
deployed.  If both solutions have merit with some tradeoffs favoring
one or the other in different circumstances or uses, both will
continue to exist.

Curtis



From owner-mpls@UU.NET  Tue Nov 18 11:24: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 LAA28365
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 11:23: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 QQppjd11441
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 16:24: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 QQppjd10204;
	Tue, 18 Nov 2003 16:23:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppjc03163
	for mpls-outgoing; Tue, 18 Nov 2003 16:03: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 QQppjc02738
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 16:02: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 QQppjc01664
	for <mpls@uu.net>; Tue, 18 Nov 2003 16:02: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 QQppjc06753
	for <mpls@uu.net>; Tue, 18 Nov 2003 16:02:03 GMT
Received: from sj-iport-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71])
	id QQppjc06741
	for <mpls@uu.net>; Tue, 18 Nov 2003 16:02:03 GMT
Received: from cisco.com (171.71.177.254)
  by sj-iport-2.cisco.com with ESMTP; 18 Nov 2003 08:05:39 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAIG1xw5005405
	for <mpls@uu.net>; Tue, 18 Nov 2003 08:01:59 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEB53335;
	Tue, 18 Nov 2003 11:01:58 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAIG1we01147 for mpls@uu.net; Tue, 18 Nov 2003 11:01:58 -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 QQppis00732
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 13:37:03 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 QQppis16131
	for <mpls@UU.NET>; Tue, 18 Nov 2003 13:36: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 QQppis16339
	for <mpls@UU.NET>; Tue, 18 Nov 2003 13:36:45 GMT
Received: from relay0.netfirms.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: m0.netfirms.com [209.171.43.51])
	id QQppis16314
	for <mpls@UU.NET>; Tue, 18 Nov 2003 13:36:45 GMT
Received: (qmail 43190 invoked from network); 18 Nov 2003 13:36:38 -0000
Received: from du-069-1253.access.clara.net (HELO Puppy) (217.158.179.236)
  by 0 with SMTP; 18 Nov 2003 13:36:38 -0000
Message-ID: <056101c3add9$02995ea0$db818182@Puppy>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <mplswg@yahoo.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: About the P2MP scalability
Date: Tue, 18 Nov 2003 13:35:11 -0000
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.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Melvin,

Thanks for both of your emails on this subject.

> Sir, I have several questions to ask:
> 1) how can we implement the P2MP in the non-packet network?
> 2) can we have some method to solve the scalability problem in P2MP
>     implementation?
> 3) Can we not to put the PE1 from the sender node in the edge-node,
>      but in the inner node in the mpls domain? I think it could enhance
>      the scalability. Although I know we always put these functions on
>      the edge node.
>
>  Hope your reply.

It is the intention of draft-yasukawa-mpls-p2mp-requirement-01.txt to make sure that any
p2mp solution developed in the MPLS WG should be applicable to other switching types (i.e.
non-packet).

Scalability is, of course, a significant concern.
draft-yasukawa-mpls-p2mp-requirement-01.txt describes networks where the branch points are
within the network and not at the edges. Scaling issues are mentioned at many points in
the draft.

There are currently two proposed solutions drafts (it is to be hoped that these may
converge on a single solution over time). Both proposed solutions take some pains to
ensure optimal use of network resources. Both solutions currently have some scaling issues
within the control plane, but I'm sure the authors are working to resolve these issues.

Cheers,
Adrian



From owner-mpls@UU.NET  Tue Nov 18 11:34: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 LAA28975
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 11:34: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 QQppje00785
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 16:34: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 QQppje00309;
	Tue, 18 Nov 2003 16:34:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppjc12171
	for mpls-outgoing; Tue, 18 Nov 2003 16:12: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 QQppjc12152
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 16:12:37 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 QQppjc20706
	for <mpls@uu.net>; Tue, 18 Nov 2003 16:11: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 QQppjc12625
	for <mpls@uu.net>; Tue, 18 Nov 2003 16:11:35 GMT
Received: from sj-iport-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71])
	id QQppjc12617
	for <mpls@uu.net>; Tue, 18 Nov 2003 16:11:34 GMT
Received: from cisco.com (171.71.177.254)
  by sj-iport-2.cisco.com with ESMTP; 18 Nov 2003 08:15:09 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAIGBVw5014087
	for <mpls@uu.net>; Tue, 18 Nov 2003 08:11:31 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEB54536;
	Tue, 18 Nov 2003 11:11:30 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAIGBUA02626 for mpls@uu.net; Tue, 18 Nov 2003 11:11: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 QQppjc11492
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 16:10: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 QQppjc24900
	for <mpls@UU.NET>; Tue, 18 Nov 2003 16:09: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 QQppjc15905
	for <mpls@UU.NET>; Tue, 18 Nov 2003 16:09:23 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 QQppjc15825
	for <mpls@UU.NET>; Tue, 18 Nov 2003 16:09:22 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hAIG8nL7006318;
	Tue, 18 Nov 2003 11:08:49 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311181608.hAIG8nL7006318@workhorse.fictitious.org>
To: "David Allan" <dallan@nortelnetworks.com>
cc: "'Rahul Aggarwal'" <rahul@juniper.net>,
        "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: documenting ECMP - was on the mpls oam framework 
In-reply-to: Your message of "Tue, 18 Nov 2003 03:06:12 EST."
             <FFFC48AEAA5F7447929F4F0D93FCC12D02B927EB@zcard031.ca.nortel.com> 
Date: Tue, 18 Nov 2003 11:08:49 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <FFFC48AEAA5F7447929F4F0D93FCC12D02B927EB@zcard031.ca.nortel.com>, "
David Allan" writes:
> 
> Rahul:
> 
> You are missing the point, if we do not know how ECMP is implemented, we
> cannot critique the solutions or participate in the design. IMHO properly
> characterizing the dataplane is a pre-requisite to being able to design
> maintenance procedures. For example VCCV proposes using the router alert
> label as an alternative to the PW-CW **because** after much teasing out, the
> proposing vendor's ECMP implementation only hashes bottom label and payload
> and the RA label would be above the bottom label. Is that true of other
> vendors???? Is this solution acceptable only because everyone else would
> have to use the CW...(so there is an escape clause)?
> 
> IMHO the variations in ECMP that would be encountered by OAM are of
> practical interest to both protocol design and independent of generating a
> framework document. It is not an issue with the architecture, it is a
> pre-requisite to working on it.
> 
> cheers
> Dave


Dave,

We've described all the ECMP methods in use either explicitly in this
email thread or through reference to RFC2991 and RFC2992.  At least
one implementation will split based on the bandwidth configured for an
RSVP/TE LSP rather than an equal split.  Otherwise very few details
have not been discussed.

Some implementations use only labels.  Some implementations look for
an IP header *if configured to do so* and hash the IP src/dst, falling
back to labels if the header is not IP.  Most implementations
(probably all) limit label stack depth before using hashed labels.
Whether the bottom label of the whole stack is hashed will varry.

You are not going to get the actual hash function itself and the
method of seeding it.  You also won't get a list of companies and
which feature is released in what version and which line cards support
what (that would be a competitive analysis that is not needed for this
sort of technical discussion).

What *relevant* detail are you missing?

Curtis



From owner-mpls@UU.NET  Tue Nov 18 11:34: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 LAA29018
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 11: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 QQppje00541
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 16:35: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 QQppje00299;
	Tue, 18 Nov 2003 16:34:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppjc11864
	for mpls-outgoing; Tue, 18 Nov 2003 16:12:03 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 QQppjc11790
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 16:11:57 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 QQppjc28893
	for <mpls@UU.NET>; Tue, 18 Nov 2003 16:10: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 QQppjc18757
	for <mpls@UU.NET>; Tue, 18 Nov 2003 16:10:48 GMT
Received: from smtp4.hy.skanova.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp4.hy.skanova.net [195.67.199.133])
	id QQppjc18737
	for <mpls@UU.NET>; Tue, 18 Nov 2003 16:10:46 GMT
Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45])
	by smtp4.hy.skanova.net (8.12.10/8.12.10) with ESMTP id hAIGAHBZ021643;
	Tue, 18 Nov 2003 17:10:17 +0100 (CET)
Message-ID: <3FBA445C.5000407@pi.se>
Date: Tue, 18 Nov 2003 17:10:04 +0100
From: Loa Andersson <loa@pi.se>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MPLS wg <mpls@UU.NET>
CC: "Thomas D. Nadeau" <tnadeau@cisco.com>,
        "David Allan" <dallan@nortelnetworks.com>,
        George Swallow <swallow@cisco.com>, Alex Zinin <zinin@psg.com>
Subject: co-editors for MPLS OAM framework confirmed
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,

Tom and Dave has agreed to co-edit the MPLS OAM Framework,
according the earlier request from me.
I expect this work to be highly and the debate continued
on the list. I hope to have a draft (outlining contents)
within the next few weeks, I also count on other parties
helping the co-editors with text and comments.

/Loa

-- 

Loa Andersson

mobile +46 739 81 21 64




From owner-mpls@UU.NET  Tue Nov 18 11:39: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 LAA29416
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 11:39: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 QQppje10858
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 16:39: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 QQppje10609;
	Tue, 18 Nov 2003 16:39:18 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppjd12597
	for mpls-outgoing; Tue, 18 Nov 2003 16:15: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 QQppjd12545
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 16:15: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 QQppjc26576
	for <mpls@UU.NET>; Tue, 18 Nov 2003 16:14: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 QQppjc23407
	for <mpls@UU.NET>; Tue, 18 Nov 2003 16:14:11 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 QQppjc23391
	for <mpls@UU.NET>; Tue, 18 Nov 2003 16:14:10 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAIGDMp15492;
	Tue, 18 Nov 2003 11:13:22 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <W3H80FGL>; Tue, 18 Nov 2003 11:13:23 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D02B9280B@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>
Cc: "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Subject: RE: on documenting ECMP (was on the mpls oam framework)
Date: Tue, 18 Nov 2003 11:13:16 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-mpls@UU.NET
Precedence: bulk

Curtis:

From my perspective there is simply OAM.

To date a fundamental obstacle to progressing OAM has been the issue of how
OAM flows are distinguished, esp in the presence of ECMP. When a packet
needs to be IP, when it needs to not alias as IP, restrictions on the use of
reserved labels to distinguish flows and where such labels can appear in the
stack, yadda yadda yadda. This has been an obstacle to discussing the actual
functionality required or any other relative merits as all solutions have
been held up to this problem first without the actual problem to be solved
being documented anywhere.

Taking ECMP off the table as an issue by documenting at a minimum the
protocol aspects so we can get on with the actual functionality required
would IMO be progress. The lack of information has been THE obstruction all
along..... 

cheers
Dave



> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] 
> Sent: Tuesday, November 18, 2003 10:39 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: 'curtis@fictitious.org'; 'tnadeau@cisco.com'; mpls@UU.NET
> Subject: Re: on the mpls oam framework 
> 
> 
> 
> In message 
> <FFFC48AEAA5F7447929F4F0D93FCC12D02B927EC@zcard031.ca.nortel.c
> om>, " David Allan" writes:
> > Curtis:
> > 
> > > MPLS Ping has a means defined to determine that an ECMP
> > > branch point exists, and a means to provide the means to 
> > > exercise each branch. This is all independent of the 
> > > algorithm used to accomplished the split, hash based or 
> > > other.  That is a move forward technically.  The alternate of 
> > > randomly spraying addresses across the 127/8 space has also 
> > > been suggested as a solution that from a practical standpoint 
> > > covers the problem, though with no certainty.
> > > 
> > > This is a solved problem.
> > 
> > Your characterization of the solution is somewhat like the dancing 
> > bear in the Moscow circus. The wonder is that it dances at all.....
> > 
> > The binary characterization of "a solution", "no solution" IMHO is 
> > insufficient and as I've noted in the comment to Rahul on 
> VCCV, there 
> > are other implications beyond simply the ability to test IP path 
> > permutations.
> > 
> > cheers
> > Dave
> 
> 
> You chopped off my next sentence.  My next two sentences were 
> "Can we stop moving backwards.  If you can improve on the 
> solution, that would be welcome too."  But you prefer to 
> remove that statement.
> 
> This is the path the IETF is currently taking and if you want 
> to contribute to it, please help it move forward.  If you 
> don't want any part of it, don't be an obstructionist.  There 
> was and is no obstruction to your work in the ITU, just no 
> acceptance of it.
> 
> There are many cases in which more than one solution is 
> pursued, OSPF and ISIS, RSVP/TE and CR-LDP, etc (anyone 
> remember Classic IP-over-ATM and Conventional IP-over-ATM).  
> The rule of politeness when this occurs is you don't ostruct 
> the other work and see which one gets deployed.  If both 
> solutions have merit with some tradeoffs favoring one or the 
> other in different circumstances or uses, both will continue to exist.
> 
> Curtis
> 


From owner-mpls@UU.NET  Tue Nov 18 11:54: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 LAA00049
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 11:54: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 QQppjf06207
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 16:54: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 QQppjf05918;
	Tue, 18 Nov 2003 16:54:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppje14550
	for mpls-outgoing; Tue, 18 Nov 2003 16:32: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 QQppje14537
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 16:32: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 QQppje20635
	for <mpls@uu.net>; Tue, 18 Nov 2003 16:32: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 QQppje25434
	for <mpls@uu.net>; Tue, 18 Nov 2003 16:32:03 GMT
Received: from sj-iport-5.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-5.cisco.com [171.68.10.87])
	id QQppje25423
	for <mpls@uu.net>; Tue, 18 Nov 2003 16:32:02 GMT
Received: from cisco.com (64.102.124.13)
  by sj-iport-5.cisco.com with ESMTP; 18 Nov 2003 08:32:15 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAIGVtDQ018224
	for <mpls@uu.net>; Tue, 18 Nov 2003 11:31:59 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEB57414;
	Tue, 18 Nov 2003 11:31:54 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAIGVsP06693 for mpls@uu.net; Tue, 18 Nov 2003 11:31: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 QQppjd14194
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 16:29: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 QQppjd28591
	for <mpls@UU.NET>; Tue, 18 Nov 2003 16:29: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 QQppjd20429
	for <mpls@UU.NET>; Tue, 18 Nov 2003 16:29:00 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 QQppjd20393
	for <mpls@UU.NET>; Tue, 18 Nov 2003 16:28:59 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hAIGRUL7006363;
	Tue, 18 Nov 2003 11:27:30 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311181627.hAIGRUL7006363@workhorse.fictitious.org>
To: Peter Willis <pjw@ip-engineering.bt.com>
cc: Rahul Aggarwal <rahul@juniper.net>,
        David Allan <dallan@nortelnetworks.com>,
        "'tnadeau@cisco.com'" <tnadeau@cisco.com>, "" <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: on the mpls oam framework 
In-reply-to: Your message of "Tue, 18 Nov 2003 09:50:57 GMT."
             <E1AM2Vd-00023L-00@celiborn.ip-engineering.bt.com> 
Date: Tue, 18 Nov 2003 11:27:30 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <E1AM2Vd-00023L-00@celiborn.ip-engineering.bt.com>, Peter Willis wri
tes:
> If we don't document OAM issues with MPLS in the OAM framework document where
>  
> do they get documented? 
> 
> I think the precedent for discussing Issues with MPLS in MPLS WG framework
>  documents is established in RFC3353.
> 
> Regards the "*practical*" point I can see why the MPLS WG has problems with 
> the top down nature of draft-allan-mpls-oam-frmwk-05.txt. Perhaps the usual 
> modus operandi of documenting implementations and waiting for customers to
> request features to fix operational problems works much better?
> 
> Peter.


An informational RFC on P2MP has nothing to do with this.  There was
very limited interest in P2MP and no one considered that framework to
be harmful.  If good concrete work comes of it that would be welcome.

If there are aspects of the architecture that impacts some methods of
OAM (and clearly there is), it should be covered.  Neither the method
of OAM should be called deficient, nor the architecture, it just
becomes an applicability issue.

There are some people who see the need for monitoring in networks that
have ECMP and have no intention of removing ECMP.  These are real
networks and therefore this is a real problem.  Some methods of
monitoring will work others won't.  That is an issue of applicability.

Some people (you, Neil, Dave, others) prefer aspects of one approach.
Some people prefer the broader applicability of other approaches.
These are tradeoffs.  If we accept these as tradeoffs, then we can
move forward.  If some people keep insisting that we need a document
that states that the architecture is broken we can make no progress.

Curtis



From owner-mpls@UU.NET  Tue Nov 18 11:57: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 LAA00262
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 11:57: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 QQppjf04106
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 16:58:09 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 QQppjf03705;
	Tue, 18 Nov 2003 16:57:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppje15053
	for mpls-outgoing; Tue, 18 Nov 2003 16:37: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 QQppje15033
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 16:36:55 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 QQppje27269
	for <mpls@UU.NET>; Tue, 18 Nov 2003 16:34:54 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 QQppje01347
	for <mpls@UU.NET>; Tue, 18 Nov 2003 16:34:53 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 QQppje01337
	for <mpls@UU.NET>; Tue, 18 Nov 2003 16:34:53 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAIGYap18977;
	Tue, 18 Nov 2003 11:34:36 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <W3H80F6F>; Tue, 18 Nov 2003 11:34:37 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D02B9280C@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>
Cc: "'Rahul Aggarwal'" <rahul@juniper.net>,
        "'tnadeau@cisco.com'"
	 <tnadeau@cisco.com>, mpls@UU.NET
Subject: RE: documenting ECMP - was on the mpls oam framework 
Date: Tue, 18 Nov 2003 11:34:33 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-mpls@UU.NET
Precedence: bulk

Curtis:

Unfortunately we're overlapping. IMHO what has been discussed is the
snooping and that implementations hash portions of or all of the stack. I'm
primarily interested in seeing the specific protocol permutations pinned
down instead of the blanket assume all permutations exist. In particular
w.r.t the label stack as I am aware of implementations that hash the bottom,
the top and would be very useful to know how much of the middle. 

If people are paranoid about publishing, perhaps feeding the information
through Loa anonymously would be a solution. However in the absence of
information other that what has appeared on the list, I'd consider the MUST
support ECMP requirement difficult to meet and would like to have somthing
to point to. I'd like to be able to know if the solution space has been
fully explored and the requirement has been met.

cheers
Dave

> Dave,
> 
> We've described all the ECMP methods in use either explicitly 
> in this email thread or through reference to RFC2991 and 
> RFC2992.  At least one implementation will split based on the 
> bandwidth configured for an RSVP/TE LSP rather than an equal 
> split.  Otherwise very few details have not been discussed.
> 
> Some implementations use only labels.  Some implementations 
> look for an IP header *if configured to do so* and hash the 
> IP src/dst, falling back to labels if the header is not IP.  
> Most implementations (probably all) limit label stack depth 
> before using hashed labels. Whether the bottom label of the 
> whole stack is hashed will varry.
> 
> You are not going to get the actual hash function itself and 
> the method of seeding it.  You also won't get a list of 
> companies and which feature is released in what version and 
> which line cards support what (that would be a competitive 
> analysis that is not needed for this sort of technical discussion).
> 
> What *relevant* detail are you missing?
> 
> Curtis
> 


From owner-mpls@UU.NET  Tue Nov 18 11:58: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 LAA00297
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 11:58: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 QQppjf08229
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 16:58:34 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 QQppjf07552;
	Tue, 18 Nov 2003 16:58:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppje15124
	for mpls-outgoing; Tue, 18 Nov 2003 16:37: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 QQppje15082
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 16:37:23 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 QQppje08878
	for <mpls@UU.NET>; Tue, 18 Nov 2003 16:34: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 QQppje01156
	for <mpls@UU.NET>; Tue, 18 Nov 2003 16:34:49 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 QQppje01135
	for <mpls@UU.NET>; Tue, 18 Nov 2003 16:34:48 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 LAA21910;
	Tue, 18 Nov 2003 11:34:45 -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 LAA27845;
	Tue, 18 Nov 2003 11:34:46 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <W9W7RYYG>; Tue, 18 Nov 2003 11:34:46 -0500
Message-ID: <39469E08BD83D411A3D900204840EC55FB70F3@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'mark seery'" <mark@interflect.com>
Cc: mpls@UU.NET
Subject: RE: On ECMP
Date: Tue, 18 Nov 2003 11:34:41 -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

Mark,

-> But do they both have the same definition of what a shortest 
-> path is? Which is really the point I was trying to make at 
-> the beginning of this. We can argue about what an algorithm 
-> is (of course we can assert there is only one definition 
-> which wouldn't be entirely out of character for this group) 
-> or we can argue about whether some some common basis of 
-> defining a shortest path is understood. We know routing 
-> loops occur when two different routers have a different 
-> understanding of the topology. I guess the question I am 
-> asking is if two different algorithms have a different 
-> concept about what shortest path means, does that not mean 
-> in essence they have a different view of the topology?

  IP routing protocols *view* of shortest path is not different. 
  For years, Distance Vector, Path Vector, Link-State IP routing
  protocols view of shortest path is same.

  Black-holes and/or cycles in Routing Protocols never result
  from using different algorithms. But, strictly because of 
  topological input mismatch.

  There are some SPF algorithms which are different from
  Dijkstra algorithm which are in use today. Recently, Thorup
  has given hierarchical SPF algo which is linear time :
  O(edges) for undirected non-negative edge weights (which   
  is the case for IP routing protocols).

  What ever algorithm is used, the SSSP using same edge 
  weights in the graph results in same DAG. I mean, Directed
  *Acyclic* Graph. More over, Dijkstra algo works with 
  non-negative edge weights only. So, it always finds a DAG
  (iff the graph is connected).

  Most of the deployed link-state algos use different flavors
  of Diakstra (i.e., using different data structures). But,
  what every flavor of data structure used and/or what ever 
  SSSP algo is used, the result is same as long as the 
  semantics assumed are same.

Venkata.


From owner-mpls@UU.NET  Tue Nov 18 12:13: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 MAA01541
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 12:13: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 QQppjg06730
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 17:13: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 QQppjg06033;
	Tue, 18 Nov 2003 17:13:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppjf16580
	for mpls-outgoing; Tue, 18 Nov 2003 16:47: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 QQppjf16575
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 16:47: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 QQppjf24440
	for <mpls@UU.NET>; Tue, 18 Nov 2003 16: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 QQppjf22200
	for <mpls@UU.NET>; Tue, 18 Nov 2003 16:46:12 GMT
Received: from linus.bcentralhost.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: linus.bcentralhost.com [205.158.154.16])
	id QQppjf22172
	for <mpls@UU.NET>; Tue, 18 Nov 2003 16:46:11 GMT
Received: (root@localhost)
	by linus.bcentralhost.com
	id LAA08205; Tue, 18 Nov 2003 11:46:07 -0500 (EST)
	[ConcentricHost SMTP Relay 1.14]
Message-ID: <200311181646.LAA08205@linus.bcentralhost.com>
From: mark seery <mark@interflect.com>
To: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
Subject: RE: On ECMP
Cc: <mpls@UU.NET>
Date: Tue, 18 Nov 2003 11:46:06 -0500 (EST)
In-Reply-To: <39469E08BD83D411A3D900204840EC55FB70F3@vie-msgusr-01.dc.fore.com> from "Naidu, Venkata" <Venkata.Naidu@Marconi.com> on Tue, 18 Nov 2003 11:34:41 -0500
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



---- "Naidu, Venkata" <Venkata.Naidu@Marconi.com> wrote:
<snip>
>   IP routing protocols *view* of shortest path is not different. 
>   For years, Distance Vector, Path Vector, Link-State IP routing
>   protocols view of shortest path is same.

we are agreed. i clearly erred in using the term "algorithm" as it got the discussion off track and did not convey the essence of what i was trying to communicate.

thanks,
mark


From owner-mpls@UU.NET  Tue Nov 18 12:21: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 MAA02198
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 12:21: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 QQppjh11329
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 17:21: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 QQppjh10925;
	Tue, 18 Nov 2003 17:21:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppjg28590
	for mpls-outgoing; Tue, 18 Nov 2003 17:01: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 QQppjg28572
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 17:01:46 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 QQppjg16863
	for <mpls@uu.net>; Tue, 18 Nov 2003 17:00: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 QQppjg10961
	for <mpls@uu.net>; Tue, 18 Nov 2003 17:00:48 GMT
Received: from sj-iport-4.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-4.cisco.com [171.68.10.86])
	id QQppjg10948
	for <mpls@uu.net>; Tue, 18 Nov 2003 17:00:47 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAIH0ixg025294
	for <mpls@uu.net>; Tue, 18 Nov 2003 12:00:44 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEB60793;
	Tue, 18 Nov 2003 12:00:43 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAIH0hR12266 for mpls@uu.net; Tue, 18 Nov 2003 12:00:43 -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 QQppjf17696
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 16:59: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 QQppjf19364
	for <mpls@UU.NET>; Tue, 18 Nov 2003 16:56: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 QQppjf05644
	for <mpls@UU.NET>; Tue, 18 Nov 2003 16:56:52 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 QQppjf05602
	for <mpls@UU.NET>; Tue, 18 Nov 2003 16:56:51 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hAIGtbL7006596;
	Tue, 18 Nov 2003 11:55:37 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311181655.hAIGtbL7006596@workhorse.fictitious.org>
To: "David Allan" <dallan@nortelnetworks.com>
cc: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: on documenting ECMP (was on the mpls oam framework) 
In-reply-to: Your message of "Tue, 18 Nov 2003 11:13:16 EST."
             <FFFC48AEAA5F7447929F4F0D93FCC12D02B9280B@zcard031.ca.nortel.com> 
Date: Tue, 18 Nov 2003 11:55:37 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <FFFC48AEAA5F7447929F4F0D93FCC12D02B9280B@zcard031.ca.nortel.com>, "
David Allan" writes:
> Curtis:
> 
> >From my perspective there is simply OAM.

Then withdraw as an author of the framework document.  That would be
like Ohta writing the IP over ATM framework (Conventional IP or ATM
advocate).

> To date a fundamental obstacle to progressing OAM has been the issue of how
> OAM flows are distinguished, esp in the presence of ECMP. When a packet
> needs to be IP, when it needs to not alias as IP, restrictions on the use of
> reserved labels to distinguish flows and where such labels can appear in the
> stack, yadda yadda yadda. This has been an obstacle to discussing the actual
> functionality required or any other relative merits as all solutions have
> been held up to this problem first without the actual problem to be solved
> being documented anywhere.
> 
> Taking ECMP off the table as an issue by documenting at a minimum the
> protocol aspects so we can get on with the actual functionality required
> would IMO be progress. The lack of information has been THE obstruction all
> along..... 
> 
> cheers
> Dave

See my prior email.  If OAM doesn't work with ECMP as it exists in the
real world then it is just an applicability issue that needs to be
documented.

Curtis



From owner-mpls@UU.NET  Tue Nov 18 12:23: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 MAA02278
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 12:23: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 QQppjh25918
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 17:23: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 QQppjh25747;
	Tue, 18 Nov 2003 17:23:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppjg28736
	for mpls-outgoing; Tue, 18 Nov 2003 17:02: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 QQppjg28726
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 17:02: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 QQppjg20315
	for <mpls@uu.net>; Tue, 18 Nov 2003 17:02: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 QQppjg09848
	for <mpls@uu.net>; Tue, 18 Nov 2003 17:02:27 GMT
Received: from sj-iport-5.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-5.cisco.com [171.68.10.87])
	id QQppjg09821
	for <mpls@uu.net>; Tue, 18 Nov 2003 17:02:27 GMT
Received: from cisco.com (171.71.177.254)
  by sj-iport-5.cisco.com with ESMTP; 18 Nov 2003 09:02:41 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAIH2Ow5029194
	for <mpls@uu.net>; Tue, 18 Nov 2003 09:02:24 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEB60981;
	Tue, 18 Nov 2003 12:02:23 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAIH2NV12596 for mpls@uu.net; Tue, 18 Nov 2003 12:02:23 -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 QQppjg21435
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 17:00: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 QQppjg28409
	for <mpls@UU.NET>; Tue, 18 Nov 2003 17:00: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 QQppjg10855
	for <mpls@UU.NET>; Tue, 18 Nov 2003 17:00:41 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 QQppjg10846
	for <mpls@UU.NET>; Tue, 18 Nov 2003 17:00:40 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hAIGxRL7006613;
	Tue, 18 Nov 2003 11:59:27 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311181659.hAIGxRL7006613@workhorse.fictitious.org>
To: "David Allan" <dallan@nortelnetworks.com>
cc: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "'Rahul Aggarwal'" <rahul@juniper.net>,
        "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: documenting ECMP - was on the mpls oam framework 
In-reply-to: Your message of "Tue, 18 Nov 2003 11:34:33 EST."
             <FFFC48AEAA5F7447929F4F0D93FCC12D02B9280C@zcard031.ca.nortel.com> 
Date: Tue, 18 Nov 2003 11:59:27 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <FFFC48AEAA5F7447929F4F0D93FCC12D02B9280C@zcard031.ca.nortel.com>, "
David Allan" writes:
> Curtis:
> 
> Unfortunately we're overlapping. IMHO what has been discussed is the
> snooping and that implementations hash portions of or all of the stack. I'm
> primarily interested in seeing the specific protocol permutations pinned
> down instead of the blanket assume all permutations exist. In particular
> w.r.t the label stack as I am aware of implementations that hash the bottom,
> the top and would be very useful to know how much of the middle. 
> 
> If people are paranoid about publishing, perhaps feeding the information
> through Loa anonymously would be a solution. However in the absence of
> information other that what has appeared on the list, I'd consider the MUST
> support ECMP requirement difficult to meet and would like to have somthing
> to point to. I'd like to be able to know if the solution space has been
> fully explored and the requirement has been met.
> 
> cheers
> Dave


Dave,

Even if everyone described their *current* ECMP implementation in
detail, not everyone would like to be constrained forever to a
particular method of ECMP just to satisfy *ITU* OAM.

If ITU OAM can't work in the presence of ECMP without aprior knowledge
of how the ECMP split is accomplished this remains an issue of
applicability.  ITU OAM is not applicable in that case.

Curtis



> > Dave,
> > 
> > We've described all the ECMP methods in use either explicitly 
> > in this email thread or through reference to RFC2991 and 
> > RFC2992.  At least one implementation will split based on the 
> > bandwidth configured for an RSVP/TE LSP rather than an equal 
> > split.  Otherwise very few details have not been discussed.
> > 
> > Some implementations use only labels.  Some implementations 
> > look for an IP header *if configured to do so* and hash the 
> > IP src/dst, falling back to labels if the header is not IP.  
> > Most implementations (probably all) limit label stack depth 
> > before using hashed labels. Whether the bottom label of the 
> > whole stack is hashed will varry.
> > 
> > You are not going to get the actual hash function itself and 
> > the method of seeding it.  You also won't get a list of 
> > companies and which feature is released in what version and 
> > which line cards support what (that would be a competitive 
> > analysis that is not needed for this sort of technical discussion).
> > 
> > What *relevant* detail are you missing?
> > 
> > Curtis
> > 
> 



From owner-mpls@UU.NET  Tue Nov 18 12:24: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 MAA02415
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 12:24: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 QQppjh16841
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 17:24:49 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 QQppjh16522;
	Tue, 18 Nov 2003 17:24:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppjg05255
	for mpls-outgoing; Tue, 18 Nov 2003 17:04: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 QQppjg05184
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 17:04:40 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 QQppjg07272
	for <mpls@UU.NET>; Tue, 18 Nov 2003 17:01: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 QQppjg11661
	for <mpls@UU.NET>; Tue, 18 Nov 2003 17:01:15 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 QQppjg11649
	for <mpls@UU.NET>; Tue, 18 Nov 2003 17:01:14 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAIGxtp00063;
	Tue, 18 Nov 2003 11:59:55 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <W3H80GRJ>; Tue, 18 Nov 2003 11:59:56 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D02B92810@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>
Cc: "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Subject: RE: on documenting ECMP (was on the mpls oam framework) 
Date: Tue, 18 Nov 2003 11:59:48 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-mpls@UU.NET
Precedence: bulk

Curtis:

You misuderstand me, I lump all tools (including LSP-PING, BFD, VCCV, ITU
efforts) together under the blanket of OAM.

enough for now
Dave

> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] 
> Sent: Tuesday, November 18, 2003 11:56 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: 'curtis@fictitious.org'; 'tnadeau@cisco.com'; mpls@UU.NET
> Subject: Re: on documenting ECMP (was on the mpls oam framework) 
> 
> 
> 
> In message 
> <FFFC48AEAA5F7447929F4F0D93FCC12D02B9280B@zcard031.ca.nortel.c
> om>, " David Allan" writes:
> > Curtis:
> > 
> > >From my perspective there is simply OAM.
> 
> Then withdraw as an author of the framework document.  That 
> would be like Ohta writing the IP over ATM framework 
> (Conventional IP or ATM advocate).
> 
> > To date a fundamental obstacle to progressing OAM has been 
> the issue 
> > of how OAM flows are distinguished, esp in the presence of 
> ECMP. When 
> > a packet needs to be IP, when it needs to not alias as IP, 
> > restrictions on the use of reserved labels to distinguish flows and 
> > where such labels can appear in the stack, yadda yadda 
> yadda. This has 
> > been an obstacle to discussing the actual functionality required or 
> > any other relative merits as all solutions have been held 
> up to this 
> > problem first without the actual problem to be solved being 
> documented 
> > anywhere.
> > 
> > Taking ECMP off the table as an issue by documenting at a 
> minimum the 
> > protocol aspects so we can get on with the actual functionality 
> > required would IMO be progress. The lack of information has 
> been THE 
> > obstruction all along.....
> > 
> > cheers
> > Dave
> 
> See my prior email.  If OAM doesn't work with ECMP as it 
> exists in the real world then it is just an applicability 
> issue that needs to be documented.
> 
> Curtis
> 


From owner-mpls@UU.NET  Tue Nov 18 13:04: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 NAA04317
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 13:04: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 QQppjk03081
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 18: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 QQppjk02720;
	Tue, 18 Nov 2003 18:04:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppjj12325
	for mpls-outgoing; Tue, 18 Nov 2003 17:47:03 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 QQppjj12316
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 17:46:51 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 QQppjj14068
	for <mpls@uu.net>; Tue, 18 Nov 2003 17:45: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 QQppjj27813
	for <mpls@uu.net>; Tue, 18 Nov 2003 17:45:11 GMT
Received: from sj-iport-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71])
	id QQppjj27790
	for <mpls@uu.net>; Tue, 18 Nov 2003 17:45:10 GMT
Received: from cisco.com (171.71.177.237)
  by sj-iport-2.cisco.com with ESMTP; 18 Nov 2003 09:48:47 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAIHj7At026908
	for <mpls@uu.net>; Tue, 18 Nov 2003 09:45:08 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEB65812;
	Tue, 18 Nov 2003 12:45:06 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAIHj6P19060 for mpls@uu.net; Tue, 18 Nov 2003 12:45: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 QQppji11658
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 17:43:58 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 QQppji03237
	for <mpls@UU.NET>; Tue, 18 Nov 2003 17:42: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 QQppji24241
	for <mpls@UU.NET>; Tue, 18 Nov 2003 17:42:29 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 QQppji24209
	for <mpls@UU.NET>; Tue, 18 Nov 2003 17:42:28 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hAIHg3L7006741;
	Tue, 18 Nov 2003 12:42:03 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311181742.hAIHg3L7006741@workhorse.fictitious.org>
To: "David Allan" <dallan@nortelnetworks.com>
cc: "'tnadeau@cisco.com'" <tnadeau@cisco.com>,
        "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: documenting ECMP 
In-reply-to: Your message of "Tue, 18 Nov 2003 10:16:12 EST."
             <FFFC48AEAA5F7447929F4F0D93FCC12D02B92806@zcard031.ca.nortel.com> 
Date: Tue, 18 Nov 2003 12:42:03 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <FFFC48AEAA5F7447929F4F0D93FCC12D02B92806@zcard031.ca.nortel.com>, "
David Allan" writes:
> 
> > 	Using the example of LSP Ping, you ask the boxes 
> > what they are going to do. In the case of VCCV,
> > we don't care because we aren't tracing, just following 
> > whatever path the data takes.
> 
> Hi Tom:
> 
> Being able to innovate in the space of fate sharing of flows so that the
> "following whatever path the data takes" actually happens is the fundamental
> reason for knowing what implementations do. This is a no-brainer....
> 
> Vendors who want interoperable OAM MUST publish the protocol specifics....!
> 
> cheers
> Dave

The real world seems to be proving you wrong on that one no matter how
emphaticly you make the assertion.

It may be true that vendors who want ITU OAM must publish the
specifics of their ECMP implementation.  Among the vendors with a
combined 99% of the high end router market this seems to be the null
set so let us move forward now.

Curtis



From owner-mpls@UU.NET  Tue Nov 18 13:11:07 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 NAA04805
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 13:11: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 QQppjk15120
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 18:11: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 QQppjk13741;
	Tue, 18 Nov 2003 18:10:30 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppjj12496
	for mpls-outgoing; Tue, 18 Nov 2003 17:49: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 QQppjj12486
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 17:49:46 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 QQppjj11484
	for <mpls@UU.NET>; Tue, 18 Nov 2003 17:46: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 QQppjj03235
	for <mpls@UU.NET>; Tue, 18 Nov 2003 17:46:28 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 QQppjj03214
	for <mpls@UU.NET>; Tue, 18 Nov 2003 17:46:28 GMT
Received: from cbibipnt08.hc.bt.com ([147.149.100.81]) by cbibipnt08.hc.bt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id W7HZ1NDX; Tue, 18 Nov 2003 17:30:46 -0000
Received: From celiborn.ip-engineering.bt.com ([132.146.100.200]) by cbibipnt08.hc.bt.com (WebShield SMTP v4.5 MR1a);
	id 1069176645725; Tue, 18 Nov 2003 17:30:45 +0000
Received: from celiborn.galadriel.bt.co.uk ([132.146.100.200] helo=ip-engineering.bt.com)
	by celiborn.ip-engineering.bt.com with esmtp (Exim 4.04)
	id 1AM9gJ-0003Cl-00; Tue, 18 Nov 2003 17:30:27 +0000
X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #11[UCI]
To: curtis@fictitious.org
cc: Peter Willis <pjw@ip-engineering.bt.com>,
        Rahul Aggarwal <rahul@juniper.net>,
        David Allan <dallan@nortelnetworks.com>,
        "'tnadeau@cisco.com'" <tnadeau@cisco.com>, "" <mpls@UU.NET>
Subject: Re: on the mpls oam framework 
In-reply-to: Your message of "Tue, 18 Nov 2003 11:27:30 EST."
             <200311181627.hAIGRUL7006363@workhorse.fictitious.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 18 Nov 2003 17:30:27 +0000
From: Peter Willis <pjw@ip-engineering.bt.com>
Message-Id: <E1AM9gJ-0003Cl-00@celiborn.ip-engineering.bt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

> If there are aspects of the architecture that impacts some methods of
> OAM (and clearly there is), it should be covered.  Neither the method
> of OAM should be called deficient, nor the architecture, it just
> becomes an applicability issue.
> 

I'm happy with that approach.

Peter.



From owner-mpls@UU.NET  Tue Nov 18 13:15: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 NAA05088
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 13:15: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 QQppjl23954
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 18:15: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 QQppjl23707;
	Tue, 18 Nov 2003 18:15:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppjj13296
	for mpls-outgoing; Tue, 18 Nov 2003 17:57: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 QQppjj13285
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 17:57: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 QQppjj01752
	for <mpls@uu.net>; Tue, 18 Nov 2003 17:56:15 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 QQppjj15945
	for <mpls@uu.net>; Tue, 18 Nov 2003 17:56:14 GMT
Received: from sj-iport-3.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72])
	id QQppjj15912
	for <mpls@uu.net>; Tue, 18 Nov 2003 17:56:12 GMT
Received: from cisco.com (171.71.177.254)
  by sj-iport-3.cisco.com with ESMTP; 18 Nov 2003 10:04:27 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAIHu9w5023048
	for <mpls@uu.net>; Tue, 18 Nov 2003 09:56:10 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEB66967;
	Tue, 18 Nov 2003 12:56:08 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAIHu8u19909 for mpls@uu.net; Tue, 18 Nov 2003 12:56:08 -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 QQppjj12877
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 17:54: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 QQppjj10402
	for <mpls@UU.NET>; Tue, 18 Nov 2003 17: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 QQppjj12948
	for <mpls@UU.NET>; Tue, 18 Nov 2003 17:53:20 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 QQppjj12917
	for <mpls@UU.NET>; Tue, 18 Nov 2003 17:53:19 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hAIHr2L7006911;
	Tue, 18 Nov 2003 12:53:02 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311181753.hAIHr2L7006911@workhorse.fictitious.org>
To: "David Allan" <dallan@nortelnetworks.com>
cc: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: on documenting ECMP (was on the mpls oam framework) 
In-reply-to: Your message of "Tue, 18 Nov 2003 11:59:48 EST."
             <FFFC48AEAA5F7447929F4F0D93FCC12D02B92810@zcard031.ca.nortel.com> 
Date: Tue, 18 Nov 2003 12:53:02 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <FFFC48AEAA5F7447929F4F0D93FCC12D02B92810@zcard031.ca.nortel.com>, "
David Allan" writes:
> Curtis:
> 
> You misuderstand me, I lump all tools (including LSP-PING, BFD, VCCV, ITU
> efforts) together under the blanket of OAM.
> 
> enough for now
> Dave


Some of these tools *will* work with ECMP without apriori knowledge of
how the split is accomplished.  Therefore you've just negated your
emphatic assertion that "Vendors who want interoperable OAM MUST
publish the protocol specifics....!"

Unless in some situations you lump all of these monitoring tools as
OAM and in other cases are talking about ITU OAM.

I agree that this is enough for now.

Curtis



> 
> > -----Original Message-----
> > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] 
> > Sent: Tuesday, November 18, 2003 11:56 AM
> > To: Allan, David [CAR:NS00:EXCH]
> > Cc: 'curtis@fictitious.org'; 'tnadeau@cisco.com'; mpls@UU.NET
> > Subject: Re: on documenting ECMP (was on the mpls oam framework) 
> > 
> > 
> > 
> > In message 
> > <FFFC48AEAA5F7447929F4F0D93FCC12D02B9280B@zcard031.ca.nortel.c
> > om>, " David Allan" writes:
> > > Curtis:
> > > 
> > > >From my perspective there is simply OAM.
> > 
> > Then withdraw as an author of the framework document.  That 
> > would be like Ohta writing the IP over ATM framework 
> > (Conventional IP or ATM advocate).
> > 
> > > To date a fundamental obstacle to progressing OAM has been 
> > the issue 
> > > of how OAM flows are distinguished, esp in the presence of 
> > ECMP. When 
> > > a packet needs to be IP, when it needs to not alias as IP, 
> > > restrictions on the use of reserved labels to distinguish flows and 
> > > where such labels can appear in the stack, yadda yadda 
> > yadda. This has 
> > > been an obstacle to discussing the actual functionality required or 
> > > any other relative merits as all solutions have been held 
> > up to this 
> > > problem first without the actual problem to be solved being 
> > documented 
> > > anywhere.
> > > 
> > > Taking ECMP off the table as an issue by documenting at a 
> > minimum the 
> > > protocol aspects so we can get on with the actual functionality 
> > > required would IMO be progress. The lack of information has 
> > been THE 
> > > obstruction all along.....
> > > 
> > > cheers
> > > Dave
> > 
> > See my prior email.  If OAM doesn't work with ECMP as it 
> > exists in the real world then it is just an applicability 
> > issue that needs to be documented.
> > 
> > Curtis



From owner-mpls@UU.NET  Tue Nov 18 13:29: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 NAA05835
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 13:29: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 QQppjl18103
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 18: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 QQppjl17979;
	Tue, 18 Nov 2003 18:29:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppjk02681
	for mpls-outgoing; Tue, 18 Nov 2003 18:06: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 QQppjk02648
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 18:06: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 QQppjk08258
	for <mpls@uu.net>; Tue, 18 Nov 2003 18:06: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 QQppjk01329
	for <mpls@uu.net>; Tue, 18 Nov 2003 18:06:00 GMT
Received: from sj-iport-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70])
	id QQppjk01308
	for <mpls@uu.net>; Tue, 18 Nov 2003 18:05:59 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAII5uAt018793
	for <mpls@uu.net>; Tue, 18 Nov 2003 10:05:57 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEB68244;
	Tue, 18 Nov 2003 13:05:51 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAII5pj21855 for mpls@uu.net; Tue, 18 Nov 2003 13:05:51 -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 QQppjk24644
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 18:03: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 QQppjj07881
	for <mpls@UU.NET>; Tue, 18 Nov 2003 17:58: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 QQppjj20027
	for <mpls@UU.NET>; Tue, 18 Nov 2003 17:58: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 QQppjj20001
	for <mpls@UU.NET>; Tue, 18 Nov 2003 17:58:51 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hAIHwaL7007025;
	Tue, 18 Nov 2003 12:58:36 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311181758.hAIHwaL7007025@workhorse.fictitious.org>
To: Peter Willis <pjw@ip-engineering.bt.com>
cc: curtis@fictitious.org, Rahul Aggarwal <rahul@juniper.net>,
        David Allan <dallan@nortelnetworks.com>,
        "'tnadeau@cisco.com'" <tnadeau@cisco.com>, "" <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: on the mpls oam framework 
In-reply-to: Your message of "Tue, 18 Nov 2003 17:30:27 GMT."
             <E1AM9gJ-0003Cl-00@celiborn.ip-engineering.bt.com> 
Date: Tue, 18 Nov 2003 12:58:36 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <E1AM9gJ-0003Cl-00@celiborn.ip-engineering.bt.com>, Peter Willis wri
tes:
> > If there are aspects of the architecture that impacts some methods of
> > OAM (and clearly there is), it should be covered.  Neither the method
> > of OAM should be called deficient, nor the architecture, it just
> > becomes an applicability issue.
> > 
> 
> I'm happy with that approach.
> 
> Peter.


Peter,

Finally some compromise.

Thanks,

Curtis



From owner-mpls@UU.NET  Tue Nov 18 13:44: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 NAA06383
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 13:44: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 QQppjm09338
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 18:44: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 QQppjm09193;
	Tue, 18 Nov 2003 18:44:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppjl05390
	for mpls-outgoing; Tue, 18 Nov 2003 18:22: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 QQppjl05379
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 18:22: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 QQppjl14936
	for <mpls@UU.NET>; Tue, 18 Nov 2003 18:22: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 QQppjl05681
	for <mpls@UU.NET>; Tue, 18 Nov 2003 18:21:59 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 QQppjl05667
	for <mpls@UU.NET>; Tue, 18 Nov 2003 18:21:59 GMT
Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35])
	by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAIILuE28435
	for <mpls@UU.NET>; Tue, 18 Nov 2003 12:21:56 -0600 (CST)
Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2656.59)
	id <TPL0B2N8>; Tue, 18 Nov 2003 13:21:55 -0500
Message-ID: <B99995113B318D44BBE87DC50092EDA90C0D5500@nj7460exch006u.ho.lucent.com>
From: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
To: "'David Allan'" <dallan@nortelnetworks.com>,
        "'curtis@fictitious.org'"
	 <curtis@fictitious.org>
Cc: "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Subject: RE: on documenting ECMP (was on the mpls oam framework) 
Date: Tue, 18 Nov 2003 13:21:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Dave, et.al.

In one of the side-branches of this discussion, the name Dijkstra came up a couple of times. Apart from inventing the famous algorithm, Dijkstra did important work in the area of correctness proofs and concurrent processes. One of his insights was that non-determinism is a powerful concept and that a program should be written in such a way that its correctness can be proven, even in the face of non-determinism.

We have to be careful translating this to OAM (after all, you don't want your service provider to blame non-determinism when your connections fail), but let's give it a try.

I think that ECMP is an issue only for a subset of traffic. ECMP is not an issue for PW-traffic, since VCCV provides a solution. ECMP is not an issue for services with QoS guarantees, where RSVP-TE is used to set up the connection, because an explicit path is nailed down. 

The question in my mind is: for the traffic that is subject to ECMP, is it really crucial to know exactly how traffic is routed? Shouldn't we just embrace non-determinism for the advantages that it provides and find ways to work around it?

For example, when I surf the web, I don't need an ISP to be able to send OAM packets along the exact same path that I used five minutes ago. For such applications, end-to-end OAM would not be relevant, but local loopback tests might be much more useful.


Peter 


> -----Original Message-----
> From: David Allan [mailto:dallan@nortelnetworks.com]
> Sent: Tuesday, November 18, 2003 12:00 PM
> To: 'curtis@fictitious.org'
> Cc: 'tnadeau@cisco.com'; mpls@UU.NET
> Subject: RE: on documenting ECMP (was on the mpls oam framework) 
> 
> 
> Curtis:
> 
> You misuderstand me, I lump all tools (including LSP-PING, 
> BFD, VCCV, ITU
> efforts) together under the blanket of OAM.
> 
> enough for now
> Dave
> 
> > -----Original Message-----
> > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] 
> > Sent: Tuesday, November 18, 2003 11:56 AM
> > To: Allan, David [CAR:NS00:EXCH]
> > Cc: 'curtis@fictitious.org'; 'tnadeau@cisco.com'; mpls@UU.NET
> > Subject: Re: on documenting ECMP (was on the mpls oam framework) 
> > 
> > 
> > 
> > In message 
> > <FFFC48AEAA5F7447929F4F0D93FCC12D02B9280B@zcard031.ca.nortel.c
> > om>, " David Allan" writes:
> > > Curtis:
> > > 
> > > >From my perspective there is simply OAM.
> > 
> > Then withdraw as an author of the framework document.  That 
> > would be like Ohta writing the IP over ATM framework 
> > (Conventional IP or ATM advocate).
> > 
> > > To date a fundamental obstacle to progressing OAM has been 
> > the issue 
> > > of how OAM flows are distinguished, esp in the presence of 
> > ECMP. When 
> > > a packet needs to be IP, when it needs to not alias as IP, 
> > > restrictions on the use of reserved labels to distinguish 
> flows and 
> > > where such labels can appear in the stack, yadda yadda 
> > yadda. This has 
> > > been an obstacle to discussing the actual functionality 
> required or 
> > > any other relative merits as all solutions have been held 
> > up to this 
> > > problem first without the actual problem to be solved being 
> > documented 
> > > anywhere.
> > > 
> > > Taking ECMP off the table as an issue by documenting at a 
> > minimum the 
> > > protocol aspects so we can get on with the actual functionality 
> > > required would IMO be progress. The lack of information has 
> > been THE 
> > > obstruction all along.....
> > > 
> > > cheers
> > > Dave
> > 
> > See my prior email.  If OAM doesn't work with ECMP as it 
> > exists in the real world then it is just an applicability 
> > issue that needs to be documented.
> > 
> > Curtis
> > 
> 


From owner-mpls@UU.NET  Tue Nov 18 14:19:16 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 OAA07974
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 14:19: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 QQppjp00794
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 19:19: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 QQppjp00407;
	Tue, 18 Nov 2003 19:19:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppjn08871
	for mpls-outgoing; Tue, 18 Nov 2003 18:58: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 QQppjn08864
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 18:58:15 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 QQppjn24923
	for <mpls@UU.NET>; Tue, 18 Nov 2003 18:57: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 QQppjn19004
	for <mpls@UU.NET>; Tue, 18 Nov 2003 18:57:32 GMT
Received: from colo-dns-ext2.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: colo-dns-ext2.juniper.net [207.17.137.64])
	id QQppjn18986
	for <mpls@UU.NET>; Tue, 18 Nov 2003 18:57:32 GMT
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	by colo-dns-ext2.juniper.net (8.11.5/8.9.3) with ESMTP id hAIIrrF05662;
	Tue, 18 Nov 2003 10:54:03 -0800 (PST)
	(envelope-from rahul@juniper.net)
Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id hAIIrlt13151;
	Tue, 18 Nov 2003 10:53:47 -0800 (PST)
	(envelope-from rahul@juniper.net)
Received: from localhost (rahul@localhost)
	by sapphire.juniper.net (8.11.6/8.11.3) with ESMTP id hAIIrlZ45844;
	Tue, 18 Nov 2003 10:53:47 -0800 (PST)
	(envelope-from rahul@juniper.net)
X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs
Date: Tue, 18 Nov 2003 10:53:47 -0800 (PST)
From: Rahul Aggarwal <rahul@juniper.net>
To: David Allan <dallan@nortelnetworks.com>
cc: "'tnadeau@cisco.com'" <tnadeau@cisco.com>, "" <mpls@UU.NET>
Subject: RE: documenting ECMP - was on the mpls oam framework 
In-Reply-To: <FFFC48AEAA5F7447929F4F0D93FCC12D02B927EB@zcard031.ca.nortel.com>
Message-ID: <20031118103040.U34445@sapphire.juniper.net>
References: <FFFC48AEAA5F7447929F4F0D93FCC12D02B927EB@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, 18 Nov 2003, David Allan wrote:

>
> Rahul:
>
> You are missing the point, if we do not know how ECMP is implemented, we
> cannot critique the solutions or participate in the design.

As has been articulated before on this thread, a MPLS OAM tool should be
able to work in the presence of ECMP, without prior knowledge of the hash
function. Lack of knowledge of the hash function does not preclude one
from designing an OAM solution or critiquing it. If certain tools have
constraints in an ECMP environment, the applicability of those tools
should be documented.

That said, if you really want to satisfy your curiosity and determine the
hash function used by a few major vendors, reverse engineering in the lab
is always possible :)

IMHO properly
> characterizing the dataplane is a pre-requisite to being able to design
> maintenance procedures. For example VCCV proposes using the router alert
> label as an alternative to the PW-CW **because** after much teasing out, the
> proposing vendor's ECMP implementation only hashes bottom label and payload
> and the RA label would be above the bottom label. Is that true of other
> vendors???? Is this solution acceptable only because everyone else would
> have to use the CW...(so there is an escape clause)?
>

The reason for having the router alert label is because a CW may not be
present or some h/w may not be able to support the CW solution. This has
the drawback of potentially breaking in the presence of ECMP and that is an
applicability of the router alert approach. We can clarify this in the
VCCV draft.

rahul

> IMHO the variations in ECMP that would be encountered by OAM are of
> practical interest to both protocol design and independent of generating a
> framework document. It is not an issue with the architecture, it is a
> pre-requisite to working on it.
>


> cheers
> Dave
>
> > -----Original Message-----
> > From: Rahul Aggarwal [mailto:rahul@juniper.net]
> > Sent: Monday, November 17, 2003 2:51 PM
> > To: Allan, David [CAR:NS00:EXCH]
> > Cc: 'tnadeau@cisco.com'; mpls@UU.NET
> > Subject: RE: on the mpls oam framework
> >
> >
> >
> > Hi Dave,
> >
> > >
> > > BTW, would be nice to get some other opinions, IMHO this is rather
> > > fundamental....
> > >
> >
> > To reiterate what has already been said on this thread. A
> > MPLS OAM framework document must a) Follow the MPLS
> > architecture and b) Discuss an OAM framework that concerns
> > *practical* problems seen in MPLS deployments.
> >
> > If folks have issues with MPLS architecture/usage, it should
> > be documented elsewhere, not in the OAM framework document.
> >
> > Regards,
> > rahul
> >
> >
> > > cheers
> > > Dave
> > >
> > >
> >
>


From owner-mpls@UU.NET  Tue Nov 18 14:30: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 OAA08767
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 14:30: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 QQppjq09994
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 19:31: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 QQppjq09815;
	Tue, 18 Nov 2003 19:30:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppjo28441
	for mpls-outgoing; Tue, 18 Nov 2003 19:10:24 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 QQppjo28374
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 19:10:07 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 QQppjo11017
	for <mpls@uu.net>; Tue, 18 Nov 2003 19:09: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 QQppjo06061
	for <mpls@uu.net>; Tue, 18 Nov 2003 19:09:13 GMT
Received: from sj-iport-4.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-4.cisco.com [171.68.10.86])
	id QQppjo06051
	for <mpls@uu.net>; Tue, 18 Nov 2003 19:09:13 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAIJ99DM020500
	for <mpls@uu.net>; Tue, 18 Nov 2003 14:09:10 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEB76110;
	Tue, 18 Nov 2003 14:09:09 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAIJ99t28808 for mpls@uu.net; Tue, 18 Nov 2003 14:09: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 QQppjo28109
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 19:08:03 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 QQppjo05398
	for <mpls@UU.NET>; Tue, 18 Nov 2003 19:07: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 QQppjo06837
	for <mpls@UU.NET>; Tue, 18 Nov 2003 19:07:21 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 QQppjo06817
	for <mpls@UU.NET>; Tue, 18 Nov 2003 19:07:20 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hAIJ2gL7029639;
	Tue, 18 Nov 2003 14:02:42 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311181902.hAIJ2gL7029639@workhorse.fictitious.org>
To: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
cc: "'David Allan'" <dallan@nortelnetworks.com>,
        "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: on documenting ECMP (was on the mpls oam framework) 
In-reply-to: Your message of "Tue, 18 Nov 2003 13:21:46 EST."
             <B99995113B318D44BBE87DC50092EDA90C0D5500@nj7460exch006u.ho.lucent.com> 
Date: Tue, 18 Nov 2003 14:02:42 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <B99995113B318D44BBE87DC50092EDA90C0D5500@nj7460exch006u.ho.lucent.c
om>, "Busschbach, Peter B (Peter)" writes:
> Dave, et.al.
> 
> In one of the side-branches of this discussion, the name Dijkstra came up a c
> ouple of times. Apart from inventing the famous algorithm, Dijkstra did impor
> tant work in the area of correctness proofs and concurrent processes. One of 
> his insights was that non-determinism is a powerful concept and that a progra
> m should be written in such a way that its correctness can be proven, even in
>  the face of non-determinism.
> 
> We have to be careful translating this to OAM (after all, you don't want your
>  service provider to blame non-determinism when your connections fail), but l
> et's give it a try.

Nice thought followed by a cheap shot, but fine.  I understand that
you don't like ECMP and no one is asking you to like it, simply to
accept that it is part of the architecture and it will be covered by
whatever OAM emerges from the IETF.

> I think that ECMP is an issue only for a subset of traffic. ECMP is not an is
> sue for PW-traffic, since VCCV provides a solution. ECMP is not an issue for 
> services with QoS guarantees, where RSVP-TE is used to set up the connection,
>  because an explicit path is nailed down. 

QoS and explicit path are orthogonal.  Some provider may feel that
they must combine the two in their service but it is not generally the
case.  QoS and ECMP are also orthogonal.  Lets not try to sneak in
assertions that may be true in your case but are not generally true.

> The question in my mind is: for the traffic that is subject to ECMP, is it re
> ally crucial to know exactly how traffic is routed? Shouldn't we just embrace
>  non-determinism for the advantages that it provides and find ways to work ar
> ound it?

We did that in MPLS Ping.  The ingress can determine from the midpoint
(essentially by the midpoint telling it) where ECMP branches exists
and how to exercise each branch.  This method is deterministic and
will exercise all paths.  The alternate is to randomly spray across
the 127/8 space, which is non-deterministic but arguably will also
exercise all paths.  The latter method can detect loss but not measure
the loss experienced on any given path (loss may be concentrated in a
subset of the traffic).

If other techniques want to do something similar to determine how to
exercise ECMP paths, then they become applicable where ECMP is used.
If they don't they are simply not applicable when ECMP is used.  One
provider may choose to disable ECMP and use a technique that works
only with ECMP disabled.  Another provider may choose to keep ECMP
enabled and use a different OAM technique that works with ECMP.

> For example, when I surf the web, I don't need an ISP to be able to send OAM 
> packets along the exact same path that I used five minutes ago. For such appl
> ications, end-to-end OAM would not be relevant, but local loopback tests migh
> t be much more useful.

I'm quite confident that the PC in my home has not sent any OAM
packets to the IETF mail servers to verify the path to the mail
server.  But quite honestly this has nothing to do with the discussion
of the OAM framework.  If I want to test to see if my ISP is live or
the path to the IETF mail server is OK, I just use IP ping and
traceroute.  Loopback tests are accomplished for your example.

> Peter 

We had some compromise and I fear that we are now slipping back to
arguing about whether ECMP is part of the architecture.  I hope that
is not the case.

Curtis



From owner-mpls@UU.NET  Tue Nov 18 14:57: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 OAA10103
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 14:57: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 QQppjr16970
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 19:57:58 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 QQppjr16856;
	Tue, 18 Nov 2003 19:57:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppjq01760
	for mpls-outgoing; Tue, 18 Nov 2003 19:37: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 QQppjq01752
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 19:37: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 QQppjq02537
	for <mpls@UU.NET>; Tue, 18 Nov 2003 19:35: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 QQppjq16355
	for <mpls@UU.NET>; Tue, 18 Nov 2003 19:35:24 GMT
Received: from ihemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ihemail2.lucent.com [192.11.222.163])
	id QQppjq16336
	for <mpls@UU.NET>; Tue, 18 Nov 2003 19:35:23 GMT
Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36])
	by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAIJZKE22684
	for <mpls@UU.NET>; Tue, 18 Nov 2003 13:35:20 -0600 (CST)
Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2656.59)
	id <V08BGQF9>; Tue, 18 Nov 2003 14:35:10 -0500
Message-ID: <B99995113B318D44BBE87DC50092EDA90C0D5501@nj7460exch006u.ho.lucent.com>
From: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
Cc: "'David Allan'" <dallan@nortelnetworks.com>,
        "'tnadeau@cisco.com'"
	 <tnadeau@cisco.com>, mpls@UU.NET
Subject: RE: on documenting ECMP (was on the mpls oam framework) 
Date: Tue, 18 Nov 2003 14:35:09 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Curtis,

Something must have been lost in the translation, because you seem to interpret most of my statements opposite to what I intended. I like ECMP. My email was intended as a request to accept ECMP as a given and accept that it leads to non-deterministic behavior in the network.

For fear of further slipping away from the compromise that you referred to, I will leave most of your misinterpretations unanswered, but I do have a question about one of your statements. Please see in-line.

Peter

> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org]
> Sent: Tuesday, November 18, 2003 2:03 PM
> To: Busschbach, Peter B (Peter)
> Cc: 'David Allan'; 'curtis@fictitious.org'; 'tnadeau@cisco.com';
> mpls@UU.NET
> Subject: Re: on documenting ECMP (was on the mpls oam framework) 
> 
> 
> 
> In message 
> <B99995113B318D44BBE87DC50092EDA90C0D5500@nj7460exch006u.ho.lucent.c
> om>, "Busschbach, Peter B (Peter)" writes:
> > Dave, et.al.
> > 
> > In one of the side-branches of this discussion, the name 
> Dijkstra came up a c
> > ouple of times. Apart from inventing the famous algorithm, 
> Dijkstra did impor
> > tant work in the area of correctness proofs and concurrent 
> processes. One of 
> > his insights was that non-determinism is a powerful concept 
> and that a progra
> > m should be written in such a way that its correctness can 
> be proven, even in
> >  the face of non-determinism.
> > 
> > We have to be careful translating this to OAM (after all, 
> you don't want your
> >  service provider to blame non-determinism when your 
> connections fail), but l
> > et's give it a try.
> 
> Nice thought followed by a cheap shot, but fine.  I understand that
> you don't like ECMP and no one is asking you to like it, simply to
> accept that it is part of the architecture and it will be covered by
> whatever OAM emerges from the IETF.
> 
> > I think that ECMP is an issue only for a subset of traffic. 
> ECMP is not an is
> > sue for PW-traffic, since VCCV provides a solution. ECMP is 
> not an issue for 
> > services with QoS guarantees, where RSVP-TE is used to set 
> up the connection,
> >  because an explicit path is nailed down. 
> 
> QoS and explicit path are orthogonal.  Some provider may feel that
> they must combine the two in their service but it is not generally the
> case.  QoS and ECMP are also orthogonal.  Lets not try to sneak in
> assertions that may be true in your case but are not generally true.

I don't understand why RSVP-TE and ECMP are orthogonal. If one uses RSVP-TE to reserve bandwidth between two points, doesn't that nail down an exact end-to-end path? 


> 
> > The question in my mind is: for the traffic that is subject 
> to ECMP, is it re
> > ally crucial to know exactly how traffic is routed? 
> Shouldn't we just embrace
> >  non-determinism for the advantages that it provides and 
> find ways to work ar
> > ound it?
> 
> We did that in MPLS Ping.  The ingress can determine from the midpoint
> (essentially by the midpoint telling it) where ECMP branches exists
> and how to exercise each branch.  This method is deterministic and
> will exercise all paths.  The alternate is to randomly spray across
> the 127/8 space, which is non-deterministic but arguably will also
> exercise all paths.  The latter method can detect loss but not measure
> the loss experienced on any given path (loss may be concentrated in a
> subset of the traffic).
> 
> If other techniques want to do something similar to determine how to
> exercise ECMP paths, then they become applicable where ECMP is used.
> If they don't they are simply not applicable when ECMP is used.  One
> provider may choose to disable ECMP and use a technique that works
> only with ECMP disabled.  Another provider may choose to keep ECMP
> enabled and use a different OAM technique that works with ECMP.
> 
> > For example, when I surf the web, I don't need an ISP to be 
> able to send OAM 
> > packets along the exact same path that I used five minutes 
> ago. For such appl
> > ications, end-to-end OAM would not be relevant, but local 
> loopback tests migh
> > t be much more useful.
> 
> I'm quite confident that the PC in my home has not sent any OAM
> packets to the IETF mail servers to verify the path to the mail
> server.  But quite honestly this has nothing to do with the discussion
> of the OAM framework.  If I want to test to see if my ISP is live or
> the path to the IETF mail server is OK, I just use IP ping and
> traceroute.  Loopback tests are accomplished for your example.
> 
> > Peter 
> 
> We had some compromise and I fear that we are now slipping back to
> arguing about whether ECMP is part of the architecture.  I hope that
> is not the case.
> 
> Curtis
> 


From owner-mpls@UU.NET  Tue Nov 18 15:56: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 PAA15693
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 15:56: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 QQppjv18031
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 20:56: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 QQppjv17680;
	Tue, 18 Nov 2003 20:56:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppju25537
	for mpls-outgoing; Tue, 18 Nov 2003 20:34:45 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 QQppju25532
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 20:34:36 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 QQppju10231
	for <mpls@uu.net>; Tue, 18 Nov 2003 20:33: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 QQppju19919
	for <mpls@uu.net>; Tue, 18 Nov 2003 20:33:49 GMT
Received: from sj-iport-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72])
	id QQppju19903
	for <mpls@uu.net>; Tue, 18 Nov 2003 20:33:48 GMT
Received: from cisco.com (171.71.177.254)
  by sj-iport-3.cisco.com with ESMTP; 18 Nov 2003 12:42:04 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAIKXjw5024813
	for <mpls@uu.net>; Tue, 18 Nov 2003 12:33:46 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEB85710;
	Tue, 18 Nov 2003 15:33:44 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAIKXiS03532 for mpls@uu.net; Tue, 18 Nov 2003 15:33:44 -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 QQppju25435
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 20:32:28 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 QQppju08358
	for <mpls@UU.NET>; Tue, 18 Nov 2003 20:32: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 QQppju06246
	for <mpls@UU.NET>; Tue, 18 Nov 2003 20:32: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 QQppju06186
	for <mpls@UU.NET>; Tue, 18 Nov 2003 20:32:00 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hAIKVbL7030141;
	Tue, 18 Nov 2003 15:31:37 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311182031.hAIKVbL7030141@workhorse.fictitious.org>
To: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
cc: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "'David Allan'" <dallan@nortelnetworks.com>,
        "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: on documenting ECMP (was on the mpls oam framework) 
In-reply-to: Your message of "Tue, 18 Nov 2003 14:35:09 EST."
             <B99995113B318D44BBE87DC50092EDA90C0D5501@nj7460exch006u.ho.lucent.com> 
Date: Tue, 18 Nov 2003 15:31:37 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <B99995113B318D44BBE87DC50092EDA90C0D5501@nj7460exch006u.ho.lucent.c
om>, "Busschbach, Peter B (Peter)" writes:
> Curtis,
> 
> Something must have been lost in the translation, because you seem to interpr
> et most of my statements opposite to what I intended. I like ECMP. My email w
> as intended as a request to accept ECMP as a given and accept that it leads t
> o non-deterministic behavior in the network.
> 
> For fear of further slipping away from the compromise that you referred to, I
>  will leave most of your misinterpretations unanswered, but I do have a quest
> ion about one of your statements. Please see in-line.
> 
> Peter


Sorry.  I did very much misread your response.  Hopefully I'll do
better with the clarification below.


> > > I think that ECMP is an issue only for a subset of traffic. 
> > ECMP is not an is
> > > sue for PW-traffic, since VCCV provides a solution. ECMP is 
> > not an issue for 
> > > services with QoS guarantees, where RSVP-TE is used to set 
> > up the connection,
> > >  because an explicit path is nailed down. 
> > 
> > QoS and explicit path are orthogonal.  Some provider may feel that
> > they must combine the two in their service but it is not generally the
> > case.  QoS and ECMP are also orthogonal.  Lets not try to sneak in
> > assertions that may be true in your case but are not generally true.
> 
> I don't understand why RSVP-TE and ECMP are orthogonal. If one uses RSVP-TE t
> o reserve bandwidth between two points, doesn't that nail down an exact end-t
> o-end path? 


First of all:  RSVP/TE != explicit-path

They are related but not equal.  RSVP/TE paths can be determined by
the ingress based on the CSPF computation.  Explicit-path means the
path is predetermined and fixed.  RSVP/TE supports explicit-path as an
option.  When determined by the CSPF (explicit-path is not being
used), the path is in a sense nailed down, at least until the
adaptivity timer fires and a later CSPF decides there is a better path
now.

Also reserving bandwidth != QoS.  In most applications this is an
accounting action only - no queueing is allocated according to the
amount of reservation unless explicitly supported and configured to do
so and most routers don't even offer the ability to set quueuing
according to the bandwidth reservation as an option.  While I
personally think that setting WFQ weights according to the bandwidth
reservation is a good idea (and it appears you do too), ISPs don't
seem very interested in doing this.

There is also no reason why QoS can't exist with LDP and in fact it
does.  The simplest QoS is based on the EXP bits only.  Queueing is
set to favor some EXP values over others.  The amount of traffic with
the preferred EXP values must be limited.  In most cases it is limited
by market acceptance (very few willing to pay extra for higher QoS).

Another issue is whether a MPLS path is a single path.  In LDP,
clearly it need not be - if an ECMP situation exists anywhere along
the path traffic will split if ECMP is enabled.  With RSVP/TE if one
of the hops is a hierarchical hop, then although it is single logical
hop, there may be two or more LSPs configured between the pair of
nodes that are used to split the traffic.  Even if it were an
explicit-path (configured by operator or NMS) if a hop was a
hierarchical hop and ECMP was configured, the traffic would split (if
traffic is such that microflows could be identified).

In some routers a very large logical link between a pair of nodes may
be a concatonated set of lower bandwidth links.  For example, eight
OC48c can form a 20 GB logical link or eight OC192c can form a 80 GB
link (this is not a hypothetical btw).  Since this is a logical link,
it can either be assumed that the pair of nodes can handle monitoring
the link (which has proven safe, but..) or this can be treated as a
form of hierarchy and as an ECMP case to explicitly test all insegment
mappings from a tool such as MPLS Ping.

Without hierarchical LSPs, RSVP/TE does not have multipath unless 1)
more than one LSP is configured to the same destination with equal
cost and MP is enabled, or 2) more than one LSP is on a path to
different egress and the total cost is the same, and this form of MP
is both supported and enabled.  This form of MP is easy to deal with
from an OAM standpoint because the only branch is at ingress.

QoS based on EXP can be enabled and ECMP can also be enabled.  If each
branch of the path honors the EXP bits, QoS still works and exists in
the presense of ECMP, over LDP or RSVP/TE.  There is very clear
existance proof of this.

Curtis



From owner-mpls@UU.NET  Tue Nov 18 16:15: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 QAA16716
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 16: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 QQppjx26294
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 21:15: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 QQppjx26162;
	Tue, 18 Nov 2003 21:15:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppjv27596
	for mpls-outgoing; Tue, 18 Nov 2003 20:53: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 QQppjv27591
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 20:53: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 QQppjv28062
	for <mpls@UU.NET>; Tue, 18 Nov 2003 20:50: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 QQppjv05860
	for <mpls@UU.NET>; Tue, 18 Nov 2003 20:50:48 GMT
Received: from kummer.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint2.juniper.net [207.17.136.150])
	id QQppjv05829
	for <mpls@UU.NET>; Tue, 18 Nov 2003 20:50:47 GMT
Received: from kummer.juniper.net (localhost [127.0.0.1])
	by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id hAIKodda083973;
	Tue, 18 Nov 2003 12:50:39 -0800 (PST)
	(envelope-from kireeti@juniper.net)
Received: from localhost (kireeti@localhost)
	by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id hAIKodbF083970;
	Tue, 18 Nov 2003 12:50:39 -0800 (PST)
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
Date: Tue, 18 Nov 2003 12:50:39 -0800 (PST)
From: Kireeti Kompella <kireeti@juniper.net>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>
cc: mpls@UU.NET
Subject: Non-determinism considered harmless
In-Reply-To: <200311181902.hAIJ2gL7029639@workhorse.fictitious.org>
Message-ID: <20031118122341.H80400@kummer.juniper.net>
References: <200311181902.hAIJ2gL7029639@workhorse.fictitious.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Curtis,

On Tue, 18 Nov 2003, Curtis Villamizar wrote:

> In message <B99995113B318D44BBE87DC50092EDA90C0D5500@nj7460exch006u.ho.lucent.c
> om>, "Busschbach, Peter B (Peter)" writes:
> > Dave, et.al.
> >
> > In one of the side-branches of this discussion, the name Dijkstra came up a c
> > ouple of times. Apart from inventing the famous algorithm, Dijkstra did impor
> > tant work in the area of correctness proofs and concurrent processes. One of
> > his insights was that non-determinism is a powerful concept and that a progra
> > m should be written in such a way that its correctness can be proven, even in
> >  the face of non-determinism.
> >
> > We have to be careful translating this to OAM (after all, you don't want your
> >  service provider to blame non-determinism when your connections fail), but l
> > et's give it a try.
>
> Nice thought followed by a cheap shot, but fine.

Actually, I think Peter was trying to be helpful :-)

Stepping waaaay back, I think the real reason (at least, one of them)
for not liking ECMP (or for wanting to know the innards thereof) is
exactly that: non-determinism.  With connection-oriented, p2p circuits
everywhere, one can definitely (deterministically) point to the exact
boxes which a given 'flow' traverses.

Losing that determinism in the face of ECMP can be (for some) rather
like letting go of one's life-preserver -- infinitely scary, until you
realize that the human body does float.

To repeat Peter: "correctness can be proven, even in the face of
non-determinism" -- you just need the right invariant, and to prove
that each router preserves that invariant.  The invariant is of course
not reordering flows, and the post-condition is that the metric is
smaller.

The funny part about this is, some think that knowing all ECMP
algorithms would alleviate the non-determinism.  It would,
theoretically, but practically, the complexity of the algorithms, as
well as the random bits, makes the task of predicting flow paths next
to impossible.

Kireeti.
-------


From owner-mpls@UU.NET  Tue Nov 18 16:39: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 QAA19413
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 16:39: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 QQppjy04414
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 21:39: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 QQppjy04280;
	Tue, 18 Nov 2003 21:39:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppjx19179
	for mpls-outgoing; Tue, 18 Nov 2003 21:17: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 QQppjx19171
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 21:17: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 QQppjw12537
	for <mpls@UU.NET>; Tue, 18 Nov 2003 21:14: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 QQppjw11331
	for <mpls@UU.NET>; Tue, 18 Nov 2003 21:14:21 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 QQppjw11308
	for <mpls@UU.NET>; Tue, 18 Nov 2003 21:14:21 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 QAA01783;
	Tue, 18 Nov 2003 16:14:17 -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 QAA10131;
	Tue, 18 Nov 2003 16:14:18 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <W9W7SCCJ>; Tue, 18 Nov 2003 16:14:18 -0500
Message-ID: <39469E08BD83D411A3D900204840EC55FB70F7@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
Cc: "'David Allan'" <dallan@nortelnetworks.com>,
        "'tnadeau@cisco.com'"
	 <tnadeau@cisco.com>, mpls@UU.NET
Subject: RE: on documenting ECMP (was on the mpls oam framework) 
Date: Tue, 18 Nov 2003 16:14:14 -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

Curtis,

-> Without hierarchical LSPs, RSVP/TE does not have multipath unless 1)
-> more than one LSP is configured to the same destination with equal
-> cost and MP is enabled, or 2) more than one LSP is on a path to
-> different egress and the total cost is the same, and this form of MP
-> is both supported and enabled.  This form of MP is easy to deal with
-> from an OAM standpoint because the only branch is at ingress.

  Very delightful to read such a good technical explanation. But...
  what ever you said above that current MPLS signaling can't support
  ECMP at non-ingress branch point is a limitation. From MPLS-TE
  point of view, all the necessary information to split the traffic
  at non-ingress can be calculated easily. Unfortunately, signaling
  doesn't support that.

  If given a chance, such an ECMP split can be computed by ingress
  CSPF by finding all augmented "equal min-cost max-flow" paths to 
  the destination. Chosing any of least/farthest such common ancestor 
  split can be made as part of singaling decision.

-> QoS based on EXP can be enabled and ECMP can also be 
-> enabled.  If each
-> branch of the path honors the EXP bits, QoS still works and exists in
-> the presense of ECMP, over LDP or RSVP/TE.  There is very clear
-> existance proof of this.

  I view ECMP as a TE mechanism than a QoS workhorse. TE and QoS are
  infact orthogonal.

Venkata.


From owner-mpls@UU.NET  Tue Nov 18 17:00: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 RAA20270
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 17:00: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 QQppka07765
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 22:00:19 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 QQppka07637;
	Tue, 18 Nov 2003 22:00:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppjy20714
	for mpls-outgoing; Tue, 18 Nov 2003 21:38:25 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 QQppjy20703
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 21:38: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 QQppjy29234
	for <mpls@uu.net>; Tue, 18 Nov 2003 21:36: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 QQppjy12248
	for <mpls@uu.net>; Tue, 18 Nov 2003 21:36:02 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 QQppjy12227
	for <mpls@uu.net>; Tue, 18 Nov 2003 21:36:02 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 QAA02410
	for <mpls@uu.net>; Tue, 18 Nov 2003 16:35:59 -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 QAA13634
	for <mpls@uu.net>; Tue, 18 Nov 2003 16:36:00 -0500 (EST)
Message-ID: <3FBA90B5.4050609@marconi.com>
Date: Tue, 18 Nov 2003 16:35:49 -0500
From: David Charlap <David.Charlap@marconi.com>
Organization: Marconi, Vienna VA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en, he
MIME-Version: 1.0
To: IETF MPLS List <mpls@UU.NET>
Subject: Re: on documenting ECMP (was on the mpls oam framework)
References: <200311182031.hAIKVbL7030141@workhorse.fictitious.org>
In-Reply-To: <200311182031.hAIKVbL7030141@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 Villamizar wrote:
> 
> First of all:  RSVP/TE != explicit-path
> 
> They are related but not equal.  RSVP/TE paths can be determined by
> the ingress based on the CSPF computation.  Explicit-path means the
> path is predetermined and fixed.  RSVP/TE supports explicit-path as an
> option.  When determined by the CSPF (explicit-path is not being
> used), the path is in a sense nailed down, at least until the
> adaptivity timer fires and a later CSPF decides there is a better path
> now.

RSVP-TE's definition of "explicit" can be rather fluid, depending on the 
nature of the ERO object and how it is generated.

- An LSP may be signaled without an ERO object.  In which case, it 
follows the IGP's route to the egress address.  The route table may be 
populated by the result of CSPF, ECMP, or other mechanisms.  When the 
route table changes, the LSP reroutes to follow it.  This is obviously 
not in any way explicit.

- The path described by an ERO may terminate before the egress node is 
reached, in which case the remaining hops are determined using the route 
table and the egress address.  This is only explicit up to the end of 
the ERO.

- An ERO object may contain loose hops.  The next-hop chosen in response 
to a loose hop is a function of the routing table.  This is explicit in 
the sense that the LSP will pass through certain nodes, but the route 
taken between those nodes is not explicit.

- Since RSVP ERO hop addresses identify nodes, not links (except when 
the GMPLS IF_ID/unnumbered HOP extensions are used), the local route 
table is used to pick a link when multiple links exist between a pair of 
nodes along the path.

- Finally, the ERO used by the ingress node may be manually generated by 
an operator, or it may be computed by software external to RSVP.  If it 
is computed, then the ERO-computation software may choose to generate a 
new ERO and reroute the LSP as the network topology changes.  This is 
explicit from RSVP's perspective, but not necessarily from the 
operator's perspective.

RSVP's path is only fixed in the intuitive sense if an ERO consisting 
entirely of strict subobjects is used, and these subobjects lead all the 
way to the egress node, and the entity that computes the ERO (human or 
software) chooses not to reroute the LSP as the network changes.

-- David




From owner-mpls@UU.NET  Tue Nov 18 17:09: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 RAA20901
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 17:09: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 QQppka03573
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 22:10: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 QQppka03385;
	Tue, 18 Nov 2003 22:09:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppjz21804
	for mpls-outgoing; Tue, 18 Nov 2003 21:47:36 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 QQppjz21798
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 21:47: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 QQppjz22943
	for <mpls@uu.net>; Tue, 18 Nov 2003 21:47: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 QQppjz14907
	for <mpls@uu.net>; Tue, 18 Nov 2003 21:47:13 GMT
Received: from sj-iport-5.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-5.cisco.com [171.68.10.87])
	id QQppjz14898
	for <mpls@uu.net>; Tue, 18 Nov 2003 21:47:13 GMT
Received: from cisco.com (171.71.177.237)
  by sj-iport-5.cisco.com with ESMTP; 18 Nov 2003 13:47:30 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAILl9At003756
	for <mpls@uu.net>; Tue, 18 Nov 2003 13:47:09 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEB93734;
	Tue, 18 Nov 2003 16:47:08 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAILl8i08101 for mpls@uu.net; Tue, 18 Nov 2003 16:47: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 QQppjz21497
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 21:45: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 QQppjz22914
	for <mpls@uu.net>; Tue, 18 Nov 2003 21:45: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 QQppjz27315
	for <mpls@uu.net>; Tue, 18 Nov 2003 21:45:07 GMT
Received: from sj-iport-5.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-5.cisco.com [171.68.10.87])
	id QQppjz27305
	for <mpls@uu.net>; Tue, 18 Nov 2003 21:45:06 GMT
Received: from cisco.com (64.102.124.12)
  by sj-iport-5.cisco.com with ESMTP; 18 Nov 2003 13:45:23 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAILj1xi022104;
	Tue, 18 Nov 2003 16:45:03 -0500 (EST)
Received: from tnadeauw2k02 (che-vpn-cluster-1-94.cisco.com [10.86.240.94])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEB93493;
	Tue, 18 Nov 2003 16:44:59 -0500 (EST)
Reply-To: <tnadeau@cisco.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
To: "'Kireeti Kompella'" <kireeti@juniper.net>, <curtis@fictitious.org>
Cc: <mpls@UU.NET>
Subject: RE: Non-determinism considered harmless
Date: Tue, 18 Nov 2003 16:44:51 -0500
Organization: Cisco Systems, inc.
Message-ID: <00e301c3ae1d$35060f20$6701a8c0@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: <20031118122341.H80400@kummer.juniper.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
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 Kireeti Kompella
>Sent: Tuesday, November 18, 2003 3:51 PM
>To: 'curtis@fictitious.org'
>Cc: mpls@UU.NET
>Subject: Non-determinism considered harmless
>
>
>Hi Curtis,
>
>On Tue, 18 Nov 2003, Curtis Villamizar wrote:
>
>> In message 
><B99995113B318D44BBE87DC50092EDA90C0D5500@nj7460exch006u.ho.lucent.c
>> om>, "Busschbach, Peter B (Peter)" writes:
>> > Dave, et.al.
>> >
>> > In one of the side-branches of this discussion, the name 
>Dijkstra came up a c
>> > ouple of times. Apart from inventing the famous algorithm, 
>Dijkstra did impor
>> > tant work in the area of correctness proofs and concurrent 
>processes. One of
>> > his insights was that non-determinism is a powerful 
>concept and that a progra
>> > m should be written in such a way that its correctness can 
>be proven, even in
>> >  the face of non-determinism.
>> >
>> > We have to be careful translating this to OAM (after all, 
>you don't want your
>> >  service provider to blame non-determinism when your 
>connections fail), but l
>> > et's give it a try.
>>
>> Nice thought followed by a cheap shot, but fine.
>
>Actually, I think Peter was trying to be helpful :-)
>
>Stepping waaaay back, I think the real reason (at least, one of them)
>for not liking ECMP (or for wanting to know the innards thereof) is
>exactly that: non-determinism.  With connection-oriented, p2p circuits
>everywhere, one can definitely (deterministically) point to the exact
>boxes which a given 'flow' traverses.
>
>Losing that determinism in the face of ECMP can be (for some) rather
>like letting go of one's life-preserver -- infinitely scary, until you
>realize that the human body does float.
	
	Wow. MPLS is openning up new doors for revenue 
opportunities all the time. The newest application would
be therapists deployed with each ECMP-enabled box for 
those folks that ECMP is triggering panic attacks? *)

>To repeat Peter: "correctness can be proven, even in the face of
>non-determinism" -- you just need the right invariant, and to prove
>that each router preserves that invariant.  The invariant is of course
>not reordering flows, and the post-condition is that the metric is
>smaller.
>
>The funny part about this is, some think that knowing all ECMP
>algorithms would alleviate the non-determinism.  It would,
>theoretically, but practically, the complexity of the algorithms, as
>well as the random bits, makes the task of predicting flow paths next
>to impossible.

	Seriously, one point to make in all of this is that if you 
WANT determinism, it is available -- completely explicit paths 
signaled with RSVP-TE. If you can't stand to let go of the life 
preserver this is an option.  Like everything though, there is no 
free lunch, which is why many folks are willing to give up some
of that determinism.

	--Tom






From owner-mpls@UU.NET  Tue Nov 18 17:53: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 RAA23088
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 17:53: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 QQppkd29348
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 22:53: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 QQppkd29238;
	Tue, 18 Nov 2003 22:53:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppkc14479
	for mpls-outgoing; Tue, 18 Nov 2003 22:34: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 QQppkc14471
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 22:34: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 QQppkc21369
	for <mpls@UU.NET>; Tue, 18 Nov 2003 22:34: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 QQppkc06661
	for <mpls@UU.NET>; Tue, 18 Nov 2003 22:34:00 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 QQppkc06643
	for <mpls@UU.NET>; Tue, 18 Nov 2003 22:33:59 GMT
Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35])
	by ihemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAIMVuJ21375
	for <mpls@UU.NET>; Tue, 18 Nov 2003 16:32:30 -0600 (CST)
Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2656.59)
	id <TPL0BXRP>; Tue, 18 Nov 2003 17:31:56 -0500
Message-ID: <B99995113B318D44BBE87DC50092EDA90C0D550A@nj7460exch006u.ho.lucent.com>
From: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
To: "'Naidu, Venkata'" <Venkata.Naidu@Marconi.com>,
        "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
Cc: "'David Allan'" <dallan@nortelnetworks.com>,
        "'tnadeau@cisco.com'"
	 <tnadeau@cisco.com>, mpls@UU.NET
Subject: RE: on documenting ECMP (was on the mpls oam framework) 
Date: Tue, 18 Nov 2003 17:31:53 -0500
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



> -----Original Message-----
> From: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com]
> Sent: Tuesday, November 18, 2003 4:14 PM
> To: 'curtis@fictitious.org'; Busschbach, Peter B (Peter)
> Cc: 'David Allan'; 'tnadeau@cisco.com'; mpls@UU.NET
> Subject: RE: on documenting ECMP (was on the mpls oam framework) 
> 
> 
> Curtis,
> 
> -> Without hierarchical LSPs, RSVP/TE does not have multipath 
> unless 1)
> -> more than one LSP is configured to the same destination with equal
> -> cost and MP is enabled, or 2) more than one LSP is on a path to
> -> different egress and the total cost is the same, and this 
> form of MP
> -> is both supported and enabled.  This form of MP is easy to 
> deal with
> -> from an OAM standpoint because the only branch is at ingress.
> 
>   Very delightful to read such a good technical explanation. But...
>   what ever you said above that current MPLS signaling can't support
>   ECMP at non-ingress branch point is a limitation. From MPLS-TE
>   point of view, all the necessary information to split the traffic
>   at non-ingress can be calculated easily. Unfortunately, signaling
>   doesn't support that.
> 
>   If given a chance, such an ECMP split can be computed by ingress
>   CSPF by finding all augmented "equal min-cost max-flow" paths to 
>   the destination. Chosing any of least/farthest such common ancestor 
>   split can be made as part of singaling decision.
> 
> -> QoS based on EXP can be enabled and ECMP can also be 
> -> enabled.  If each
> -> branch of the path honors the EXP bits, QoS still works 
> and exists in
> -> the presense of ECMP, over LDP or RSVP/TE.  There is very clear
> -> existance proof of this.
> 
>   I view ECMP as a TE mechanism than a QoS workhorse. TE and QoS are
>   infact orthogonal.

String-theorist must be right: we live in a 10-dimensional world, because  everything seems to be orthogonal to everything else :-)

I would agree that TE is neither necessary nor sufficient for QoS, but to call them orthogonal is a little extreme.

It may be helpful if I reword my original point, which was:

1) ECMP leads to non-deterministic behavior. We should develop OAM mechanisms that accept that as a given

2) Nevertheless, for certain types of traffic it might be possible to use tools from the connection-oriented world. E.g. if a Service Provider uses RSVP-TE to reserve bandwidth between two points, it will result in a path without intermediate splits. 

That last statement was my assumption. Curtis argued that there are exceptions, such as the case of hierarchical hops where a logical link consists of multiple physical links. You argue that path calculations can theoretically deal with ECMP splits. 

I stand corrected. I do wonder how routers will distribute traffic over the multiple paths with bandwidth guarantees. As far as I know, current hashing algorithms leave the packet sequence of micro flows intact, but there is nothing that prevents them from sending 90% of the traffic over one path and 10% over another. Or is there?

Peter

> 
> Venkata.
> 


From owner-mpls@UU.NET  Tue Nov 18 18:06: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 SAA23809
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 18:06: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 QQppke04944
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 23:06: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 QQppke04576;
	Tue, 18 Nov 2003 23:06:47 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppkd15649
	for mpls-outgoing; Tue, 18 Nov 2003 22: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 QQppkd15637
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 22:45: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 QQppkc20779
	for <mpls@uu.net>; Tue, 18 Nov 2003 22:44: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 QQppkc26648
	for <mpls@uu.net>; Tue, 18 Nov 2003 22:44:43 GMT
Received: from sj-iport-3.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72])
	id QQppkc26636
	for <mpls@uu.net>; Tue, 18 Nov 2003 22:44:43 GMT
Received: from cisco.com (171.71.177.254)
  by sj-iport-3.cisco.com with ESMTP; 18 Nov 2003 14:52:59 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAIMiYw5028585
	for <mpls@uu.net>; Tue, 18 Nov 2003 14:44:39 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEB99212;
	Tue, 18 Nov 2003 17:44:32 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAIMiWR11859 for mpls@uu.net; Tue, 18 Nov 2003 17:44:32 -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 QQppkc15060
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 22:42:43 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 QQppkc19354
	for <mpls@UU.NET>; Tue, 18 Nov 2003 22:40: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 QQppkc21320
	for <mpls@UU.NET>; Tue, 18 Nov 2003 22:40: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 QQppkc21287
	for <mpls@UU.NET>; Tue, 18 Nov 2003 22:40:51 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hAIMeSL7030534;
	Tue, 18 Nov 2003 17:40:28 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311182240.hAIMeSL7030534@workhorse.fictitious.org>
To: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
cc: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "Busschbach,
    Peter B (Peter)" <busschbach@lucent.com>,
        "'David Allan'" <dallan@nortelnetworks.com>,
        "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: on documenting ECMP (was on the mpls oam framework) 
In-reply-to: Your message of "Tue, 18 Nov 2003 16:14:14 EST."
             <39469E08BD83D411A3D900204840EC55FB70F7@vie-msgusr-01.dc.fore.com> 
Date: Tue, 18 Nov 2003 17:40:27 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <39469E08BD83D411A3D900204840EC55FB70F7@vie-msgusr-01.dc.fore.com>, 
"Naidu, Venkata" writes:
> Curtis,
> 
> -> Without hierarchical LSPs, RSVP/TE does not have multipath unless 1)
> -> more than one LSP is configured to the same destination with equal
> -> cost and MP is enabled, or 2) more than one LSP is on a path to
> -> different egress and the total cost is the same, and this form of MP
> -> is both supported and enabled.  This form of MP is easy to deal with
> -> from an OAM standpoint because the only branch is at ingress.
> 
>   Very delightful to read such a good technical explanation. But...
>   what ever you said above that current MPLS signaling can't support
>   ECMP at non-ingress branch point is a limitation. From MPLS-TE
>   point of view, all the necessary information to split the traffic
>   at non-ingress can be calculated easily. Unfortunately, signaling
>   doesn't support that.

The ingress can set up two LSPs that take an identical path up to the
intended branch point.  The traffic is forwarded onto one of those two
LSP at the ingress.  Also note that the traffic split need not be
equal.  I don't see this as very limiting.

>   If given a chance, such an ECMP split can be computed by ingress
>   CSPF by finding all augmented "equal min-cost max-flow" paths to 
>   the destination. Chosing any of least/farthest such common ancestor 
>   split can be made as part of singaling decision.

Currently implementations (that I'm aware of) require the operator to
configure more than one LSP.  If there is one path with lots of
available bandwidth, both LSPs will take identical paths (obviously
though if the operator also asks that they be disjoint, they will take
very different paths, but the purpose of specifying disjoint is
different).  If there are two paths and neither can support both LSPs,
then the LSP will take separate paths.

I don't know of any implementation that creates extra LSP if it
notices equal cost paths.  A worst case (often used in testing with
the aid of simulationed topology) would be getting from one corner to
the other of a square grid.  There are an enormous number of equal
cost paths as the grid gets larger.

The case where split is completely automatic is where the total cost
to reach a given destination using two LSPs with different egress is
equal.  This is an IP only situation.  It can't occur other services.
Some implementations don't support this at all.  Some require that it
be enabled (or allow it to be disabled).

> -> QoS based on EXP can be enabled and ECMP can also be 
> -> enabled.  If each
> -> branch of the path honors the EXP bits, QoS still works and exists in
> -> the presense of ECMP, over LDP or RSVP/TE.  There is very clear
> -> existance proof of this.
> 
>   I view ECMP as a TE mechanism than a QoS workhorse. TE and QoS are
>   infact orthogonal.

That was the point I was getting at (or very close to it).  ECMP are
orthogonal.  As you point out TE and QoS are also orthogonal.  Maybe
in the long message the main point got lost.  Thanks for summarizing.

> Venkata.

Curtis



From owner-mpls@UU.NET  Tue Nov 18 18:35: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 SAA25532
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 18:35: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 QQppkg08381
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 23:36:09 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 QQppkg08201;
	Tue, 18 Nov 2003 23:36:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppkf08141
	for mpls-outgoing; Tue, 18 Nov 2003 23:16:25 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 QQppkf08130
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 23:16: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 QQppke04101
	for <mpls@UU.NET>; Tue, 18 Nov 2003 23:14: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 QQppke16883
	for <mpls@UU.NET>; Tue, 18 Nov 2003 23:14:33 GMT
Received: from prattle.redback.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: prattle.redback.com [155.53.12.9])
	id QQppke16862
	for <mpls@UU.NET>; Tue, 18 Nov 2003 23:14:32 GMT
Received: from localhost (localhost [127.0.0.1])
	by prattle.redback.com (Postfix) with ESMTP
	id 813208E7F21; Tue, 18 Nov 2003 15:14:31 -0800 (PST)
Received: from prattle.redback.com ([127.0.0.1])
 by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 28978-10; Tue, 18 Nov 2003 15:14:31 -0800 (PST)
Received: from redback.com (malt.redback.com [155.53.12.41])
	by prattle.redback.com (Postfix) with ESMTP
	id ED4818E7F22; Tue, 18 Nov 2003 15:14:30 -0800 (PST)
Received: from malt (localhost [127.0.0.1])
	by redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) with ESMTP id PAA05199;
	Tue, 18 Nov 2003 15:14:29 -0800 (PST)
Message-Id: <200311182314.PAA05199@redback.com>
To: mpls@UU.NET
Subject: Re: on documenting ECMP (was on the mpls oam framework) 
In-reply-to: Mail from "Busschbach, Peter B (Peter)" <busschbach@lucent.com> 
 dated Tue, 18 Nov 2003 13:21:46 EST
 <B99995113B318D44BBE87DC50092EDA90C0D5500@nj7460exch006u.ho.lucent.com> 
Date: Tue, 18 Nov 2003 15:14:28 -0800
From: Naiming Shen <naiming@redback.com>
X-Virus-Scanned: by amavisd-new at redback.com
Sender: owner-mpls@UU.NET
Precedence: bulk


some of the routers even "secretly" perform UnEqual Cost Multi-Path,
please also document those.

- Naiming


From owner-mpls@UU.NET  Tue Nov 18 18:48: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 SAA26311
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 18:48:44 -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 QQppkh14432
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 23: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 QQppkh14180;
	Tue, 18 Nov 2003 23:48:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppkf08725
	for mpls-outgoing; Tue, 18 Nov 2003 23:28:45 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 QQppkf08715
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 23:28:30 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 QQppkf21034
	for <mpls@UU.NET>; Tue, 18 Nov 2003 23:28:02 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 QQppkf12030
	for <mpls@UU.NET>; Tue, 18 Nov 2003 23:28:02 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 QQppkf12014
	for <mpls@UU.NET>; Tue, 18 Nov 2003 23:28: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 SAA05048;
	Tue, 18 Nov 2003 18:27:57 -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 SAA25663;
	Tue, 18 Nov 2003 18:27:59 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <W9W7SFJV>; Tue, 18 Nov 2003 18:27:58 -0500
Message-ID: <39469E08BD83D411A3D900204840EC55FB70F8@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'Busschbach, Peter B (Peter)'" <busschbach@lucent.com>,
        "Naidu, Venkata" <Venkata.Naidu@Marconi.com>,
        "'curtis@fictitious.org'"
	 <curtis@fictitious.org>
Cc: "'David Allan'" <dallan@nortelnetworks.com>,
        "'tnadeau@cisco.com'"
	 <tnadeau@cisco.com>, mpls@UU.NET
Subject: RE: on documenting ECMP (was on the mpls oam framework) 
Date: Tue, 18 Nov 2003 18:27:53 -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

Peter,

-> It may be helpful if I reword my original point, which was:
-> 
-> 1) ECMP leads to non-deterministic behavior. We should 
-> develop OAM mechanisms that accept that as a given

  Agreed. ECMP is non-deterministic. Note also that non-determinism 
  leads to freedom and innovation. If there is no requirement
  to follow a standard and there is no requirement to interoperate
  with other vendor's implementation, vendor's can develop
  innovative mechanisms to support ECMP. Why are we restricting
  our community and trying to enumerate *current* practices ?

-> 2) Nevertheless, for certain types of traffic it might be 
-> possible to use tools from the connection-oriented world. 
-> E.g. if a Service Provider uses RSVP-TE to reserve bandwidth 
-> between two points, it will result in a path without 
-> intermediate splits. 

  No. Not always.

-> That last statement was my assumption. Curtis argued that 
-> there are exceptions, such as the case of hierarchical hops 
-> where a logical link consists of multiple physical links. 
-> You argue that path calculations can theoretically deal with 
-> ECMP splits. 

  Yes.

-> I stand corrected. I do wonder how routers will distribute 
-> traffic over the multiple paths with bandwidth guarantees. 
-> As far as I know, current hashing algorithms leave the 
-> packet sequence of micro flows intact, but there is nothing 
-> that prevents them from sending 90% of the traffic over one 
-> path and 10% over another. Or is there?

  No. Nothing preventing from doing so. But, finally, note that 
  any problem may be non-determinisic in nature, but proposed 
  solutions, algorithms and/or implementations are infact 
  deterministic for known-agreed-upon approximations/limitations.
  And a solution is not required to conver all degeneracies or corner
  cases. 

Venkata.


From owner-mpls@UU.NET  Tue Nov 18 19:03: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 TAA26833
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 19:03: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 QQppki26814
	for <mpls-archive@lists.ietf.org>; Wed, 19 Nov 2003 00:03: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 QQppki26710;
	Wed, 19 Nov 2003 00:03:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppkg09563
	for mpls-outgoing; Tue, 18 Nov 2003 23:44: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 QQppkg09548
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 23:44:18 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 QQppkg27396
	for <mpls@UU.NET>; Tue, 18 Nov 2003 23:43: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 QQppkg04242
	for <mpls@UU.NET>; Tue, 18 Nov 2003 23:43:57 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 QQppkg04212
	for <mpls@UU.NET>; Tue, 18 Nov 2003 23:43:56 GMT
Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35])
	by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAINhrE20730
	for <mpls@UU.NET>; Tue, 18 Nov 2003 17:43:53 -0600 (CST)
Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2656.59)
	id <TPL0B5G9>; Tue, 18 Nov 2003 18:43:52 -0500
Message-ID: <B99995113B318D44BBE87DC50092EDA90C0D550F@nj7460exch006u.ho.lucent.com>
From: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
To: "'Naidu, Venkata'" <Venkata.Naidu@Marconi.com>,
        "Busschbach, Peter B (Peter)" <busschbach@lucent.com>,
        "'curtis@fictitious.org'" <curtis@fictitious.org>
Cc: "'David Allan'" <dallan@nortelnetworks.com>,
        "'tnadeau@cisco.com'"
	 <tnadeau@cisco.com>, mpls@UU.NET
Subject: RE: on documenting ECMP (was on the mpls oam framework) 
Date: Tue, 18 Nov 2003 18:43:51 -0500
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



> -----Original Message-----
> From: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com]
> Sent: Tuesday, November 18, 2003 6:28 PM
> To: 'Busschbach, Peter B (Peter)'; Naidu, Venkata;
> 'curtis@fictitious.org'
> Cc: 'David Allan'; 'tnadeau@cisco.com'; mpls@UU.NET
> Subject: RE: on documenting ECMP (was on the mpls oam framework) 
> 
> 
> Peter,
> 
> -> It may be helpful if I reword my original point, which was:
> -> 
> -> 1) ECMP leads to non-deterministic behavior. We should 
> -> develop OAM mechanisms that accept that as a given
> 
>   Agreed. ECMP is non-deterministic. Note also that non-determinism 
>   leads to freedom and innovation. If there is no requirement
>   to follow a standard and there is no requirement to interoperate
>   with other vendor's implementation, vendor's can develop
>   innovative mechanisms to support ECMP. Why are we restricting
>   our community and trying to enumerate *current* practices ?
> 
> -> 2) Nevertheless, for certain types of traffic it might be 
> -> possible to use tools from the connection-oriented world. 
> -> E.g. if a Service Provider uses RSVP-TE to reserve bandwidth 
> -> between two points, it will result in a path without 
> -> intermediate splits. 
> 
>   No. Not always.
> 
> -> That last statement was my assumption. Curtis argued that 
> -> there are exceptions, such as the case of hierarchical hops 
> -> where a logical link consists of multiple physical links. 
> -> You argue that path calculations can theoretically deal with 
> -> ECMP splits. 
> 
>   Yes.
> 
> -> I stand corrected. I do wonder how routers will distribute 
> -> traffic over the multiple paths with bandwidth guarantees. 
> -> As far as I know, current hashing algorithms leave the 
> -> packet sequence of micro flows intact, but there is nothing 
> -> that prevents them from sending 90% of the traffic over one 
> -> path and 10% over another. Or is there?
> 
>   No. Nothing preventing from doing so. But, finally, note that 
>   any problem may be non-determinisic in nature, but proposed 
>   solutions, algorithms and/or implementations are infact 
>   deterministic for known-agreed-upon approximations/limitations.
>   And a solution is not required to conver all degeneracies or corner
>   cases. 

Forgive me for being simple-minded:

My question is: if I use RSVP-TE to be guaranteed that 10 Mb/s of bandwidth is reserved for my aggregate traffic, would I ever want to use ECMP splits in the end-to-end path?

I understand that that is theoretically possible within agreed-upon limitations. But are these limitations narrow enough to make this a realistic scenario. Or do I just have to reserve 10 Mb/s along each of the multiple paths?

> 
> Venkata.
> 


From owner-mpls@UU.NET  Tue Nov 18 19:20: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 TAA27310
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 19:20: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 QQppkj02641
	for <mpls-archive@lists.ietf.org>; Wed, 19 Nov 2003 00:20:51 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 QQppkj02415;
	Wed, 19 Nov 2003 00:20:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppkh10662
	for mpls-outgoing; Tue, 18 Nov 2003 23:59:25 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 QQppkh10656
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Nov 2003 23:59:16 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 QQppkh08985
	for <mpls@UU.NET>; Tue, 18 Nov 2003 23:58: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 QQppkh27008
	for <mpls@UU.NET>; Tue, 18 Nov 2003 23:58:02 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 QQppkh26987
	for <mpls@UU.NET>; Tue, 18 Nov 2003 23:58:02 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 SAA05433;
	Tue, 18 Nov 2003 18:57:58 -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 SAA28165;
	Tue, 18 Nov 2003 18:58:00 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <W9W7SF6L>; Tue, 18 Nov 2003 18:57:59 -0500
Message-ID: <39469E08BD83D411A3D900204840EC55FB70F9@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'Busschbach, Peter B (Peter)'" <busschbach@lucent.com>,
        "'curtis@fictitious.org'" <curtis@fictitious.org>
Cc: "'David Allan'" <dallan@nortelnetworks.com>,
        "'tnadeau@cisco.com'"
	 <tnadeau@cisco.com>, mpls@UU.NET
Subject: RE: on documenting ECMP (was on the mpls oam framework) 
Date: Tue, 18 Nov 2003 18:57:49 -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

Peter,

-> Forgive me for being simple-minded:

  Forgive me for such a general explanation.

-> My question is: if I use RSVP-TE to be guaranteed that 10 
-> Mb/s of bandwidth is reserved for my aggregate traffic, 
-> would I ever want to use ECMP splits in the end-to-end path?

  Not required. But if ECMP is enabled you never know.

-> I understand that that is theoretically possible within 
-> agreed-upon limitations. But are these limitations narrow 
-> enough to make this a realistic scenario. Or do I just have 
-> to reserve 10 Mb/s along each of the multiple paths?

  No. No need to reserve 10 Mb/s along each of the multiple path.

  Some ECMP models are control plane directed with a prior
  knowledge of far away hops and current load on bottle-neck 
  links. If, for example, there are two different paths to
  reach the destination. Each of those paths have different
  bottle-neck links and the demand for some links are high
  along a path then ECMP can split traffic proportionately.

  In such a case reserving 10 Mb/s is not advised. Reserving
  10Mb/s on every multiple path is an overkill. Some vendors
  can do so for resiliency. I never heard of such.

Venkata.


From owner-mpls@UU.NET  Tue Nov 18 19:41: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 TAA28028
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 19:41: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 QQppkk11305
	for <mpls-archive@lists.ietf.org>; Wed, 19 Nov 2003 00:41:09 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 QQppkk11105;
	Wed, 19 Nov 2003 00:41:03 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppkj01206
	for mpls-outgoing; Wed, 19 Nov 2003 00:19:04 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 QQppkj01194
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Nov 2003 00:18:55 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 QQppkj26729
	for <mpls@UU.NET>; Wed, 19 Nov 2003 00:15: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 QQppkj23901
	for <mpls@UU.NET>; Wed, 19 Nov 2003 00:15:33 GMT
Received: from linus.bcentralhost.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: linus.bcentralhost.com [205.158.154.16])
	id QQppkj23874
	for <mpls@UU.NET>; Wed, 19 Nov 2003 00:15:32 GMT
Received: (root@localhost)
	by linus.bcentralhost.com
	id TAA24567; Tue, 18 Nov 2003 19:15:30 -0500 (EST)
	[ConcentricHost SMTP Relay 1.14]
Message-ID: <200311190015.TAA24567@linus.bcentralhost.com>
From: mark seery <mark@interflect.com>
To: <mpls@UU.NET>
Subject: RE: Non-determinism considered harmless
Date: Tue, 18 Nov 2003 19:15:30 -0500 (EST)
In-Reply-To: <00e301c3ae1d$35060f20$6701a8c0@amer.cisco.com> from "Thomas D. Nadeau" <tnadeau@cisco.com> on Tue, 18 Nov 2003 16:44:51 -0500
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Some philosopher's say there is no such thing as truth, just optimization for a result (very amoral of course, but a worthwhile observation none the less).

It is clear shortest-path routing is an optimization that has proven very nice indeed, it is clear the explicit routing is an optimization that has proven useful as well. It is also worth noting that the packet networks envisioned by Paul Baran had even less determinision than what we think of as IP today - and that was an opimization for a specific result. So everyone has there determinism life preserver of choice (for some its as simple as in the light of a constant topology packets will always flow along the same path).

What we all are is obvious, we are just arguing over the size of the preserver at this point. 


From owner-mpls@UU.NET  Tue Nov 18 20:54: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 UAA01205
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 20:54: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 QQppkp15805
	for <mpls-archive@lists.ietf.org>; Wed, 19 Nov 2003 01:54:18 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 QQppkp15621;
	Wed, 19 Nov 2003 01:54:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppko24801
	for mpls-outgoing; Wed, 19 Nov 2003 01:35:03 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 QQppko24792
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Nov 2003 01:34: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 QQppko09913
	for <mpls@uu.net>; Wed, 19 Nov 2003 01:33: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 QQppko24760
	for <mpls@uu.net>; Wed, 19 Nov 2003 01:33:27 GMT
Received: from sj-iport-5.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-5.cisco.com [171.68.10.87])
	id QQppko24749
	for <mpls@uu.net>; Wed, 19 Nov 2003 01:33:26 GMT
Received: from cisco.com (64.102.124.13)
  by sj-iport-5.cisco.com with ESMTP; 18 Nov 2003 17:33:45 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAJ1XNDM026038
	for <mpls@uu.net>; Tue, 18 Nov 2003 20:33:23 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEC09958;
	Tue, 18 Nov 2003 20:33:22 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAJ1XLs20364 for mpls@uu.net; Tue, 18 Nov 2003 20:33: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 QQppko24697
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Nov 2003 01:32:18 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 QQppko05207
	for <mpls@uu.net>; Wed, 19 Nov 2003 01:31: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 QQppko10985
	for <mpls@uu.net>; Wed, 19 Nov 2003 01:31:45 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 QQppko10954
	for <mpls@uu.net>; Wed, 19 Nov 2003 01:31:44 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hAJ1U8L7030879;
	Tue, 18 Nov 2003 20:30:09 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311190130.hAJ1U8L7030879@workhorse.fictitious.org>
To: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
cc: "'Naidu, Venkata'" <Venkata.Naidu@Marconi.com>,
        "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "'David Allan'" <dallan@nortelnetworks.com>,
        "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: on documenting ECMP (was on the mpls oam framework) 
In-reply-to: Your message of "Tue, 18 Nov 2003 17:31:53 EST."
             <B99995113B318D44BBE87DC50092EDA90C0D550A@nj7460exch006u.ho.lucent.com> 
Date: Tue, 18 Nov 2003 20:30:08 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <B99995113B318D44BBE87DC50092EDA90C0D550A@nj7460exch006u.ho.lucent.c
om>, "Busschbach, Peter B (Peter)" writes:
> 
[snip]
> 
> I would agree that TE is neither necessary nor sufficient for QoS, but to cal
> l them orthogonal is a little extreme.
> 
> It may be helpful if I reword my original point, which was:
> 
> 1) ECMP leads to non-deterministic behavior. We should develop OAM mechanisms
>  that accept that as a given

Agreed.

> 2) Nevertheless, for certain types of traffic it might be possible to use too
> ls from the connection-oriented world. E.g. if a Service Provider uses RSVP-T
> E to reserve bandwidth between two points, it will result in a path without i
> ntermediate splits. 
> 
> That last statement was my assumption. Curtis argued that there are exception
> s, such as the case of hierarchical hops where a logical link consists of mul
> tiple physical links. You argue that path calculations can theoretically deal
>  with ECMP splits. 

But the ISP will know that these exist unless the links are going
across another providers infrastructure in which case the provider
should not see any adverse affects (but could infer by reordering of
packet from different microflows that ECMP was used).

> I stand corrected. I do wonder how routers will distribute traffic over the m
> ultiple paths with bandwidth guarantees. As far as I know, current hashing al
> gorithms leave the packet sequence of micro flows intact, but there is nothin
> g that prevents them from sending 90% of the traffic over one path and 10% ov
> er another. Or is there?
> 
> Peter

There is no guarentee but even when the Internet was made up of T1
lines there was enough diversity in the flows to keep the balance
reasonably good.  Back then and in the T3-NSFNET days the NSF funded
supercomputer centers could open a TCP connection that would seriously
bias the split to one branch.  Single wide area host to host TCP flows
much over OC12c have not even been demonstrated.  The fastest wide
area host flows remain well under 100 mb/s even though 1 Gb/s on the
LAN is not so hard to do.  At 100 Mb/s over 10 msec RTT (5 msec each
way) you need a 125 MB TCP send and receive buffer and machines
configured to allow that much buffering per TCP flow are quite rare
(again, most likely "big science" still at it).  Any packet loss
whatsoever would greatly reduce the throughput.  Typical wide area
flows would be well 1 mb/s.  Lots of these on a 10 Gb/s link tend to
spread out quite evenly.  They even spread out nicely over OC3c.  When
you get down below DS3, load split can be quite uneven.

Back in the late 1990s there was speculation that single host to host
microflows might reach OC12c or even OC48c speeds due to traffic
between IPsec gateways that appeared as a single flow.  That hasn't
happenned at all.

So the answer is - in theory it could be a problem.  In practice, for
IP it never is.  For PW that is not expected to be the case so very
large PW LSPs may have to be handled by ISPs with some caution.

If QoS is EXP based, and preferred traffic remains very small, whether
you have 90% of a very small number or 50% of a very small number on
one side doesn't matter.  What does matter is how much of the total
traffic ends up on either leg and there it is more likely that the
split will be even, and the consequence of it not being even is
limited.  If the non-QoS traffic is all IP then in practice split will
be very even.

btw- probability dictates that the gases in a room will be more or
less evenly distributed, but it not entirely deterministic so the
distribution is never perfect, and there is no guarentee that all of
the oxygen won't migrate to one side of the room such that people on
the other side will suffocate.  I think you get my point.  :-)

Curtis



From owner-mpls@UU.NET  Tue Nov 18 21:05: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 VAA01511
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 21:05: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 QQppkq16140
	for <mpls-archive@lists.ietf.org>; Wed, 19 Nov 2003 02:05: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 QQppkq15954;
	Wed, 19 Nov 2003 02:05:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppkp25978
	for mpls-outgoing; Wed, 19 Nov 2003 01:49:03 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 QQppkp25938
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Nov 2003 01:48:45 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 QQppkp18816
	for <mpls@uu.net>; Wed, 19 Nov 2003 01:48: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 QQppkp01248
	for <mpls@uu.net>; Wed, 19 Nov 2003 01:48:26 GMT
Received: from sj-iport-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72])
	id QQppkp01243
	for <mpls@uu.net>; Wed, 19 Nov 2003 01:48:26 GMT
Received: from cisco.com (171.71.177.237)
  by sj-iport-3.cisco.com with ESMTP; 18 Nov 2003 17:56:44 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAJ1mMAt026421
	for <mpls@uu.net>; Tue, 18 Nov 2003 17:48:23 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEC11048;
	Tue, 18 Nov 2003 20:48:21 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAJ1mLh21205 for mpls@uu.net; Tue, 18 Nov 2003 20:48: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 QQppkp25815
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Nov 2003 01:46: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 QQppko08421
	for <mpls@UU.NET>; Wed, 19 Nov 2003 01:44: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 QQppko29453
	for <mpls@UU.NET>; Wed, 19 Nov 2003 01:44:29 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 QQppko29421
	for <mpls@UU.NET>; Wed, 19 Nov 2003 01:44:28 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hAJ1hxL7030926;
	Tue, 18 Nov 2003 20:43:59 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311190143.hAJ1hxL7030926@workhorse.fictitious.org>
To: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
cc: "'Busschbach, Peter B (Peter)'" <busschbach@lucent.com>,
        "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "'David Allan'" <dallan@nortelnetworks.com>,
        "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: on documenting ECMP (was on the mpls oam framework) 
In-reply-to: Your message of "Tue, 18 Nov 2003 18:27:53 EST."
             <39469E08BD83D411A3D900204840EC55FB70F8@vie-msgusr-01.dc.fore.com> 
Date: Tue, 18 Nov 2003 20:43:59 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <39469E08BD83D411A3D900204840EC55FB70F8@vie-msgusr-01.dc.fore.com>, 
"Naidu, Venkata" writes:
> Peter,
> 
> -> It may be helpful if I reword my original point, which was:
> -> 
> -> 1) ECMP leads to non-deterministic behavior. We should 
> -> develop OAM mechanisms that accept that as a given
> 
>   Agreed. ECMP is non-deterministic. Note also that non-determinism 
>   leads to freedom and innovation. If there is no requirement
>   to follow a standard and there is no requirement to interoperate
>   with other vendor's implementation, vendor's can develop
>   innovative mechanisms to support ECMP. Why are we restricting
>   our community and trying to enumerate *current* practices ?

We are free to inovate and all of the ECMP implementations
interoperate with each other and the existance of any new ECMP
implementation which did nothing but ECMP but did it completely
differently would also interoperate.

> -> 2) Nevertheless, for certain types of traffic it might be 
> -> possible to use tools from the connection-oriented world. 
> -> E.g. if a Service Provider uses RSVP-TE to reserve bandwidth 
> -> between two points, it will result in a path without 
> -> intermediate splits. 
> 
>   No. Not always.
> 
> -> That last statement was my assumption. Curtis argued that 
> -> there are exceptions, such as the case of hierarchical hops 
> -> where a logical link consists of multiple physical links. 
> -> You argue that path calculations can theoretically deal with 
> -> ECMP splits. 
> 
>   Yes.
> 
> -> I stand corrected. I do wonder how routers will distribute 
> -> traffic over the multiple paths with bandwidth guarantees. 
> -> As far as I know, current hashing algorithms leave the 
> -> packet sequence of micro flows intact, but there is nothing 
> -> that prevents them from sending 90% of the traffic over one 
> -> path and 10% over another. Or is there?
> 
>   No. Nothing preventing from doing so. But, finally, note that 
>   any problem may be non-determinisic in nature, but proposed 
>   solutions, algorithms and/or implementations are infact 
>   deterministic for known-agreed-upon approximations/limitations.
>   And a solution is not required to conver all degeneracies or corner
>   cases. 
> 
> Venkata.

All of the oxygen must be on one side of the room.  :-(

Curtis



From owner-mpls@UU.NET  Tue Nov 18 21:30: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 VAA02129
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 21:30: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 QQppks22598
	for <mpls-archive@lists.ietf.org>; Wed, 19 Nov 2003 02:30: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 QQppks22313;
	Wed, 19 Nov 2003 02:30:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppkq16766
	for mpls-outgoing; Wed, 19 Nov 2003 02:14:04 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 QQppkq16758
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Nov 2003 02: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 QQppkq21254
	for <mpls@uu.net>; Wed, 19 Nov 2003 02:02: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 QQppkq10518
	for <mpls@uu.net>; Wed, 19 Nov 2003 02:02:44 GMT
Received: from sj-iport-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71])
	id QQppkq10499
	for <mpls@uu.net>; Wed, 19 Nov 2003 02:02:44 GMT
Received: from cisco.com (171.71.177.237)
  by sj-iport-2.cisco.com with ESMTP; 18 Nov 2003 18:06:26 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAJ22fAt006815
	for <mpls@uu.net>; Tue, 18 Nov 2003 18:02:41 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEC11944;
	Tue, 18 Nov 2003 21:02:40 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAJ22eu23703 for mpls@uu.net; Tue, 18 Nov 2003 21:02: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 QQppkq03299
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Nov 2003 02:01: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 QQppkq22852
	for <mpls@UU.NET>; Wed, 19 Nov 2003 02:00: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 QQppkq26681
	for <mpls@UU.NET>; Wed, 19 Nov 2003 02:00: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 QQppkq26636
	for <mpls@UU.NET>; Wed, 19 Nov 2003 02:00:49 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hAJ21CL7030973;
	Tue, 18 Nov 2003 21:01:13 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311190201.hAJ21CL7030973@workhorse.fictitious.org>
To: David Charlap <David.Charlap@marconi.com>
cc: IETF MPLS List <mpls@UU.NET>
Reply-To: curtis@fictitious.org
Subject: Re: on documenting ECMP (was on the mpls oam framework) 
In-reply-to: Your message of "Tue, 18 Nov 2003 16:35:49 EST."
             <3FBA90B5.4050609@marconi.com> 
Date: Tue, 18 Nov 2003 21:01:12 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <3FBA90B5.4050609@marconi.com>, David Charlap writes:
> Curtis Villamizar wrote:
> > 
> > First of all:  RSVP/TE != explicit-path
> > 
> > They are related but not equal.  RSVP/TE paths can be determined by
> > the ingress based on the CSPF computation.  Explicit-path means the
> > path is predetermined and fixed.  RSVP/TE supports explicit-path as an
> > option.  When determined by the CSPF (explicit-path is not being
> > used), the path is in a sense nailed down, at least until the
> > adaptivity timer fires and a later CSPF decides there is a better path
> > now.
> 
> RSVP-TE's definition of "explicit" can be rather fluid, depending on the 
> nature of the ERO object and how it is generated.
> 
> - An LSP may be signaled without an ERO object.  In which case, it 
> follows the IGP's route to the egress address.  The route table may be 
> populated by the result of CSPF, ECMP, or other mechanisms.  When the 
> route table changes, the LSP reroutes to follow it.  This is obviously 
> not in any way explicit.
> 
> - The path described by an ERO may terminate before the egress node is 
> reached, in which case the remaining hops are determined using the route 
> table and the egress address.  This is only explicit up to the end of 
> the ERO.
> 
> - An ERO object may contain loose hops.  The next-hop chosen in response 
> to a loose hop is a function of the routing table.  This is explicit in 
> the sense that the LSP will pass through certain nodes, but the route 
> taken between those nodes is not explicit.
> 
> - Since RSVP ERO hop addresses identify nodes, not links (except when 
> the GMPLS IF_ID/unnumbered HOP extensions are used), the local route 
> table is used to pick a link when multiple links exist between a pair of 
> nodes along the path.
> 
> - Finally, the ERO used by the ingress node may be manually generated by 
> an operator, or it may be computed by software external to RSVP.  If it 
> is computed, then the ERO-computation software may choose to generate a 
> new ERO and reroute the LSP as the network topology changes.  This is 
> explicit from RSVP's perspective, but not necessarily from the 
> operator's perspective.
> 
> RSVP's path is only fixed in the intuitive sense if an ERO consisting 
> entirely of strict subobjects is used, and these subobjects lead all the 
> way to the egress node, and the entity that computes the ERO (human or 
> software) chooses not to reroute the LSP as the network changes.
> 
> -- David


I was using the RFC2702 definition of explicit-path.

  5.6.1 Administratively Specified Explicit Paths

   An administratively specified explicit path for a traffic trunk is
   one which is configured through operator action. An administratively
   specified path can be completely specified or partially specified. A
   path is completely specified if all of the required hops between the
   endpoints are indicated. A path is partially specified if only a
   subset of intermediate hops are indicated. In this case, the
   underlying protocols are required to complete the path.  [... etc]

Note that the term explicit path is used *only* for this case at least
in RFC2702 and AFAIK is not redefined differently in any other RFC.

My statement still stands: RSVP/TE != explicit-path.  And the rest of
it remains true.  I neglected to mention that an explicit-path may
contain loose hops.

Your statement is also entirely correct.  I think we are going off
into detail on a tangent.  Just wanted to clarify where the definition
comes from and that it really does mean "configured" (which can
include SNMP - to fend off another possible tangient).

Curtis

btw - in case anyone thinks ECMP is some new requirement (also from
RFC2702, dated Sep 1999):

  5.6.5 Load Distribution Across Parallel Traffic Trunks

   Load distribution across multiple parallel traffic trunks between two
   nodes is an important consideration.  In many practical contexts, the
   aggregate traffic between two nodes may be such that no single link
   (hence no single path) can carry the load. However, the aggregate
   flow might be less than the maximum permissible flow across a "min-
   cut" that partitions the two nodes. In this case, the only feasible
   solution is to appropriately divide the aggregate traffic into sub-
   streams and route the sub-streams through multiple paths between the
   two nodes.



From owner-mpls@UU.NET  Tue Nov 18 21:44: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 VAA02466
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 21:44: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 QQppks14601
	for <mpls-archive@lists.ietf.org>; Wed, 19 Nov 2003 02:44: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 QQppks14397;
	Wed, 19 Nov 2003 02:44:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppkr17911
	for mpls-outgoing; Wed, 19 Nov 2003 02:27: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 QQppkr17894
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Nov 2003 02:27:17 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 QQppkr22795
	for <mpls@uu.net>; Wed, 19 Nov 2003 02:24: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 QQppkr13308
	for <mpls@uu.net>; Wed, 19 Nov 2003 02:24:48 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 QQppkr13295
	for <mpls@uu.net>; Wed, 19 Nov 2003 02:24:47 GMT
Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35])
	by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAJ2OiE23094
	for <mpls@uu.net>; Tue, 18 Nov 2003 20:24:45 -0600 (CST)
Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2656.59)
	id <TPL0B9HS>; Tue, 18 Nov 2003 21:24:43 -0500
Message-ID: <B99995113B318D44BBE87DC50092EDA90C0D5513@nj7460exch006u.ho.lucent.com>
From: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
Cc: "'Naidu, Venkata'" <Venkata.Naidu@Marconi.com>,
        "'David Allan'"
	 <dallan@nortelnetworks.com>,
        "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Subject: RE: on documenting ECMP (was on the mpls oam framework) 
Date: Tue, 18 Nov 2003 21:24:42 -0500
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, Curtis. You make a convincing argument.

One last question:

What happens with RSVP-TE messages at an ECMP split? Suppose a source node sends a Path message requesting reservation of 10 Mb/s of bandwidth. When it reaches the ECMP split, will that router generate two Path messages, each requesting 5 Mb/s, and forward them along the two equal-cost paths to the destination?

Peter



> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org]
> Sent: Tuesday, November 18, 2003 8:30 PM
> To: Busschbach, Peter B (Peter)
> Cc: 'Naidu, Venkata'; 'curtis@fictitious.org'; 'David Allan';
> 'tnadeau@cisco.com'; mpls@uu.net
> Subject: Re: on documenting ECMP (was on the mpls oam framework) 
> 
> 
> 
> In message 
> <B99995113B318D44BBE87DC50092EDA90C0D550A@nj7460exch006u.ho.lucent.c
> om>, "Busschbach, Peter B (Peter)" writes:
> > 
> [snip]
> > 
> > I would agree that TE is neither necessary nor sufficient 
> for QoS, but to cal
> > l them orthogonal is a little extreme.
> > 
> > It may be helpful if I reword my original point, which was:
> > 
> > 1) ECMP leads to non-deterministic behavior. We should 
> develop OAM mechanisms
> >  that accept that as a given
> 
> Agreed.
> 
> > 2) Nevertheless, for certain types of traffic it might be 
> possible to use too
> > ls from the connection-oriented world. E.g. if a Service 
> Provider uses RSVP-T
> > E to reserve bandwidth between two points, it will result 
> in a path without i
> > ntermediate splits. 
> > 
> > That last statement was my assumption. Curtis argued that 
> there are exception
> > s, such as the case of hierarchical hops where a logical 
> link consists of mul
> > tiple physical links. You argue that path calculations can 
> theoretically deal
> >  with ECMP splits. 
> 
> But the ISP will know that these exist unless the links are going
> across another providers infrastructure in which case the provider
> should not see any adverse affects (but could infer by reordering of
> packet from different microflows that ECMP was used).
> 
> > I stand corrected. I do wonder how routers will distribute 
> traffic over the m
> > ultiple paths with bandwidth guarantees. As far as I know, 
> current hashing al
> > gorithms leave the packet sequence of micro flows intact, 
> but there is nothin
> > g that prevents them from sending 90% of the traffic over 
> one path and 10% ov
> > er another. Or is there?
> > 
> > Peter
> 
> There is no guarentee but even when the Internet was made up of T1
> lines there was enough diversity in the flows to keep the balance
> reasonably good.  Back then and in the T3-NSFNET days the NSF funded
> supercomputer centers could open a TCP connection that would seriously
> bias the split to one branch.  Single wide area host to host TCP flows
> much over OC12c have not even been demonstrated.  The fastest wide
> area host flows remain well under 100 mb/s even though 1 Gb/s on the
> LAN is not so hard to do.  At 100 Mb/s over 10 msec RTT (5 msec each
> way) you need a 125 MB TCP send and receive buffer and machines
> configured to allow that much buffering per TCP flow are quite rare
> (again, most likely "big science" still at it).  Any packet loss
> whatsoever would greatly reduce the throughput.  Typical wide area
> flows would be well 1 mb/s.  Lots of these on a 10 Gb/s link tend to
> spread out quite evenly.  They even spread out nicely over OC3c.  When
> you get down below DS3, load split can be quite uneven.
> 
> Back in the late 1990s there was speculation that single host to host
> microflows might reach OC12c or even OC48c speeds due to traffic
> between IPsec gateways that appeared as a single flow.  That hasn't
> happenned at all.
> 
> So the answer is - in theory it could be a problem.  In practice, for
> IP it never is.  For PW that is not expected to be the case so very
> large PW LSPs may have to be handled by ISPs with some caution.
> 
> If QoS is EXP based, and preferred traffic remains very small, whether
> you have 90% of a very small number or 50% of a very small number on
> one side doesn't matter.  What does matter is how much of the total
> traffic ends up on either leg and there it is more likely that the
> split will be even, and the consequence of it not being even is
> limited.  If the non-QoS traffic is all IP then in practice split will
> be very even.
> 
> btw- probability dictates that the gases in a room will be more or
> less evenly distributed, but it not entirely deterministic so the
> distribution is never perfect, and there is no guarentee that all of
> the oxygen won't migrate to one side of the room such that people on
> the other side will suffocate.  I think you get my point.  :-)
> 
> Curtis
> 


From owner-mpls@UU.NET  Tue Nov 18 22:08: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 WAA03261
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 22:08: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 QQppku06298
	for <mpls-archive@lists.ietf.org>; Wed, 19 Nov 2003 03: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 QQppku06218;
	Wed, 19 Nov 2003 03:08:33 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppkt19938
	for mpls-outgoing; Wed, 19 Nov 2003 02:48: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 QQppkt19933
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Nov 2003 02:48:11 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 QQppkt19773
	for <mpls@uu.net>; Wed, 19 Nov 2003 02:47: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 QQppkt05104
	for <mpls@uu.net>; Wed, 19 Nov 2003 02:47:21 GMT
Received: from sj-iport-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71])
	id QQppkt05070
	for <mpls@uu.net>; Wed, 19 Nov 2003 02:47:19 GMT
Received: from cisco.com (171.71.177.238)
  by sj-iport-2.cisco.com with ESMTP; 18 Nov 2003 18:51:01 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAJ2W5jq003279
	for <mpls@uu.net>; Tue, 18 Nov 2003 18:32:05 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEC13134;
	Tue, 18 Nov 2003 21:32:04 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAJ2W4a26366 for mpls@uu.net; Tue, 18 Nov 2003 21:32: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 QQppks18450
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Nov 2003 02:30:35 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 QQppks20920
	for <mpls@UU.NET>; Wed, 19 Nov 2003 02:30: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 QQppks07100
	for <mpls@UU.NET>; Wed, 19 Nov 2003 02:30:22 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 QQppks07077
	for <mpls@UU.NET>; Wed, 19 Nov 2003 02:30:21 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hAJ2UUL7031153;
	Tue, 18 Nov 2003 21:30:30 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311190230.hAJ2UUL7031153@workhorse.fictitious.org>
To: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
cc: "'Naidu, Venkata'" <Venkata.Naidu@Marconi.com>,
        "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "'David Allan'" <dallan@nortelnetworks.com>,
        "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: on documenting ECMP (was on the mpls oam framework) 
In-reply-to: Your message of "Tue, 18 Nov 2003 18:43:51 EST."
             <B99995113B318D44BBE87DC50092EDA90C0D550F@nj7460exch006u.ho.lucent.com> 
Date: Tue, 18 Nov 2003 21:30:30 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <B99995113B318D44BBE87DC50092EDA90C0D550F@nj7460exch006u.ho.lucent.c
om>, "Busschbach, Peter B (Peter)" writes:
> 
> 
> My question is: if I use RSVP-TE to be guaranteed that 10 Mb/s of bandwidth i
> s reserved for my aggregate traffic, would I ever want to use ECMP splits in 
> the end-to-end path?

  From a practical standpoint - probably not unless you had a T1
  backbone (somewhere in the third world or maybe enterprise).

  If you had 10 Gb/s of aggregate traffic and an Oc192c backbone,
  you'd probably want to make two 5 Gb/s LSPs.  Even more so if you
  had 12 Gb/s of aggregate traffic and an Oc192c backbone.

  Does this happen.  I doubt any ISP is going to tell you what their
  aggregate IP flow is from NY or DC to SF Bay area or LA or San
  Diego, .. or Chicago, or Dallas or Houston.  I know that some ISPs
  found that some city pairs could become a very big number and exceed
  the capacity of any any single link.

  For two 6 Gb/s LSPs on a Oc192c backbone, you get diverse paths for
  nothing.  For two 4 Gb/s LSPs, you have to ask for them to be
  diverse.  The benefit is you get a fast temporary failover if one
  path goes down (no signaling needed, but not guarantee against
  transient congestion) good to hold you over for the CSPF and LSP
  signaling time.

  There are of course methods to either bundle or concatonate links to
  make a bigger pipe that the componsent OC192c.  But bundling
  requires that you make multiple LSPs and load split and
  concatonating makes a logical interface but load splits over the
  component links.

  So briefly, - yes -, there can be a reason to want to load split
  traffic (though maybe not 10 mb/s of traffic).

> I understand that that is theoretically possible within agreed-upon limitatio
> ns. But are these limitations narrow enough to make this a realistic scenario
> . Or do I just have to reserve 10 Mb/s along each of the multiple paths?

Again, scaling the example up to 3 orders of magnitude to where there
is an ECMP issue.  If the oxygen in the room ends up on one side of
the room, then all of the IP traffic might also end up on one link.
You need to decide if you are willing to take these chances.

Curtis



From owner-mpls@UU.NET  Tue Nov 18 22:13:15 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 WAA03386
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 22:13: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 QQppku00447
	for <mpls-archive@lists.ietf.org>; Wed, 19 Nov 2003 03:13: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 QQppku00244;
	Wed, 19 Nov 2003 03:13:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppkt20317
	for mpls-outgoing; Wed, 19 Nov 2003 02:53: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 QQppkt20309
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Nov 2003 02:53:42 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 QQppkt00421
	for <mpls@uu.net>; Wed, 19 Nov 2003 02:53: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 QQppkt27050
	for <mpls@uu.net>; Wed, 19 Nov 2003 02:53:00 GMT
Received: from sj-iport-4.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-4.cisco.com [171.68.10.86])
	id QQppkt27027
	for <mpls@uu.net>; Wed, 19 Nov 2003 02:53:00 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAJ2quDM006472
	for <mpls@uu.net>; Tue, 18 Nov 2003 21:52:57 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEC13829;
	Tue, 18 Nov 2003 21:52:56 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAJ2quS27540 for mpls@uu.net; Tue, 18 Nov 2003 21:52:56 -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 QQppkt19853
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Nov 2003 02:46: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 QQppks12601
	for <mpls@UU.NET>; Wed, 19 Nov 2003 02:44: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 QQppks01034
	for <mpls@UU.NET>; Wed, 19 Nov 2003 02:44:15 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 QQppks00985
	for <mpls@UU.NET>; Wed, 19 Nov 2003 02:44:14 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hAJ2iEL7031182;
	Tue, 18 Nov 2003 21:44:14 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311190244.hAJ2iEL7031182@workhorse.fictitious.org>
To: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
cc: "'Busschbach, Peter B (Peter)'" <busschbach@lucent.com>,
        "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "'David Allan'" <dallan@nortelnetworks.com>,
        "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: on documenting ECMP (was on the mpls oam framework) 
In-reply-to: Your message of "Tue, 18 Nov 2003 18:57:49 EST."
             <39469E08BD83D411A3D900204840EC55FB70F9@vie-msgusr-01.dc.fore.com> 
Date: Tue, 18 Nov 2003 21:44:14 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <39469E08BD83D411A3D900204840EC55FB70F9@vie-msgusr-01.dc.fore.com>, 
"Naidu, Venkata" writes:
> Peter,
> 
> -> Forgive me for being simple-minded:
> 
>   Forgive me for such a general explanation.
> 
> -> My question is: if I use RSVP-TE to be guaranteed that 10 
> -> Mb/s of bandwidth is reserved for my aggregate traffic, 
> -> would I ever want to use ECMP splits in the end-to-end path?
> 
>   Not required. But if ECMP is enabled you never know.
> 
> -> I understand that that is theoretically possible within 
> -> agreed-upon limitations. But are these limitations narrow 
> -> enough to make this a realistic scenario. Or do I just have 
> -> to reserve 10 Mb/s along each of the multiple paths?
> 
>   No. No need to reserve 10 Mb/s along each of the multiple path.
> 
>   Some ECMP models are control plane directed with a prior
>   knowledge of far away hops and current load on bottle-neck 
>   links. If, for example, there are two different paths to
>   reach the destination. Each of those paths have different
>   bottle-neck links and the demand for some links are high
>   along a path then ECMP can split traffic proportionately.
> 
>   In such a case reserving 10 Mb/s is not advised. Reserving
>   10Mb/s on every multiple path is an overkill. Some vendors
>   can do so for resiliency. I never heard of such.
> 
> Venkata.
>

If you create on LSP and want 10 mb/s then reserve 10 mb/s.  If it
goes over a hierarchical link that splits in two that logical link is
credited with another 10 mb/s and the two logical links should get 5
mb/s each.  A realy smart implementation might even tweak the number
of hash buckets on either side of the split if the split was uneven
(if for example you tossed a few PW LSPs inside an LSP with PW and
IP).

If you put one PW LSP over a hierarchical link that splits in two (and
nothing else so you can't possibly load split) you can't split the
traffic so all the traffic goes one way.  Its your network, why did
you configure it this way?  Can you fix it - sure - just remove one
component of the hierarchical link.

Note that for this to happen (a split in the middle of an LSP) the
operator had to configure two LSPs between the same pair of nodes and
then define a hierarchical link (or run LDP over it).  An explicit
configuration was needed to make this possible.  If you don't
configure hierarchical links, RSVP/TE links will never split in the
middle of an LSP.  If you never configure two LSP from the same
ingress to the same egress and run LDP over the this pair of nodes and
you disable LDP ECMP, LDP (over RSVP/TE or not) will also never split
traffic (although reservations and LDP don't go together).

I'm sorry if this is degenerating into a tutorial by examples.

Curtis



From owner-mpls@UU.NET  Tue Nov 18 23:05: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 XAA04945
	for <mpls-archive@lists.ietf.org>; Tue, 18 Nov 2003 23:05: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 QQppky28265
	for <mpls-archive@lists.ietf.org>; Wed, 19 Nov 2003 04: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 QQppky28124;
	Wed, 19 Nov 2003 04:05:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppkx13240
	for mpls-outgoing; Wed, 19 Nov 2003 03:46: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 QQppkx13235
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Nov 2003 03:46: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 QQppkw28020
	for <mpls@uu.net>; Wed, 19 Nov 2003 03:44: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 QQppkw13797
	for <mpls@uu.net>; Wed, 19 Nov 2003 03:44:49 GMT
Received: from sj-iport-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70])
	id QQppkw13780
	for <mpls@uu.net>; Wed, 19 Nov 2003 03:44:48 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAJ3ijw5022030
	for <mpls@uu.net>; Tue, 18 Nov 2003 19:44:45 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEC16609;
	Tue, 18 Nov 2003 22:44:44 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAJ3iiX03694 for mpls@uu.net; Tue, 18 Nov 2003 22:44:44 -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 QQppkw12714
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Nov 2003 03:43: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 QQppkw09386
	for <mpls@uu.net>; Wed, 19 Nov 2003 03:42: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 QQppkw11378
	for <mpls@uu.net>; Wed, 19 Nov 2003 03:42:45 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 QQppkw11363
	for <mpls@uu.net>; Wed, 19 Nov 2003 03:42:44 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hAJ3gmL7031429;
	Tue, 18 Nov 2003 22:42:48 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311190342.hAJ3gmL7031429@workhorse.fictitious.org>
To: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
cc: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "'Naidu,
    Venkata'" <Venkata.Naidu@Marconi.com>,
        "'David Allan'" <dallan@nortelnetworks.com>,
        "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: on documenting ECMP (was on the mpls oam framework) 
In-reply-to: Your message of "Tue, 18 Nov 2003 21:24:42 EST."
             <B99995113B318D44BBE87DC50092EDA90C0D5513@nj7460exch006u.ho.lucent.com> 
Date: Tue, 18 Nov 2003 22:42:48 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <B99995113B318D44BBE87DC50092EDA90C0D5513@nj7460exch006u.ho.lucent.c
om>, "Busschbach, Peter B (Peter)" writes:
> Thanks, Curtis. You make a convincing argument.
> 
> One last question:
> 
> What happens with RSVP-TE messages at an ECMP split? Suppose a source node se
> nds a Path message requesting reservation of 10 Mb/s of bandwidth. When it re
> aches the ECMP split, will that router generate two Path messages, each reque
> sting 5 Mb/s, and forward them along the two equal-cost paths to the destinat
> ion?
> 
> Peter


Peter,

This email thread has a life of its own.  Not a comment to you but
maybe I should be appologizing for the email bandwidht I've used up.

I did try to answer that in another response.  Briefly, at a
hierarchical link you have a logical link so if you ask for 10 mb/s it
has to find 10 mb/s.  If its a bundle it finds 10 mb/s on a single
component.  If it is load spliting, it may split two ways in effect
taking 5 mb/s from each side.  Obviously it has to have 5 mb/s
available on each component LSP of the hierarchical LSP to do so.

Keep in mind that how a LSR decides how much bandwidth to allocate to
a hierarchical LSP and when to change this allocation is not defined.
[Lots of room for innovation.  The ITU guys are gonna hate it.  And
now that its been brought up we may end up spending a lot of time
explaining why it will interoperate. :) ]

Curtis



From owner-mpls@UU.NET  Wed Nov 19 04:12: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 EAA09647
	for <mpls-archive@lists.ietf.org>; Wed, 19 Nov 2003 04:12: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 QQppls26493
	for <mpls-archive@lists.ietf.org>; Wed, 19 Nov 2003 09:12:58 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 QQppls26069;
	Wed, 19 Nov 2003 09:12:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpplr06350
	for mpls-outgoing; Wed, 19 Nov 2003 08:53: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 QQpplr06342
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Nov 2003 08:53: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 QQpplr10799
	for <mpls@UU.NET>; Wed, 19 Nov 2003 08:53: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 QQpplr23294
	for <mpls@UU.NET>; Wed, 19 Nov 2003 08:53:12 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 QQpplr23278
	for <mpls@UU.NET>; Wed, 19 Nov 2003 08:53:12 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAJ8qYA17422;
	Wed, 19 Nov 2003 03:52:34 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <W3H80SSD>; Wed, 19 Nov 2003 03:52:35 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D02B92816@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'curtis@fictitious.org'" <curtis@fictitious.org>
Cc: "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Subject: RE: on documenting ECMP (was on the mpls oam framework) 
Date: Wed, 19 Nov 2003 03:52:33 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Curtis:

We have different interpretation of the requirements....and that seems to
see us talking past each other. If tools are to measure/test/verify the data
plane, then there needs to be some behavior target to shoot for. Using PING
to reverse engineer the network are devise a test plan is ONE solution but
one I (and apparently others) think can be improved upon. LSR-SELF test is
closer as we are starting to recognize that delegating responsibilty for
testing all perumations to all boxes results in a lot of useless traffic,
but IMO is still a bit heavyweight as a solution and requires ubiquitous
deployment, that its heavyweight is a personal option, that it requires
ubiquitous deployment is a fact. Does that mean I don't like ping, wrong, I
just do not see it as a universal panacea. I've already expressed that
opinion publically and in drafts. The emergence of BFD with more or less the
same technical justification as 1711 w.r.t. ping would seem to suggest I am
not alone.

As we have different expectations as to what degree of monitoring/auditing
network behavior is appropriate, it is no surprise we do not agree on the
degree of specification required and the appropriateness of all tools in all
applications. How you manage to covert this into an attitude that you are
interested in compromising in the interest of progress and I am not
completely escapes me....

cheers
Dave


> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] 
> Sent: Tuesday, November 18, 2003 12:53 PM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: 'curtis@fictitious.org'; 'tnadeau@cisco.com'; mpls@UU.NET
> Subject: Re: on documenting ECMP (was on the mpls oam framework) 
> 
> 
> 
> In message 
> <FFFC48AEAA5F7447929F4F0D93FCC12D02B92810@zcard031.ca.nortel.c
> om>, " David Allan" writes:
> > Curtis:
> > 
> > You misuderstand me, I lump all tools (including LSP-PING, 
> BFD, VCCV, 
> > ITU
> > efforts) together under the blanket of OAM.
> > 
> > enough for now
> > Dave
> 
> 
> Some of these tools *will* work with ECMP without apriori 
> knowledge of how the split is accomplished.  Therefore you've 
> just negated your emphatic assertion that "Vendors who want 
> interoperable OAM MUST publish the protocol specifics....!"
> 
> Unless in some situations you lump all of these monitoring 
> tools as OAM and in other cases are talking about ITU OAM.
> 
> I agree that this is enough for now.
> 
> Curtis
> 
> 
> 
> > 
> > > -----Original Message-----
> > > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org]
> > > Sent: Tuesday, November 18, 2003 11:56 AM
> > > To: Allan, David [CAR:NS00:EXCH]
> > > Cc: 'curtis@fictitious.org'; 'tnadeau@cisco.com'; mpls@UU.NET
> > > Subject: Re: on documenting ECMP (was on the mpls oam framework) 
> > > 
> > > 
> > > 
> > > In message
> > > <FFFC48AEAA5F7447929F4F0D93FCC12D02B9280B@zcard031.ca.nortel.c
> > > om>, " David Allan" writes:
> > > > Curtis:
> > > > 
> > > > >From my perspective there is simply OAM.
> > > 
> > > Then withdraw as an author of the framework document.  That
> > > would be like Ohta writing the IP over ATM framework 
> > > (Conventional IP or ATM advocate).
> > > 
> > > > To date a fundamental obstacle to progressing OAM has been
> > > the issue
> > > > of how OAM flows are distinguished, esp in the presence of
> > > ECMP. When
> > > > a packet needs to be IP, when it needs to not alias as IP,
> > > > restrictions on the use of reserved labels to 
> distinguish flows and 
> > > > where such labels can appear in the stack, yadda yadda 
> > > yadda. This has
> > > > been an obstacle to discussing the actual functionality 
> required 
> > > > or
> > > > any other relative merits as all solutions have been held 
> > > up to this
> > > > problem first without the actual problem to be solved being
> > > documented
> > > > anywhere.
> > > > 
> > > > Taking ECMP off the table as an issue by documenting at a
> > > minimum the
> > > > protocol aspects so we can get on with the actual functionality
> > > > required would IMO be progress. The lack of information has 
> > > been THE
> > > > obstruction all along.....
> > > > 
> > > > cheers
> > > > Dave
> > > 
> > > See my prior email.  If OAM doesn't work with ECMP as it
> > > exists in the real world then it is just an applicability 
> > > issue that needs to be documented.
> > > 
> > > Curtis
> 


From owner-mpls@UU.NET  Wed Nov 19 04:13: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 EAA09672
	for <mpls-archive@lists.ietf.org>; Wed, 19 Nov 2003 04:13: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 QQppls10803
	for <mpls-archive@lists.ietf.org>; Wed, 19 Nov 2003 09:13: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 QQppls10561;
	Wed, 19 Nov 2003 09:13:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpplr06399
	for mpls-outgoing; Wed, 19 Nov 2003 08:54: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 QQpplr06394
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Nov 2003 08:54:46 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 QQpplr28893
	for <mpls@UU.NET>; Wed, 19 Nov 2003 08: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 QQpplr09474
	for <mpls@UU.NET>; Wed, 19 Nov 2003 08:53:39 GMT
Received: from zcars04f.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57])
	id QQpplr09462
	for <mpls@UU.NET>; Wed, 19 Nov 2003 08:53:38 GMT
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAJ8rCA17444;
	Wed, 19 Nov 2003 03:53:13 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <W3H80SSJ>; Wed, 19 Nov 2003 03:53:13 -0500
Message-ID: <FFFC48AEAA5F7447929F4F0D93FCC12D02B92817@zcard031.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "'Busschbach, Peter B (Peter)'" <busschbach@lucent.com>,
        "'curtis@fictitious.org'" <curtis@fictitious.org>
Cc: "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Subject: RE: on documenting ECMP (was on the mpls oam framework) 
Date: Wed, 19 Nov 2003 03:53:12 -0500
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Peter:

> In one of the side-branches of this discussion, the name 
> Dijkstra came up a couple of times. Apart from inventing the 
> famous algorithm, Dijkstra did important work in the area of 
> correctness proofs and concurrent processes. One of his 
> insights was that non-determinism is a powerful concept and 
> that a program should be written in such a way that its 
> correctness can be proven, even in the face of non-determinism.
> 
> We have to be careful translating this to OAM (after all, you 
> don't want your service provider to blame non-determinism 
> when your connections fail), but let's give it a try.

OK
 
> I think that ECMP is an issue only for a subset of traffic. 
> ECMP is not an issue for PW-traffic, since VCCV provides a 
> solution. 

For currently deployed ECMP. Everyone seems to want to reserve the right to
do proprietary future versions. As soon as we get into snooping PW payloads,
all bets are off.... ;-)

> ECMP is not an issue for services with QoS 
> guarantees, where RSVP-TE is used to set up the connection, 
> because an explicit path is nailed down. 
> 
> The question in my mind is: for the traffic that is subject 
> to ECMP, is it really crucial to know exactly how traffic is 
> routed? Shouldn't we just embrace non-determinism for the 
> advantages that it provides and find ways to work around it?

No, actually IMHO ECMP introduces connectivity components that are not known
to upstream components therefore expecting those components to have
responsibility for verification of the "unknowable" is unreasonable, and
introduces a lot of extra load on the network. George has proposed a
solution in LSR-SELF test, I have a solution that fits my sensibilities in
17fec-cv.

> For example, when I surf the web, I don't need an ISP to be 
> able to send OAM packets along the exact same path that I 
> used five minutes ago. For such applications, end-to-end OAM 
> would not be relevant, but local loopback tests might be much 
> more useful.

I presume you're referring to the ECMP node doing more, I agree in general
that distributing responsibility for testing ECMP needs to move to the ECMP
implementing LSRs on the basis of the argument above. IMHO that eliminates
non-determinism.

cheers
Dave


From owner-mpls@UU.NET  Wed Nov 19 11:27: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 LAA24633
	for <mpls-archive@lists.ietf.org>; Wed, 19 Nov 2003 11:27: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 QQppmv14575
	for <mpls-archive@lists.ietf.org>; Wed, 19 Nov 2003 16:27: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 QQppmv14316;
	Wed, 19 Nov 2003 16:27:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppmu06689
	for mpls-outgoing; Wed, 19 Nov 2003 16:05: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 QQppmu06651
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Nov 2003 16:05: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 QQppmu28144
	for <mpls@UU.NET>; Wed, 19 Nov 2003 16:04:18 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 QQppmu09213
	for <mpls@UU.NET>; Wed, 19 Nov 2003 16:04:17 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 QQppmu09196
	for <mpls@UU.NET>; Wed, 19 Nov 2003 16:04:17 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 LAA24271
	for <mpls@UU.NET>; Wed, 19 Nov 2003 11:04:14 -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 LAA18957
	for <mpls@UU.NET>; Wed, 19 Nov 2003 11:04:15 -0500 (EST)
Message-ID: <3FBB9472.1010700@marconi.com>
Date: Wed, 19 Nov 2003 11:04:02 -0500
From: David Charlap <David.Charlap@marconi.com>
Organization: Marconi, Vienna VA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en, he
MIME-Version: 1.0
To: IETF MPLS List <mpls@UU.NET>
Subject: Re: on documenting ECMP (was on the mpls oam framework)
References: <200311190201.hAJ21CL7030973@workhorse.fictitious.org>
In-Reply-To: <200311190201.hAJ21CL7030973@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 Villamizar wrote:
> David Charlap writes:
>> Curtis Villamizar wrote:
>>> 
>>> First of all:  RSVP/TE != explicit-path ...
>> 
>> RSVP-TE's definition of "explicit" can be rather fluid, depending
>> on the nature of the ERO object and how it is generated. ...
> 
> I was using the RFC2702 definition of explicit-path. ...
> 
> My statement still stands: RSVP/TE != explicit-path.  And the rest of
> it remains true.  I neglected to mention that an explicit-path may
> contain loose hops.

I think you misunderstood my post.  I was posting more detailed
information about RSVP in support of your statement, not as a
counterexample.

RSVP-TE can only be considered equivalent with explicit-path for a small 
subset of the various mechanisms that RSVP implementations may generate 
and use the EXPLICIT_ROUTE object - for other usages, they are not even 
close to equivalent.

> Your statement is also entirely correct.  I think we are going off
> into detail on a tangent.  Just wanted to clarify where the
> definition comes from and that it really does mean "configured"
> (which can include SNMP - to fend off another possible tangient).

-- David



From owner-mpls@UU.NET  Wed Nov 19 11:36: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 LAA25030
	for <mpls-archive@lists.ietf.org>; Wed, 19 Nov 2003 11:36: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 QQppmw29342
	for <mpls-archive@lists.ietf.org>; Wed, 19 Nov 2003 16:36: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 QQppmw28956;
	Wed, 19 Nov 2003 16:36:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppmu08168
	for mpls-outgoing; Wed, 19 Nov 2003 16:13: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 QQppmu08136
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Nov 2003 16: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 QQppmu06818
	for <mpls@uu.net>; Wed, 19 Nov 2003 16:12:02 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 QQppmu02642
	for <mpls@uu.net>; Wed, 19 Nov 2003 16:12:02 GMT
Received: from sj-iport-3.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72])
	id QQppmu02621
	for <mpls@uu.net>; Wed, 19 Nov 2003 16:12:02 GMT
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 19 Nov 2003 08:12:23 +0000
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAJGBwjq011605
	for <mpls@uu.net>; Wed, 19 Nov 2003 08:11:59 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEC44232;
	Wed, 19 Nov 2003 11:11:57 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAJGBvX11452 for mpls@uu.net; Wed, 19 Nov 2003 11:11:57 -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 QQppmu07334
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Nov 2003 16: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 QQppmu02031
	for <mpls@UU.NET>; Wed, 19 Nov 2003 16:09: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 QQppmu28516
	for <mpls@UU.NET>; Wed, 19 Nov 2003 16:09: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 QQppmu28447
	for <mpls@UU.NET>; Wed, 19 Nov 2003 16:09:47 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id hAJG5tL7033008;
	Wed, 19 Nov 2003 11:05:55 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200311191605.hAJG5tL7033008@workhorse.fictitious.org>
To: "David Allan" <dallan@nortelnetworks.com>
cc: "'curtis@fictitious.org'" <curtis@fictitious.org>,
        "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: on documenting ECMP (was on the mpls oam framework) 
In-reply-to: Your message of "Wed, 19 Nov 2003 03:52:33 EST."
             <FFFC48AEAA5F7447929F4F0D93FCC12D02B92816@zcard031.ca.nortel.com> 
Date: Wed, 19 Nov 2003 11:05:55 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <FFFC48AEAA5F7447929F4F0D93FCC12D02B92816@zcard031.ca.nortel.com>, "
David Allan" writes:
> Hi Curtis:
> 
> We have different interpretation of the requirements....and that seems to
> see us talking past each other. If tools are to measure/test/verify the data
> plane, then there needs to be some behavior target to shoot for. Using PING
> to reverse engineer the network are devise a test plan is ONE solution but
> one I (and apparently others) think can be improved upon. LSR-SELF test is
> closer as we are starting to recognize that delegating responsibilty for
> testing all perumations to all boxes results in a lot of useless traffic,
> but IMO is still a bit heavyweight as a solution and requires ubiquitous
> deployment, that its heavyweight is a personal option, that it requires
> ubiquitous deployment is a fact. Does that mean I don't like ping, wrong, I
> just do not see it as a universal panacea. I've already expressed that
> opinion publically and in drafts. The emergence of BFD with more or less the
> same technical justification as 1711 w.r.t. ping would seem to suggest I am
> not alone.
> 
> As we have different expectations as to what degree of monitoring/auditing
> network behavior is appropriate, it is no surprise we do not agree on the
> degree of specification required and the appropriateness of all tools in all
> applications. How you manage to covert this into an attitude that you are
> interested in compromising in the interest of progress and I am not
> completely escapes me....
> 
> cheers
> Dave


Dave,

I hadn't intended to send another message but you summarized your
position nicely above.

At this point both of us should agree to disagree and stop talking.

You beleive that every aspect of forwarding must be know exactly in
order to support OAM and therefor determinism is a requirement for
forwarding.  The longer summary is above.

I believe that in a (large) subset of the community it is a
requirement to that there be OAM tools that work in the presence of
ECMP where forwarding of any one packet is not deterministic from the
standpoint of the ingress.  I believe that both those tools that
require completely deterministic forwarding and those that don't
should be supported.

If you agree that both types of tools can exist and the architecture
should not describe either ECMP in the forwarding architecture or
tools that don't support ECMP as deficient, then we have already
reached compromise.  I thought that was the compromise that had been
suggested earlier.  If you agree that this is a reasonable compromise,
then we can move forward.

If not, I suggest that we both be quiet for a while and see what
consensus comes out of the WG.  I'll do my part (and be silent).

Curtis



From owner-mpls@UU.NET  Wed Nov 19 17:08: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 RAA17955
	for <mpls-archive@lists.ietf.org>; Wed, 19 Nov 2003 17:08: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 QQppns08837
	for <mpls-archive@lists.ietf.org>; Wed, 19 Nov 2003 22:08: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 QQppns08701;
	Wed, 19 Nov 2003 22:08:46 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppnq12228
	for mpls-outgoing; Wed, 19 Nov 2003 21:43: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 QQppnq12215
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Nov 2003 21:43:40 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 QQppnq05732
	for <mpls@UU.NET>; Wed, 19 Nov 2003 21:41: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 QQppnq25796
	for <mpls@UU.NET>; Wed, 19 Nov 2003 21:41:08 GMT
Received: from mxsf27.cluster1.charter.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mxsf27.cluster1.charter.net [209.225.28.227])
	id QQppnq25785
	for <mpls@UU.NET>; Wed, 19 Nov 2003 21:41:08 GMT
Received: from interflect.com (ts46-01-qdr3166.mrgnhll.ca.charter.com [68.118.70.100])
	by mxsf27.cluster1.charter.net (8.12.10/8.12.8) with ESMTP id hAJLUMP6089360;
	Wed, 19 Nov 2003 16:30:23 -0500 (EST)
	(envelope-from mark@interflect.com)
Message-ID: <3FBBE0F1.4010007@interflect.com>
Date: Wed, 19 Nov 2003 13:30:25 -0800
From: mark seery <mark@interflect.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
CC: mpls@UU.NET
Subject: OT: BOIDS (was Re: on documenting ECMP (was on the mpls oam framework))
References: <B99995113B318D44BBE87DC50092EDA90C0D5500@nj7460exch006u.ho.lucent.com>
In-Reply-To: <B99995113B318D44BBE87DC50092EDA90C0D5500@nj7460exch006u.ho.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

Busschbach, Peter B (Peter) wrote:

>(large snipping license follows - apologies in advance)......non-determinism is a powerful concept and that a program should be written in such a way that its correctness can be proven, even in the face of non-determinism..........is it really crucial to know exactly how traffic is routed? Shouldn't we just embrace non-determinism for the advantages that it provides and find ways to work around it?
>
Way OT in to the theoretical, but.................

Peter, I think your instinct that there is a philisophical/paradigm 
disconect is true, of which many would agree. I understand why you took 
the determinism route (as determinism was previously raised), but I 
don't think determinism fully explains the issue.

You may have heard of the famous computer simulation by Craig Reynolds 
(http://www.red3d.com/cwr/boids) that involved "boids" - artificial life 
birds. In one model, boids were given three simple rules: maintain a 
minimum distance from other objects, try to match velocity with other 
boids in the neighborhood, try to move towards the perceived center of 
mass of boids in the neighborhood. In one of the runs, a boid hit a 
pole, it bounced off, the other boids flew around the pole, and then all 
the boids self-organized back in to the flock formation they were 
previously in. There was not one line of code in the simulation 
directing the boids what to do if they hit a pole. From this observation 
people have inferred that in protocols, and by extension networks, you 
can not anticipate all the potential problems, and that by trying to do 
so makes the system inherently less robust; and that a better approach 
is to program rules that will lead to self-organization, and perhaps 
even one day emergent behavior. So in dynamic routing, we see yet 
another human endeavor searching for the essence of intelligence. This, 
combined with the social and technological trends of the 70's and 80's 
that highlighted the limitations of hierarchy, have combined to create a 
powerful force within our industry.

So I would observe the behavior of the boids were determinstic (not 
randomly selected choice as in some genetic algorithms of trial and 
error). But the real "life preserver" issue to which Kireeti referred is 
not whether to trust in non-determinism, but whether to trust the 
inherent intelligence of the network, and the simple rules (some of 
which Kireeti has enumerated) which we use to make sure our 
(packets)boids react when they hit their respective poles. It is the 
difference between whether you believe you can enumerate all the 
potential fault conditions or not, and whether you are willing to pay 
the price for accounting for them. It is the difference between whether 
you think intelligence lives purely in the control plane, of whether you 
think it lives in the data and management planes as well.

No doubt our respective operational experiences inform us on this and 
other issues, which of course is one of the dividing lines, and why the 
compromise of applicability seems so important.

As it is said that science often works more by metaphor than deduction 
than people believe, the search for a metaphor is good - finding the 
right one is extremely hard. It is also fair to observe that most major 
standards bodies (IEEE, IETF, ITU, ATM Forum, ANSI) are most comfortable 
with one metaphor, everything else has the potential to be an irritation 
in the oyster which produces a pearl, but often that is not the case. 
The inherent problem with MPLS is that it has the potential to confuse 
people about which metaphor is being pursued, but this thread does not 
lead much doubt (IMO) - though even within the IETF/IP community that is 
sometimes debated (adding to the confusion).

This is not anywhere near the entire story, but thought your comment 
deserved a considered response.

Best,
mark

p.s. it was constructive and worthwhile of Tom to add that even with 
MPLS there are options.



From owner-mpls@UU.NET  Thu Nov 20 02:27: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 CAA20506
	for <mpls-archive@lists.ietf.org>; Thu, 20 Nov 2003 02:27:30 -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 QQpppd10592
	for <mpls-archive@lists.ietf.org>; Thu, 20 Nov 2003 07:27:40 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 QQpppd10432;
	Thu, 20 Nov 2003 07:27:33 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpppc10142
	for mpls-outgoing; Thu, 20 Nov 2003 07:11: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 QQpppc10068
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 20 Nov 2003 07:11: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 QQpppc04553
	for <mpls@UU.NET>; Thu, 20 Nov 2003 07:10:07 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 QQpppc20818
	for <mpls@UU.NET>; Thu, 20 Nov 2003 07:10:06 GMT
Received: from i2kc04-ukbr.domain1.systemhost.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp4.smtp.bt.com [217.32.164.151])
	id QQpppc20800
	for <mpls@UU.NET>; Thu, 20 Nov 2003 07:10:06 GMT
Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 20 Nov 2003 07:10:05 +0000
Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 20 Nov 2003 07:10:05 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: mp2p with ECMP (was on documenting ECMP (was on the mpls oam framework))
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Date: Thu, 20 Nov 2003 07:10:04 -0000
Message-ID: <0536FC9B908BEC4597EE721BE6A3538904EF2E6F@i2km07-ukbr.domain1.systemhost.net>
Thread-Topic: on documenting ECMP (was on the mpls oam framework)
Thread-Index: AcOuudcnzHY5H4TXSkyrJEpaF05iVgAGfW6w
To: <mpls@UU.NET>
X-OriginalArrivalTime: 20 Nov 2003 07:10:05.0239 (UTC) FILETIME=[52B77C70:01C3AF35]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Can someone please explain to me the purpose of having a standardised =
MPLS layer mp2p construct with proprietary ECMP?  The former is a co-ps =
mode server layer consruct which is causing *traffic convergence* of its =
clients, whilst the latter is doing its best to ensure *traffic =
divergence* of its clients.  In terms of control/determinism this would =
seem to undermine the routing role of the mp2p server layer =
construct......but I'll bet some people also do it with p2p TE LSPs =
(which, if true, would seem to completely undermine their purpose).   =
That is, if I removed the mp2p server layer then the actual traffic =
distribution of the clients would not be affected......so exactly what =
was the point of doing it in the 1st place (other than creating a new =
and rich set of network problems to address, eg OAM and fault =
management, traffic, performance). =20

Further thought.....just how does all the above fit in with TE DS =
classes and the notion of constraining routing? =20

BTW - just in case anyone is wondering.  I still firmly stand by the =
observations that a mp2p consruct and PHP are violations of the co-ps =
mode.  Nothing can change that view as its simply true.

regards, Neil


From owner-mpls@UU.NET  Thu Nov 20 10:16: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 KAA08686
	for <mpls-archive@lists.ietf.org>; Thu, 20 Nov 2003 10:16:09 -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 QQppqj01742
	for <mpls-archive@lists.ietf.org>; Thu, 20 Nov 2003 15: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 QQppqj01447;
	Thu, 20 Nov 2003 15:16:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppqh03204
	for mpls-outgoing; Thu, 20 Nov 2003 14:56: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 QQppqh03199
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 20 Nov 2003 14:56: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 QQppqh07230
	for <mpls@uu.net>; Thu, 20 Nov 2003 14:55: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 QQppqh00013
	for <mpls@uu.net>; Thu, 20 Nov 2003 14:55:19 GMT
Received: from sj-iport-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72])
	id QQppqh00008
	for <mpls@uu.net>; Thu, 20 Nov 2003 14:55:18 GMT
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-3.cisco.com with ESMTP; 20 Nov 2003 06:55:51 +0000
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAKEtEAt023430
	for <mpls@uu.net>; Thu, 20 Nov 2003 06:55:14 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AED20747;
	Thu, 20 Nov 2003 09:55:13 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAKEtDR24161 for mpls@uu.net; Thu, 20 Nov 2003 09:55:13 -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 QQppqe27143
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 20 Nov 2003 14:04:13 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 QQppqe16961
	for <mpls@UU.NET>; Thu, 20 Nov 2003 14:02: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 QQppqe28907
	for <mpls@UU.NET>; Thu, 20 Nov 2003 14:02:14 GMT
Received: from smtp.apricot.ocn.ne.jp by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: apricot.ocn.ne.jp [211.6.83.52])
	id QQppqe28879
	for <mpls@UU.NET>; Thu, 20 Nov 2003 14:02:13 GMT
Received: from [127.0.0.1] (dhcp64-134-134-157.spa.phx.wayport.net [64.134.134.157])
	by smtp.apricot.ocn.ne.jp (Postfix) with ESMTP
	id 914F1109; Thu, 20 Nov 2003 23:02:10 +0900 (JST)
Date: Thu, 20 Nov 2003 23:12:52 +0900
From: Seisho Yasukawa <seisho-yasukawa@apricot.ocn.ne.jp>
To: "Adrian Farrel" <adrian@olddog.co.uk>, mplswg@yahoo.com
Subject: Re: About the P2MP scalability
Cc: "'mpls@uu.net'" <mpls@UU.NET>, yasukawa.seisho@lab.ntt.co.jp
In-Reply-To: <056101c3add9$02995ea0$db818182@Puppy>
References: <056101c3add9$02995ea0$db818182@Puppy>
Message-Id: <20031120231224.514B.SEISHO-YASUKAWA@apricot.ocn.ne.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.07.01
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Melvin and Adrian,

Yes, I agree with Adrian.
Scalability is an important requirement for p2mp becuase
some p2mp typical service scenario require a lot of p2mp lsp
setup in the core with large number of leaf nodes.
And we hope this is clearly expressed in the requirements draft.

There are at least four aspects of scaling that we must cover

  1. The number of protocol messages needed to set up the full p2mp
     tree, or to recover the tree after failure.
  2. The size of the protocol messages
  3. Sharing of resources between flows for the same p2mp tree
  4. The amount of Path and Resv state required to support the p2mp
     tree when it passes through one LSR.

The solutions will need to resolve these issues.

Cheers,

Seisho

> Hi Melvin,
> 
> Thanks for both of your emails on this subject.
> 
> > Sir, I have several questions to ask:
> > 1) how can we implement the P2MP in the non-packet network?
> > 2) can we have some method to solve the scalability problem in P2MP
> >     implementation?
> > 3) Can we not to put the PE1 from the sender node in the edge-node,
> >      but in the inner node in the mpls domain? I think it could enhance
> >      the scalability. Although I know we always put these functions on
> >      the edge node.
> >
> >  Hope your reply.
> 
> It is the intention of draft-yasukawa-mpls-p2mp-requirement-01.txt to make sure that any
> p2mp solution developed in the MPLS WG should be applicable to other switching types (i.e.
> non-packet).
> 
> Scalability is, of course, a significant concern.
> draft-yasukawa-mpls-p2mp-requirement-01.txt describes networks where the branch points are
> within the network and not at the edges. Scaling issues are mentioned at many points in
> the draft.
> 
> There are currently two proposed solutions drafts (it is to be hoped that these may
> converge on a single solution over time). Both proposed solutions take some pains to
> ensure optimal use of network resources. Both solutions currently have some scaling issues
> within the control plane, but I'm sure the authors are working to resolve these issues.
> 
> Cheers,
> Adrian

-- 
seisho yasukawa <seisho-yasukawa@apricot.ocn.ne.jp>




From owner-mpls@UU.NET  Thu Nov 20 12:52: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 MAA15451
	for <mpls-archive@lists.ietf.org>; Thu, 20 Nov 2003 12:52:45 -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 QQppqt27854
	for <mpls-archive@lists.ietf.org>; Thu, 20 Nov 2003 17:52: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 QQppqt27652;
	Thu, 20 Nov 2003 17:52:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppqs14728
	for mpls-outgoing; Thu, 20 Nov 2003 17:38:29 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 QQppqs14721
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 20 Nov 2003 17:38: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 QQppqs10893
	for <mpls@uu.net>; Thu, 20 Nov 2003 17:37: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 QQppqs05704
	for <mpls@uu.net>; Thu, 20 Nov 2003 17:37:39 GMT
Received: from sj-iport-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71])
	id QQppqs05660
	for <mpls@uu.net>; Thu, 20 Nov 2003 17:37:38 GMT
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-2.cisco.com with ESMTP; 20 Nov 2003 09:38:00 +0000
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAKHbZjq018948
	for <mpls@uu.net>; Thu, 20 Nov 2003 09:37:35 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AED37034;
	Thu, 20 Nov 2003 12:37:34 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAKHbXJ27731 for mpls@uu.net; Thu, 20 Nov 2003 12:37:33 -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 QQppqq26442
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 20 Nov 2003 17:00: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 QQppqq19721
	for <mpls@uu.net>; Thu, 20 Nov 2003 17:00:11 GMT
From: AtrJoh@netscape.net
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQppqq25536
	for <mpls@uu.net>; Thu, 20 Nov 2003 17:00:11 GMT
Received: from imo-d02.mx.aol.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imo-d02.mx.aol.com [205.188.157.34])
	id QQppqq25521
	for <mpls@uu.net>; Thu, 20 Nov 2003 17:00:10 GMT
Received: from AtrJoh@netscape.net
	by imo-d02.mx.aol.com (mail_out_v36_r1.1.) id 1.c2.a6f63c6 (16238)
	 for <mpls@uu.net>; Thu, 20 Nov 2003 12:00:04 -0500 (EST)
Received: from  netscape.net (mow-d17.webmail.aol.com [205.188.139.133]) by air-in03.mx.aol.com (v97.8) with ESMTP id MAILININ32-3f6e3fbcf314360; Thu, 20 Nov 2003 12:00:04 -0500
Date: Thu, 20 Nov 2003 12:00:04 -0500
To: mpls@UU.NET
Subject: Fast Reroute - local revertive
MIME-Version: 1.0
Message-ID: <40016D30.3EBC075A.00047620@netscape.net>
X-Mailer: Atlas Mailer 2.0
X-AOL-IP: 62.90.130.2
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit

I have a question regarding the local revertive behavior (section 6.5.2 fast reroute draft). The draft says: "Interoperability: If a PLR is configured with the local revertive mode but the MP is not, any attempt from the PLR to resignal the TELSP over the restored resource would fail as the MP will not send any Resv message...".
Why the MP won't send the RESV message? 

__________________________________________________________________
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455



From owner-mpls@UU.NET  Thu Nov 20 15:51:43 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 PAA25317
	for <mpls-archive@lists.ietf.org>; Thu, 20 Nov 2003 15:51: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 QQpprf17771
	for <mpls-archive@lists.ietf.org>; Thu, 20 Nov 2003 20:51: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 QQpprf17142;
	Thu, 20 Nov 2003 20:51:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQppre26990
	for mpls-outgoing; Thu, 20 Nov 2003 20:34:09 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 QQppre26985
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 20 Nov 2003 20:34:08 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 QQppre12666
	for <mpls@uu.net>; Thu, 20 Nov 2003 20:32: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 QQppre27413
	for <mpls@uu.net>; Thu, 20 Nov 2003 20:32:23 GMT
Received: from sj-iport-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71])
	id QQppre27399
	for <mpls@uu.net>; Thu, 20 Nov 2003 20:32:22 GMT
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-2.cisco.com with ESMTP; 20 Nov 2003 12:32:43 +0000
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAKKWGw5004078
	for <mpls@uu.net>; Thu, 20 Nov 2003 12:32:17 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AED55445;
	Thu, 20 Nov 2003 15:32:16 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAKKWF902319 for mpls@uu.net; Thu, 20 Nov 2003 15:32:15 -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 QQppre26717
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 20 Nov 2003 20:30: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 QQpprd04827
	for <mpls@uu.net>; Thu, 20 Nov 2003 20:29: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 QQpprd28053
	for <mpls@uu.net>; Thu, 20 Nov 2003 20:29:30 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 QQpprd28025
	for <mpls@uu.net>; Thu, 20 Nov 2003 20:29:29 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24135;
	Thu, 20 Nov 2003 15:29:15 -0500 (EST)
Message-Id: <200311202029.PAA24135@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-ldp-mib-14.txt
Date: Thu, 20 Nov 2003 15:29:15 -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		: Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP)
	Author(s)	: J. Cucchiara, H. Sjostrand, J. Luciani
	Filename	: draft-ietf-mpls-ldp-mib-14.txt
	Pages		: 132
	Date		: 2003-11-20
	
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects for the Multiprotocol
Label Switching, Label Distribution Protocol (LDP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-mib-14.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-ldp-mib-14.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-ldp-mib-14.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-11-20154429.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-ldp-mib-14.txt

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Sun Nov 23 18:24: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 SAA04213
	for <mpls-archive@lists.ietf.org>; Sun, 23 Nov 2003 18:24: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 QQpqcr06212
	for <mpls-archive@lists.ietf.org>; Sun, 23 Nov 2003 23:24:49 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 QQpqcr05918;
	Sun, 23 Nov 2003 23:24:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqcq26056
	for mpls-outgoing; Sun, 23 Nov 2003 23:05: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 QQpqcq26025
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 23 Nov 2003 23:05:37 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 QQpqcq15807
	for <mpls@UU.NET>; Sun, 23 Nov 2003 23:04: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 QQpqcq18866
	for <mpls@UU.NET>; Sun, 23 Nov 2003 23:04:37 GMT
Received: from smtp4.hy.skanova.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp4.hy.skanova.net [195.67.199.133])
	id QQpqcq18829
	for <mpls@UU.NET>; Sun, 23 Nov 2003 23:04:36 GMT
Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45])
	by smtp4.hy.skanova.net (8.12.10/8.12.10) with ESMTP id hANN4UBZ007344;
	Mon, 24 Nov 2003 00:04:30 +0100 (CET)
Message-ID: <3FC13CF1.2060802@pi.se>
Date: Mon, 24 Nov 2003 00:04:17 +0100
From: Loa Andersson <loa@pi.se>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MPLS wg <mpls@UU.NET>
CC: George Swallow <swallow@cisco.com>, Alex Zinin <zinin@psg.com>
Subject: draft-yasukawa-mpls-p2mp-requirement-01.txt for working document?
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,

we've been asked to make the

draft-yasukawa-mpls-p2mp-requirement-01.txt

an mpls working group documument. The draft were discussed
in Minneapolis and there were support for making it a working
group document.

Comments?

/Loa


-- 

Loa Andersson

mobile +46 739 81 21 64




From owner-mpls@UU.NET  Sun Nov 23 18:28: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 SAA04308
	for <mpls-archive@lists.ietf.org>; Sun, 23 Nov 2003 18:28: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 QQpqcr21372
	for <mpls-archive@lists.ietf.org>; Sun, 23 Nov 2003 23:28: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 QQpqcr21207;
	Sun, 23 Nov 2003 23:28:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqcq27417
	for mpls-outgoing; Sun, 23 Nov 2003 23:12: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 QQpqcq27410
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 23 Nov 2003 23:12: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 QQpqcq27950
	for <mpls@UU.NET>; Sun, 23 Nov 2003 23:11:53 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 QQpqcq01850
	for <mpls@UU.NET>; Sun, 23 Nov 2003 23:11:53 GMT
Received: from smtp4.hy.skanova.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp4.hy.skanova.net [195.67.199.133])
	id QQpqcq01838
	for <mpls@UU.NET>; Sun, 23 Nov 2003 23:11:52 GMT
Received: from pi.se (h45n1fls31o888.telia.com [213.67.172.45])
	by smtp4.hy.skanova.net (8.12.10/8.12.10) with ESMTP id hANNBkBZ010484;
	Mon, 24 Nov 2003 00:11:46 +0100 (CET)
Message-ID: <3FC13EA6.6030305@pi.se>
Date: Mon, 24 Nov 2003 00:11:34 +0100
From: Loa Andersson <loa@pi.se>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MPLS wg <mpls@UU.NET>
CC: George Swallow <swallow@cisco.com>, Alex Zinin <zinin@psg.com>
Subject: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document
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,

we been asked to make

draft-farrel-mpls-rsvpte-attributes-00.txt

an mpls working document. The document were discussed in
Minneapolis, the room was undecided if we should go
forward with the document. No opposition, but also no
strongly voiced support.

Therefore we would like both those in favor and those
opposed to making this a working group document to
speak up.

/Loa

-- 

Loa Andersson

mobile +46 739 81 21 64




From owner-mpls@UU.NET  Mon Nov 24 12:26: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 MAA17407
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 12:26: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 QQpqfl20750
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 17:26: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 QQpqfl20441;
	Mon, 24 Nov 2003 17:26:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqfk10098
	for mpls-outgoing; Mon, 24 Nov 2003 17:06:15 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 QQpqfk09994
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Nov 2003 17:06:05 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 QQpqfk06536
	for <MPLS@UU.NET>; Mon, 24 Nov 2003 17:04: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 QQpqfk14848
	for <MPLS@UU.NET>; Mon, 24 Nov 2003 17:04:31 GMT
Received: from zrtps06s.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zrtps06s.nortelnetworks.com [47.140.48.50])
	id QQpqfk14834
	for <MPLS@UU.NET>; Mon, 24 Nov 2003 17:04:30 GMT
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAOH46L01883;
	Mon, 24 Nov 2003 12:04:06 -0500 (EST)
Received: from zrtpd0jd.us.nortel.com ([47.140.203.31]) by zrtpd0jn.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id WTQH6YPN; Mon, 24 Nov 2003 12:04:06 -0500
Received: from artpt62d.us.nortel.com ([47.140.54.19]) by zrtpd0jd.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id W8T8VJFL; Mon, 24 Nov 2003 12:04:06 -0500
Subject: Re: Fast Reroute - local revertive
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: "Kellermann,Rurick" <rurick@nortelnetworks.com>
To: AtrJoh@netscape.net
Cc: MPLS@UU.NET
In-Reply-To: <28C212F7.429DDA4C.00047620@netscape.net>
References: <28C212F7.429DDA4C.00047620@netscape.net>
Content-Type: text/plain
Message-Id: <1069693392.1963.54.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Mon, 24 Nov 2003 12:03:12 -0500
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Atrjoh,

I still think that the interop. statement of section 6.5.2 refers only
to the fact that both PLR and the MP have to agree on supporting local
revertive in order for the MP to respond to the PLR's attempts to
resignal the TE LSP to the restored TE LSP. Note that the draft says
that this signaling will be done through the backup TE LSP.  

IMO, the other interop. issue is whether / how both modes can be
supported by the MP. The draft says the following:

<< It is recommended that one always use the globally revertive mode.
   Note that a link or node "failure" may be due to the facility being
   permanently taken out of service.  Local revertive mode is
   optional.  When used in combination, the global mode may rely
   solely on timers to do the reoptimization.>> 

If i'm reading this correctly, the MP may respond to the head-end LSR of each tunnel wrt. reoptimizing 
the TE LSPs that used the failed resource. But it can also respond to the PLR's initiative to switch 
the backup LSP to the protected TE LSP, if and only if, the MP and PLR support the local revertive.

Authors, could you please provide some input?

Rurick K.  


On Sun, 2003-11-23 at 02:19, AtrJoh@netscape.net wrote:
> I still didn't understand from your answer why if the MP is configured for 
> global revertive, it will reject the LSP if the PLR will try to resignal it over the restored resource.
> 
> "Kellermann,Rurick" <rurick@nortelnetworks.com> wrote:
> 
> >IMO, it says that both the PLR and the MP have to agree to support local
> >revertive in order for the PLR to be able to resignal the TELSP over the
> >restored resource.
> >
> >If I compare this to the protection behaviour offered by APS, the
> >behaviour is equivalent to NON revertive APS....
> >
> >Rurick Kellermann
> >
> >
> >On Thu, 2003-11-20 at 12:00, AtrJoh@netscape.net wrote:
> >> I have a question regarding the local revertive behavior (section 6.5.2 fast reroute draft). The draft says: "Interoperability: If a PLR is configured with the local revertive mode but the MP is not, any attempt from the PLR to resignal the TELSP over the restored resource would fail as the MP will not send any Resv message...".
> >> Why the MP won't send the RESV message? 
> >> 
> >> __________________________________________________________________
> >> McAfee VirusScan Online from the Netscape Network.
> >> Comprehensive protection for your entire computer. Get your free trial today!
> >> http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397
> >> 
> >> Get AOL Instant Messenger 5.1 free of charge.  Download Now!
> >> http://aim.aol.com/aimnew/Aim/register.adp?promo=380455
> >> 
> >
> >
> 
> __________________________________________________________________
> McAfee VirusScan Online from the Netscape Network.
> Comprehensive protection for your entire computer. Get your free trial today!
> http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397
> 
> Get AOL Instant Messenger 5.1 free of charge.  Download Now!
> http://aim.aol.com/aimnew/Aim/register.adp?promo=380455



From owner-mpls@UU.NET  Mon Nov 24 12:36: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 MAA18039
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 12:36: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 QQpqfm02557
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 17:36: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 QQpqfm02192;
	Mon, 24 Nov 2003 17:36:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqfl12188
	for mpls-outgoing; Mon, 24 Nov 2003 17:18: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 QQpqfl12177
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Nov 2003 17:18: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 QQpqfl07271
	for <mpls@UU.NET>; Mon, 24 Nov 2003 17:17: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 QQpqfl07081
	for <mpls@UU.NET>; Mon, 24 Nov 2003 17:17:41 GMT
Received: from kummer.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint2.juniper.net [207.17.136.150])
	id QQpqfl07060
	for <mpls@UU.NET>; Mon, 24 Nov 2003 17:17:40 GMT
Received: from kummer.juniper.net (localhost [127.0.0.1])
	by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id hAOHGBda010963;
	Mon, 24 Nov 2003 09:16:11 -0800 (PST)
	(envelope-from kireeti@juniper.net)
Received: from localhost (kireeti@localhost)
	by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id hAOHGB5L010960;
	Mon, 24 Nov 2003 09:16:11 -0800 (PST)
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
Date: Mon, 24 Nov 2003 09:16:11 -0800 (PST)
From: Kireeti Kompella <kireeti@juniper.net>
To: Loa Andersson <loa@pi.se>
cc: MPLS wg <mpls@UU.NET>, George Swallow <swallow@cisco.com>,
        Alex Zinin <zinin@psg.com>
Subject: Re: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document
In-Reply-To: <3FC13EA6.6030305@pi.se>
Message-ID: <20031124090918.J10907@kummer.juniper.net>
References: <3FC13EA6.6030305@pi.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Mon, 24 Nov 2003, Loa Andersson wrote:

> we been asked to make
>
> draft-farrel-mpls-rsvpte-attributes-00.txt
>
> an mpls working document.

Ja, det ar mycket bra.

Kireeti.
-------


From owner-mpls@UU.NET  Mon Nov 24 12:43: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 MAA18432
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 12:43:26 -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 QQpqfm11907
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 17:43:40 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 QQpqfm11780;
	Mon, 24 Nov 2003 17:43:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqfl12880
	for mpls-outgoing; Mon, 24 Nov 2003 17:26: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 QQpqfl12685
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Nov 2003 17:25: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 QQpqfl09106
	for <mpls@uu.net>; Mon, 24 Nov 2003 17:25: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 QQpqfl18664
	for <mpls@uu.net>; Mon, 24 Nov 2003 17:25:10 GMT
Received: from sj-iport-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70])
	id QQpqfl18648
	for <mpls@uu.net>; Mon, 24 Nov 2003 17:25:09 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAOHP6w5018905
	for <mpls@uu.net>; Mon, 24 Nov 2003 09:25:06 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEF26188;
	Mon, 24 Nov 2003 12:25:05 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAOHP4J26576 for mpls@uu.net; Mon, 24 Nov 2003 12:25: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 QQpqaf04179
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 23 Nov 2003 07:20:07 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 QQpqaf22613
	for <mpls@uu.net>; Sun, 23 Nov 2003 07:19:40 GMT
From: AtrJoh@netscape.net
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQpqaf14660
	for <mpls@uu.net>; Sun, 23 Nov 2003 07:19:39 GMT
Received: from imo-d01.mx.aol.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imo-d01.mx.aol.com [205.188.157.33])
	id QQpqaf14646
	for <mpls@uu.net>; Sun, 23 Nov 2003 07:19:39 GMT
Received: from AtrJoh@netscape.net
	by imo-d01.mx.aol.com (mail_out_v36_r1.1.) id d.10a.a5d9f45 (22681);
	Sun, 23 Nov 2003 02:19:27 -0500 (EST)
Received: from  netscape.net (mow-d15.webmail.aol.com [205.188.139.131]) by air-in04.mx.aol.com (v97.8) with ESMTP id MAILININ42-58993fc05f7f281; Sun, 23 Nov 2003 02:19:27 -0500
Date: Sun, 23 Nov 2003 02:19:27 -0500
To: rurick@nortelnetworks.com ("Kellermann,Rurick")
Cc: mpls@UU.NET
Subject: Re: Fast Reroute - local revertive
MIME-Version: 1.0
Message-ID: <28C212F7.429DDA4C.00047620@netscape.net>
X-Mailer: Atlas Mailer 2.0
X-AOL-IP: 62.90.130.2
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit

I still didn't understand from your answer why if the MP is configured for 
global revertive, it will reject the LSP if the PLR will try to resignal it over the restored resource.

"Kellermann,Rurick" <rurick@nortelnetworks.com> wrote:

>IMO, it says that both the PLR and the MP have to agree to support local
>revertive in order for the PLR to be able to resignal the TELSP over the
>restored resource.
>
>If I compare this to the protection behaviour offered by APS, the
>behaviour is equivalent to NON revertive APS....
>
>Rurick Kellermann
>
>
>On Thu, 2003-11-20 at 12:00, AtrJoh@netscape.net wrote:
>> I have a question regarding the local revertive behavior (section 6.5.2 fast reroute draft). The draft says: "Interoperability: If a PLR is configured with the local revertive mode but the MP is not, any attempt from the PLR to resignal the TELSP over the restored resource would fail as the MP will not send any Resv message...".
>> Why the MP won't send the RESV message? 
>> 
>> __________________________________________________________________
>> McAfee VirusScan Online from the Netscape Network.
>> Comprehensive protection for your entire computer. Get your free trial today!
>> http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397
>> 
>> Get AOL Instant Messenger 5.1 free of charge.  Download Now!
>> http://aim.aol.com/aimnew/Aim/register.adp?promo=380455
>> 
>
>

__________________________________________________________________
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455



From owner-mpls@UU.NET  Mon Nov 24 13:24: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 NAA19874
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 13:24: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 QQpqfp08474
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 18:24: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 QQpqfp08322;
	Mon, 24 Nov 2003 18:24:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqfo04901
	for mpls-outgoing; Mon, 24 Nov 2003 18:06: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 QQpqfo04883
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Nov 2003 18:06: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 QQpqfo28968
	for <mpls@uu.net>; Mon, 24 Nov 2003 18:02: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 QQpqfo04649
	for <mpls@uu.net>; Mon, 24 Nov 2003 18:02:26 GMT
Received: from sj-iport-3.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72])
	id QQpqfo04636
	for <mpls@uu.net>; Mon, 24 Nov 2003 18:02:26 GMT
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-3.cisco.com with ESMTP; 24 Nov 2003 10:03:47 +0000
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAOI2MAt029091
	for <mpls@uu.net>; Mon, 24 Nov 2003 10:02:22 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEF30095;
	Mon, 24 Nov 2003 13:02:21 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAOI2Lo00272 for mpls@uu.net; Mon, 24 Nov 2003 13:02:21 -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 QQpqfo26614
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Nov 2003 18:01: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 QQpqfn22878
	for <mpls@uu.net>; Mon, 24 Nov 2003 17:54: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 QQpqfn24253
	for <mpls@uu.net>; Mon, 24 Nov 2003 17:54:01 GMT
Received: from sj-iport-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71])
	id QQpqfn24244
	for <mpls@uu.net>; Mon, 24 Nov 2003 17:54:00 GMT
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-2.cisco.com with ESMTP; 24 Nov 2003 09:55:09 +0000
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAOHrvw5017940;
	Mon, 24 Nov 2003 09:53:57 -0800 (PST)
Received: from jvasseur-w2k01.cisco.com (dhcp-10-86-162-191.cisco.com [10.86.162.191]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA13418; Mon, 24 Nov 2003 09:53:56 -0800 (PST)
Message-Id: <4.3.2.7.2.20031124125337.048dc3d0@wells.cisco.com>
X-Sender: jvasseur@wells.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 24 Nov 2003 12:53:55 -0500
To: Kireeti Kompella <kireeti@juniper.net>
From: Jean Philippe Vasseur <jvasseur@cisco.com>
Subject: Re: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document
Cc: Loa Andersson <loa@pi.se>, MPLS wg <mpls@UU.NET>,
        George Swallow <swallow@cisco.com>, Alex Zinin <zinin@psg.com>
In-Reply-To: <20031124090918.J10907@kummer.juniper.net>
References: <3FC13EA6.6030305@pi.se>
 <3FC13EA6.6030305@pi.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 09:16 AM 11/24/2003 -0800, Kireeti Kompella wrote:
>On Mon, 24 Nov 2003, Loa Andersson wrote:
>
> > we been asked to make
> >
> > draft-farrel-mpls-rsvpte-attributes-00.txt
> >
> > an mpls working document.
>
>Ja, det ar mycket bra.

merci de ton support Kireeti. A bientot.

JP.

>Kireeti.
>-------



From owner-mpls@UU.NET  Mon Nov 24 13:52: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 NAA21109
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 13:52: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 QQpqfr02370
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 18:52: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 QQpqfr02165;
	Mon, 24 Nov 2003 18:52:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqfq08224
	for mpls-outgoing; Mon, 24 Nov 2003 18:34: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 QQpqfq08217
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Nov 2003 18:34:17 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 QQpqfq22326
	for <mpls@uu.net>; Mon, 24 Nov 2003 18:32: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 QQpqfq00631
	for <mpls@uu.net>; Mon, 24 Nov 2003 18:32:49 GMT
Received: from sj-iport-4.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-4.cisco.com [171.68.10.86])
	id QQpqfq00614
	for <mpls@uu.net>; Mon, 24 Nov 2003 18:32:49 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAOIWjxg029168
	for <mpls@uu.net>; Mon, 24 Nov 2003 13:32:45 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEF33654;
	Mon, 24 Nov 2003 13:32:44 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAOIWiq03113 for mpls@uu.net; Mon, 24 Nov 2003 13:32:44 -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 QQpqfo05088
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Nov 2003 18:08: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 QQpqfo04717
	for <mpls@UU.NET>; Mon, 24 Nov 2003 18:06: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 QQpqfo22410
	for <mpls@UU.NET>; Mon, 24 Nov 2003 18:06:10 GMT
Received: from relay0.netfirms.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: m0.netfirms.com [209.171.43.51])
	id QQpqfo22391
	for <mpls@UU.NET>; Mon, 24 Nov 2003 18:06:10 GMT
Received: (qmail 82419 invoked from network); 24 Nov 2003 18:05:43 -0000
Received: from du-069-0780.access.clara.net (HELO Puppy) (217.158.170.17)
  by 0 with SMTP; 24 Nov 2003 18:05:43 -0000
Message-ID: <08f801c3b2b5$9ad486f0$db818182@Puppy>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: draft-yasukawa-mpls-p2mp-requirement-01.txt for working document?
Date: Mon, 24 Nov 2003 18:02:23 -0000
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.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

I support.
Adrian

> All,
>
> we've been asked to make the
>
> draft-yasukawa-mpls-p2mp-requirement-01.txt
>
> an mpls working group documument. The draft were discussed
> in Minneapolis and there were support for making it a working
> group document.
>
> Comments?




From owner-mpls@UU.NET  Mon Nov 24 14:22: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 OAA22729
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 14:22: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 QQpqft15250
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 19:22: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 QQpqft15000;
	Mon, 24 Nov 2003 19:22:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqfs14392
	for mpls-outgoing; Mon, 24 Nov 2003 19:00: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 QQpqfs14346
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Nov 2003 19:00:30 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 QQpqfr21445
	for <mpls@UU.NET>; Mon, 24 Nov 2003 18:56: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 QQpqfr08367
	for <mpls@UU.NET>; Mon, 24 Nov 2003 18:56:36 GMT
Received: from hs22.order-vault.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hs22.order-vault.net [65.18.133.138])
	id QQpqfr08353
	for <mpls@UU.NET>; Mon, 24 Nov 2003 18:56:36 GMT
Received: from lb-laptop.labn.net (labn.net [65.18.134.4])
	(authenticated (0 bits))
	by hs22.order-vault.net (8.11.6/8.11.6) with ESMTP id hAOIuWj26401;
	Mon, 24 Nov 2003 13:56:32 -0500
Message-Id: <4.3.2.7.2.20031124135438.028aa368@mail.labn.net>
X-Sender: lberger@mail.labn.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 24 Nov 2003 13:56:33 -0500
To: Loa Andersson <loa@pi.se>
From: Lou Berger <lberger@labn.net>
Subject: Re: draft-yasukawa-mpls-p2mp-requirement-01.txt for working
  document?
Cc: MPLS wg <mpls@UU.NET>, George Swallow <swallow@cisco.com>,
        Alex Zinin <zinin@psg.com>
In-Reply-To: <3FC13CF1.2060802@pi.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


I support making it a working group document.  I think it's consistent with 
WG P2MP-TE milestone.

Lou


At 06:04 PM 11/23/2003, Loa Andersson wrote:
>All,
>
>we've been asked to make the
>
>draft-yasukawa-mpls-p2mp-requirement-01.txt
>
>an mpls working group documument. The draft were discussed
>in Minneapolis and there were support for making it a working
>group document.
>
>Comments?
>
>/Loa
>
>
>--
>
>Loa Andersson
>
>mobile +46 739 81 21 64



From owner-mpls@UU.NET  Mon Nov 24 14:22:15 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 OAA22745
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 14:22:15 -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 QQpqft15325
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 19:22: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 QQpqft15035;
	Mon, 24 Nov 2003 19:22:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqfs14483
	for mpls-outgoing; Mon, 24 Nov 2003 19:00: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 QQpqfs14360
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Nov 2003 19:00:31 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 QQpqfr24681
	for <mpls@UU.NET>; Mon, 24 Nov 2003 18:58: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 QQpqfr14041
	for <mpls@UU.NET>; Mon, 24 Nov 2003 18:58:44 GMT
Received: from hs22.order-vault.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hs22.order-vault.net [65.18.133.138])
	id QQpqfr14024
	for <mpls@UU.NET>; Mon, 24 Nov 2003 18:58:43 GMT
Received: from lb-laptop.labn.net (labn.net [65.18.134.4])
	(authenticated (0 bits))
	by hs22.order-vault.net (8.11.6/8.11.6) with ESMTP id hAOIwej26728;
	Mon, 24 Nov 2003 13:58:40 -0500
Message-Id: <4.3.2.7.2.20031124135814.0b03c5a0@mail.labn.net>
X-Sender: lberger@mail.labn.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 24 Nov 2003 13:58:40 -0500
To: Loa Andersson <loa@pi.se>
From: Lou Berger <lberger@labn.net>
Subject: Re: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document
Cc: MPLS wg <mpls@UU.NET>, George Swallow <swallow@cisco.com>,
        Alex Zinin <zinin@psg.com>
In-Reply-To: <3FC13EA6.6030305@pi.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

In favor...

At 06:11 PM 11/23/2003, Loa Andersson wrote:
>All,
>
>we been asked to make
>
>draft-farrel-mpls-rsvpte-attributes-00.txt
>
>an mpls working document. The document were discussed in
>Minneapolis, the room was undecided if we should go
>forward with the document. No opposition, but also no
>strongly voiced support.
>
>Therefore we would like both those in favor and those
>opposed to making this a working group document to
>speak up.
>
>/Loa
>
>--
>
>Loa Andersson
>
>mobile +46 739 81 21 64



From owner-mpls@UU.NET  Mon Nov 24 14:40: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 OAA23619
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 14:40: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 QQpqfu14623
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 19: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 QQpqfu14462;
	Mon, 24 Nov 2003 19:40:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqft01819
	for mpls-outgoing; Mon, 24 Nov 2003 19:23:55 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 QQpqft01809
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Nov 2003 19:23:43 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 QQpqft06703
	for <mpls@UU.NET>; Mon, 24 Nov 2003 19:19: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 QQpqft14422
	for <mpls@UU.NET>; Mon, 24 Nov 2003 19:19:57 GMT
Received: from colo-dns-ext1.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: colo-dns-ext1.juniper.net [207.17.137.57])
	id QQpqft14402
	for <mpls@UU.NET>; Mon, 24 Nov 2003 19:19:56 GMT
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id hAOJIZl87107;
	Mon, 24 Nov 2003 11:18:35 -0800 (PST)
	(envelope-from arthi@juniper.net)
Received: from zircon.juniper.net (zircon.juniper.net [172.17.28.113])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id hAOJIUX98547;
	Mon, 24 Nov 2003 11:18:30 -0800 (PST)
	(envelope-from arthi@juniper.net)
Date: Mon, 24 Nov 2003 11:18:30 -0800 (PST)
From: Arthi Ayyangar <arthi@juniper.net>
To: Loa Andersson <loa@pi.se>
cc: MPLS wg <mpls@UU.NET>, George Swallow <swallow@cisco.com>,
        Alex Zinin <zinin@psg.com>
Subject: Re: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document
In-Reply-To: <3FC13EA6.6030305@pi.se>
Message-ID: <20031124101845.Y84830@zircon.juniper.net>
References: <3FC13EA6.6030305@pi.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

In favor.

-arthi

> we been asked to make
>
> draft-farrel-mpls-rsvpte-attributes-00.txt
>
> an mpls working document. The document were discussed in
> Minneapolis, the room was undecided if we should go
> forward with the document. No opposition, but also no
> strongly voiced support.
>
> Therefore we would like both those in favor and those
> opposed to making this a working group document to
> speak up.
>
> /Loa
>
> --
>
> Loa Andersson
>
> mobile +46 739 81 21 64
>
>


From owner-mpls@UU.NET  Mon Nov 24 15:14: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 PAA26055
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 15:14: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 QQpqfw25439
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 20:14: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 QQpqfw22810;
	Mon, 24 Nov 2003 20:13:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqfv04383
	for mpls-outgoing; Mon, 24 Nov 2003 19:55: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 QQpqfv04378
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Nov 2003 19:55: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 QQpqfv28680
	for <mpls@UU.NET>; Mon, 24 Nov 2003 19:45: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 QQpqfv24830
	for <mpls@UU.NET>; Mon, 24 Nov 2003 19:45:55 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 QQpqfv24813
	for <mpls@UU.NET>; Mon, 24 Nov 2003 19:45:55 GMT
Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19)
	id <RHZKNPNQ>; Mon, 24 Nov 2003 11:45:54 -0800
Message-ID: <9D42C6E086250248810DCADA39CE7EFC01048E08@nimbus.chromisys.com>
From: John Drake <jdrake@calient.net>
To: "'Lou Berger'" <lberger@labn.net>, Loa Andersson <loa@pi.se>
Cc: MPLS wg <mpls@UU.NET>, George Swallow <swallow@cisco.com>,
        Alex Zinin
	 <zinin@psg.com>
Subject: RE: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document
Date: Mon, 24 Nov 2003 11:45:53 -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

Ditto

> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Monday, November 24, 2003 10:59 AM
> To: Loa Andersson
> Cc: MPLS wg; George Swallow; Alex Zinin
> Subject: Re: draft-farrel-mpls-rsvpte-attributes-00.txt for 
> wg document
> 
> 
> In favor...
> 
> At 06:11 PM 11/23/2003, Loa Andersson wrote:
> >All,
> >
> >we been asked to make
> >
> >draft-farrel-mpls-rsvpte-attributes-00.txt
> >
> >an mpls working document. The document were discussed in
> >Minneapolis, the room was undecided if we should go
> >forward with the document. No opposition, but also no
> >strongly voiced support.
> >
> >Therefore we would like both those in favor and those
> >opposed to making this a working group document to
> >speak up.
> >
> >/Loa
> >
> >--
> >
> >Loa Andersson
> >
> >mobile +46 739 81 21 64
> 


From owner-mpls@UU.NET  Mon Nov 24 15:30: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 PAA27228
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 15:30: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 QQpqfy27141
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 20:30: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 QQpqfy26848;
	Mon, 24 Nov 2003 20:30:46 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqfw24959
	for mpls-outgoing; Mon, 24 Nov 2003 20:13:47 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 QQpqfw24932
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Nov 2003 20:13: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 QQpqfw22016
	for <mpls@UU.NET>; Mon, 24 Nov 2003 20:09: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 QQpqfw26085
	for <mpls@UU.NET>; Mon, 24 Nov 2003 20:09:28 GMT
Received: from colo-dns-ext1.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: colo-dns-ext1.juniper.net [207.17.137.57])
	id QQpqfw26074
	for <mpls@UU.NET>; Mon, 24 Nov 2003 20:09:27 GMT
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id hAOK9Pl87418;
	Mon, 24 Nov 2003 12:09:25 -0800 (PST)
	(envelope-from rahul@juniper.net)
Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id hAOK85X03301;
	Mon, 24 Nov 2003 12:08:05 -0800 (PST)
	(envelope-from rahul@juniper.net)
Received: from localhost (rahul@localhost)
	by sapphire.juniper.net (8.11.6/8.11.3) with ESMTP id hAOK85e24249;
	Mon, 24 Nov 2003 12:08:05 -0800 (PST)
	(envelope-from rahul@juniper.net)
X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs
Date: Mon, 24 Nov 2003 12:08:05 -0800 (PST)
From: Rahul Aggarwal <rahul@juniper.net>
To: Loa Andersson <loa@pi.se>
cc: MPLS wg <mpls@UU.NET>, George Swallow <swallow@cisco.com>,
        Alex Zinin <zinin@psg.com>
Subject: Re: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document
In-Reply-To: <3FC13EA6.6030305@pi.se>
Message-ID: <20031124120729.X22105@sapphire.juniper.net>
References: <3FC13EA6.6030305@pi.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi Loa,

In support..

rahul

On Mon, 24 Nov 2003, Loa Andersson wrote:

> All,
>
> we been asked to make
>
> draft-farrel-mpls-rsvpte-attributes-00.txt
>
> an mpls working document. The document were discussed in
> Minneapolis, the room was undecided if we should go
> forward with the document. No opposition, but also no
> strongly voiced support.
>
> Therefore we would like both those in favor and those
> opposed to making this a working group document to
> speak up.
>
> /Loa
>
> --
>
> Loa Andersson
>
> mobile +46 739 81 21 64
>
>
>


From owner-mpls@UU.NET  Mon Nov 24 16:02: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 QAA29613
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 16:02: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 QQpqga26308
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 21:03: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 QQpqga26023;
	Mon, 24 Nov 2003 21:03:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqfy27471
	for mpls-outgoing; Mon, 24 Nov 2003 20:41: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 QQpqfy27463
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Nov 2003 20:41: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 QQpqfy29656
	for <mpls@uu.net>; Mon, 24 Nov 2003 20:39: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 QQpqfy08273
	for <mpls@uu.net>; Mon, 24 Nov 2003 20:39:43 GMT
Received: from sj-iport-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71])
	id QQpqfy08261
	for <mpls@uu.net>; Mon, 24 Nov 2003 20:39:43 GMT
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-2.cisco.com with ESMTP; 24 Nov 2003 12:40:53 +0000
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAOKdYw9026905
	for <mpls@uu.net>; Mon, 24 Nov 2003 12:39:40 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEF48098;
	Mon, 24 Nov 2003 15:39:33 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAOKdX409552 for mpls@uu.net; Mon, 24 Nov 2003 15:39:33 -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 QQpqfy27168
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Nov 2003 20:38: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 QQpqfy19297
	for <mpls@uu.net>; Mon, 24 Nov 2003 20:34: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 QQpqfy11542
	for <mpls@uu.net>; Mon, 24 Nov 2003 20:34:23 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 QQpqfy11462
	for <mpls@uu.net>; Mon, 24 Nov 2003 20: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 PAA27867;
	Mon, 24 Nov 2003 15:34:02 -0500 (EST)
Message-Id: <200311242034.PAA27867@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-lsr-mib-14.txt
Date: Mon, 24 Nov 2003 15:34:02 -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) Label Switching 
			  Router (LSR)Management Information Base
	Author(s)	: C. Srinivasan, A. Viswanathan,  . Nadeau
	Filename	: draft-ietf-mpls-lsr-mib-14.txt
	Pages		: 57
	Date		: 2003-11-24
	
This memo defines an portion of the Management
Information Base (MIB) for use with network management protocols
in the Internet community.  In particular, it describes managed
objects to configure and/or monitor a Multi-Protocol Label 
Switching (MPLS) Label Switching Router (LSR).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-14.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-lsr-mib-14.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-lsr-mib-14.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-11-24152821.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-lsr-mib-14.txt

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Mon Nov 24 16:04: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 QAA29734
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 16:04: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 QQpqga00540
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 21:04: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 QQpqga29979;
	Mon, 24 Nov 2003 21:04:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqfy27503
	for mpls-outgoing; Mon, 24 Nov 2003 20:41: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 QQpqfy27487
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Nov 2003 20:41:46 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 QQpqfy22446
	for <mpls@uu.net>; Mon, 24 Nov 2003 20:39:39 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 QQpqfy08194
	for <mpls@uu.net>; Mon, 24 Nov 2003 20:39:39 GMT
Received: from sj-iport-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71])
	id QQpqfy08179
	for <mpls@uu.net>; Mon, 24 Nov 2003 20:39:38 GMT
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-2.cisco.com with ESMTP; 24 Nov 2003 12:40:48 +0000
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAOKdYw5026905
	for <mpls@uu.net>; Mon, 24 Nov 2003 12:39:34 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEF48096;
	Mon, 24 Nov 2003 15:39:32 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAOKdWM09543 for mpls@uu.net; Mon, 24 Nov 2003 15:39:32 -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 QQpqfy27167
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Nov 2003 20:38: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 QQpqfy19349
	for <mpls@uu.net>; Mon, 24 Nov 2003 20:34: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 QQpqfy11580
	for <mpls@uu.net>; Mon, 24 Nov 2003 20:34:24 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 QQpqfy11549
	for <mpls@uu.net>; Mon, 24 Nov 2003 20:34:23 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27880;
	Mon, 24 Nov 2003 15:34:08 -0500 (EST)
Message-Id: <200311242034.PAA27880@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-te-mib-14.txt
Date: Mon, 24 Nov 2003 15:34:08 -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) Traffic 
			  Engineering Management Information Base
	Author(s)	: C. Srinivasan, A. Viswanathan,  . Nadeau
	Filename	: draft-ietf-mpls-te-mib-14.txt
	Pages		: 68
	Date		: 2003-11-24
	
This memo defines a portion of the Management Information
Base  (MIB) for use with network management protocols in
the Internet community.  In particular, it describes
managed objects for Multiprotocol Label Switching (MPLS)
based traffic engineering.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-mib-14.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-te-mib-14.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-te-mib-14.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-11-24152836.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-te-mib-14.txt

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Mon Nov 24 16:04: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 QAA29769
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 16:04: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 QQpqga28409
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 21:04: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 QQpqga28300;
	Mon, 24 Nov 2003 21:04:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqfy27489
	for mpls-outgoing; Mon, 24 Nov 2003 20:41: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 QQpqfy27481
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Nov 2003 20:41: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 QQpqfy22753
	for <mpls@uu.net>; Mon, 24 Nov 2003 20:39:55 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 QQpqfy19349
	for <mpls@uu.net>; Mon, 24 Nov 2003 20:39:54 GMT
Received: from sj-iport-4.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-4.cisco.com [171.68.10.86])
	id QQpqfy19343
	for <mpls@uu.net>; Mon, 24 Nov 2003 20:39:54 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAOKdojq025566
	for <mpls@uu.net>; Mon, 24 Nov 2003 12:39:50 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEF48140;
	Mon, 24 Nov 2003 15:39:49 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAOKdnK09592 for mpls@uu.net; Mon, 24 Nov 2003 15:39: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 QQpqfy27223
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Nov 2003 20:39:06 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 QQpqfy15569
	for <mpls@uu.net>; Mon, 24 Nov 2003 20:32: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 QQpqfy09722
	for <mpls@uu.net>; Mon, 24 Nov 2003 20:32:22 GMT
Received: from sj-iport-5.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-5.cisco.com [171.68.10.87])
	id QQpqfy09711
	for <mpls@uu.net>; Mon, 24 Nov 2003 20:32:21 GMT
Received: from cisco.com (64.102.124.12)
  by sj-iport-5.cisco.com with ESMTP; 24 Nov 2003 12:32:18 -0800
Received: from zaliw2k01 (che-vpn-cluster-1-128.cisco.com [10.86.240.128])
	by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAOKWHxg027384;
	Mon, 24 Nov 2003 15:32:17 -0500 (EST)
From: "zafar ali" <zali@cisco.com>
To: "'Loa Andersson'" <loa@pi.se>, "'MPLS wg'" <mpls@UU.NET>
Cc: "'George Swallow'" <swallow@cisco.com>, "'Alex Zinin'" <zinin@psg.com>
Subject: RE: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document
Date: Mon, 24 Nov 2003 15:32:15 -0500
Organization: Cisco Systems
Message-ID: <001e01c3b2ca$0dd0ee00$0200a8c0@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: <3FC13EA6.6030305@pi.se>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi WG chairs, 

I am in favor of this document. 

Thanks
 
Regards... Zafar


>-----Original Message-----
>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf 
>Of Loa Andersson
>Sent: Sunday, November 23, 2003 6:12 PM
>To: MPLS wg
>Cc: George Swallow; Alex Zinin
>Subject: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document
>
>
>All,
>
>we been asked to make
>
>draft-farrel-mpls-rsvpte-attributes-00.txt
>
>an mpls working document. The document were discussed in 
>Minneapolis, the room was undecided if we should go forward 
>with the document. No opposition, but also no strongly voiced support.
>
>Therefore we would like both those in favor and those
>opposed to making this a working group document to
>speak up.
>
>/Loa
>
>-- 
>
>Loa Andersson
>
>mobile +46 739 81 21 64
>
>



From owner-mpls@UU.NET  Mon Nov 24 16:48:07 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 QAA03508
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 16:48:03 -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 QQpqgd27214
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 21:48: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 QQpqgd26918;
	Mon, 24 Nov 2003 21:48:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqgc22225
	for mpls-outgoing; Mon, 24 Nov 2003 21:34: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 QQpqgc22216
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Nov 2003 21:33:56 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 QQpqgc22331
	for <mpls@UU.NET>; Mon, 24 Nov 2003 21:31:02 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 QQpqgc19824
	for <mpls@UU.NET>; Mon, 24 Nov 2003 21:31:01 GMT
Received: from vmmr8.verisignmail.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: omrnat3.verisignmail.com [216.168.230.162])
	id QQpqgc19816
	for <mpls@UU.NET>; Mon, 24 Nov 2003 21:31:01 GMT
Received: from ms7.verisignmail.com (ms7.verisignmail.com [216.168.230.174] (may be forged))
	by vmmr8.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA)
	with ESMTP id ATK19857;
	Mon, 24 Nov 2003 15:55:45 -0500 (EST)
Received: from khumbu (66.238.227.126.ptr.us.xo.net [66.238.227.126])
	by ms7.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA)
	with SMTP id AWL73543;
	Mon, 24 Nov 2003 15:55:43 -0500 (EST)
From: "Eric W Gray" <egray@westridgenetworks.com>
To: "'Loa Andersson'" <loa@pi.se>, "'MPLS wg'" <mpls@UU.NET>
Cc: "'George Swallow'" <swallow@cisco.com>, "'Alex Zinin'" <zinin@psg.com>
Subject: RE: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document
Date: Mon, 24 Nov 2003 15:55:38 -0500
Message-ID: <012101c3b2cd$50640d80$8801a8c0@khumbu>
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.2627
Importance: Normal
In-Reply-To: <3FC13EA6.6030305@pi.se>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

I am in favor of making this a working group document.

--
Eric

> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Loa
Andersson
> Sent: Sunday, November 23, 2003 6:12 PM
> To: MPLS wg
> Cc: George Swallow; Alex Zinin
> Subject: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document
> 
> All,
> 
> we been asked to make
> 
> draft-farrel-mpls-rsvpte-attributes-00.txt
> 
> an mpls working document. The document were discussed in
> Minneapolis, the room was undecided if we should go
> forward with the document. No opposition, but also no
> strongly voiced support.
> 
> Therefore we would like both those in favor and those
> opposed to making this a working group document to
> speak up.
> 
> /Loa
> 
> --
> 
> Loa Andersson
> 
> mobile +46 739 81 21 64
> 





From owner-mpls@UU.NET  Mon Nov 24 17:18: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 RAA06405
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 17:18: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 QQpqgf07803
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 22:18: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 QQpqgf07518;
	Mon, 24 Nov 2003 22:18:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqgd24402
	for mpls-outgoing; Mon, 24 Nov 2003 21:59: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 QQpqgd24397
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Nov 2003 21:59:46 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 QQpqgd16566
	for <mpls@UU.NET>; Mon, 24 Nov 2003 21:58:50 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 QQpqgd11189
	for <mpls@UU.NET>; Mon, 24 Nov 2003 21:58:50 GMT
Received: from sa.infonet.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sa.infonet.com [192.157.130.21])
	id QQpqgd11169
	for <mpls@UU.NET>; Mon, 24 Nov 2003 21:58:50 GMT
Received: from delta.info.net (delta.info.net [192.237.125.34])
	by sa.infonet.com  with ESMTP id hAOLvx2o016837;
	Mon, 24 Nov 2003 21:57:59 GMT
Received: from zhangr2.info.net (sfjl114.us.info.net [204.79.139.114])
	by delta.info.net  with ESMTP id VAA22193;
	Mon, 24 Nov 2003 21:57:58 GMT
Message-Id: <5.2.0.9.2.20031124120353.00ace7c8@delta.info.net>
X-Sender: zhangr@delta.info.net
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 24 Nov 2003 12:04:04 -0800
To: Loa Andersson <loa@pi.se>, MPLS wg <mpls@UU.NET>
From: raymond zhang <zhangr@info.net>
Subject: Re: draft-yasukawa-mpls-p2mp-requirement-01.txt for working
  document?
Cc: George Swallow <swallow@cisco.com>, Alex Zinin <zinin@psg.com>
In-Reply-To: <3FC13CF1.2060802@pi.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Loa,

In favor...

Regards,
Raymond

At 12:04 AM 11/24/2003 +0100, Loa Andersson wrote:
>All,
>
>we've been asked to make the
>
>draft-yasukawa-mpls-p2mp-requirement-01.txt
>
>an mpls working group documument. The draft were discussed
>in Minneapolis and there were support for making it a working
>group document.
>
>Comments?
>
>/Loa
>
>
>--
>
>Loa Andersson
>
>mobile +46 739 81 21 64
>




From owner-mpls@UU.NET  Mon Nov 24 17:22: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 RAA06511
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 17:22: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 QQpqgf01186
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 22:22: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 QQpqgf00878;
	Mon, 24 Nov 2003 22:22:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqge08626
	for mpls-outgoing; Mon, 24 Nov 2003 22:03: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 QQpqge08320
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Nov 2003 22:03:47 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 QQpqge09618
	for <mpls@UU.NET>; Mon, 24 Nov 2003 22:00: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 QQpqge13586
	for <mpls@UU.NET>; Mon, 24 Nov 2003 22:00:36 GMT
Received: from sa.infonet.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sa.infonet.com [192.157.130.21])
	id QQpqge13523
	for <mpls@UU.NET>; Mon, 24 Nov 2003 22:00:33 GMT
Received: from delta.info.net (delta.info.net [192.237.125.34])
	by sa.infonet.com  with ESMTP id hAOM052o018029;
	Mon, 24 Nov 2003 22:00:05 GMT
Received: from zhangr2.info.net (sfjl114.us.info.net [204.79.139.114])
	by delta.info.net  with ESMTP id WAA22271;
	Mon, 24 Nov 2003 22:00:04 GMT
Message-Id: <5.2.0.9.2.20031124135924.03cac618@delta.info.net>
X-Sender: zhangr@delta.info.net
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 24 Nov 2003 13:59:56 -0800
To: Loa Andersson <loa@pi.se>, MPLS wg <mpls@UU.NET>
From: raymond zhang <zhangr@info.net>
Subject: Re: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document
Cc: George Swallow <swallow@cisco.com>, Alex Zinin <zinin@psg.com>
In-Reply-To: <3FC13EA6.6030305@pi.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Loa,

I am in favor of in making this as a wg doc.

Regards,
Raymond

At 12:11 AM 11/24/2003 +0100, Loa Andersson wrote:
>All,
>
>we been asked to make
>
>draft-farrel-mpls-rsvpte-attributes-00.txt
>
>an mpls working document. The document were discussed in
>Minneapolis, the room was undecided if we should go
>forward with the document. No opposition, but also no
>strongly voiced support.
>
>Therefore we would like both those in favor and those
>opposed to making this a working group document to
>speak up.
>
>/Loa
>
>--
>
>Loa Andersson
>
>mobile +46 739 81 21 64
>
>




From owner-mpls@UU.NET  Mon Nov 24 20:30:02 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 UAA15385
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 20:30:01 -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 QQpqgs27789
	for <mpls-archive@lists.ietf.org>; Tue, 25 Nov 2003 01:30: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 QQpqgs27582;
	Tue, 25 Nov 2003 01:30:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqgq26836
	for mpls-outgoing; Tue, 25 Nov 2003 01:11: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 QQpqgq26824
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Nov 2003 01:11:35 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 QQpqgq10959
	for <mpls@UU.NET>; Tue, 25 Nov 2003 01:07: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 QQpqgq28978
	for <mpls@UU.NET>; Tue, 25 Nov 2003 01:07:01 GMT
Received: from mailhost.avici.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: b2gateway2.avici.com [208.246.215.201] (may be forged))
	id QQpqgq28964
	for <mpls@UU.NET>; Tue, 25 Nov 2003 01:07:00 GMT
Received: from avici.com (swdev105.avici.com [10.2.21.105])
	by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id hAP16jue000905;
	Mon, 24 Nov 2003 20:06:45 -0500
Message-Id: <200311250106.hAP16jue000905@mailhost.avici.com>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
From: Markus Jork <mjork@avici.com>
To: Loa Andersson <loa@pi.se>
cc: MPLS wg <mpls@UU.NET>, George Swallow <swallow@cisco.com>,
        Alex Zinin <zinin@psg.com>
Subject: Re: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document 
In-reply-to: Your message of "Mon, 24 Nov 2003 00:11:34 +0100."
             <3FC13EA6.6030305@pi.se> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 24 Nov 2003 20:06:43 -0500
Sender: owner-mpls@UU.NET
Precedence: bulk

in favor

Markus


> All,
> 
> we been asked to make
> 
> draft-farrel-mpls-rsvpte-attributes-00.txt
> 
> an mpls working document. The document were discussed in
> Minneapolis, the room was undecided if we should go
> forward with the document. No opposition, but also no
> strongly voiced support.
> 
> Therefore we would like both those in favor and those
> opposed to making this a working group document to
> speak up.
> 
> /Loa
> 
> -- 
> 
> Loa Andersson
> 
> mobile +46 739 81 21 64
> 




From owner-mpls@UU.NET  Mon Nov 24 20:55: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 UAA16174
	for <mpls-archive@lists.ietf.org>; Mon, 24 Nov 2003 20:55: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 QQpqgt03975
	for <mpls-archive@lists.ietf.org>; Tue, 25 Nov 2003 01:55: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 QQpqgt03809;
	Tue, 25 Nov 2003 01:55:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqgs29029
	for mpls-outgoing; Tue, 25 Nov 2003 01:40: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 QQpqgs29019
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Nov 2003 01:40: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 QQpqgs28255
	for <mpls@uu.net>; Tue, 25 Nov 2003 01:38: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 QQpqgs13711
	for <mpls@uu.net>; Tue, 25 Nov 2003 01:38:34 GMT
Received: from sj-iport-5.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-5.cisco.com [171.68.10.87])
	id QQpqgs13691
	for <mpls@uu.net>; Tue, 25 Nov 2003 01:38:34 GMT
Received: from cisco.com (171.71.177.238)
  by sj-iport-5.cisco.com with ESMTP; 24 Nov 2003 17:38:26 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAP1cUjq023560
	for <mpls@uu.net>; Mon, 24 Nov 2003 17:38:30 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEF70708;
	Mon, 24 Nov 2003 20:38:29 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAP1cTA21679 for mpls@uu.net; Mon, 24 Nov 2003 20:38:29 -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 QQpqgs28925
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Nov 2003 01:37: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 QQpqgs14923
	for <mpls@uu.net>; Tue, 25 Nov 2003 01:35: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 QQpqgs10033
	for <mpls@uu.net>; Tue, 25 Nov 2003 01:35:40 GMT
Received: from sj-iport-4.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-4.cisco.com [171.68.10.86])
	id QQpqgs10021
	for <mpls@uu.net>; Tue, 25 Nov 2003 01:35:39 GMT
Received: from mira-kan-a.cisco.com (IDENT:mirapoint@mira-kan-a.cisco.com [161.44.201.17])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAP1Zajq021140;
	Mon, 24 Nov 2003 17:35:37 -0800 (PST)
Received: from cisco.com (che-vpn-cluster-1-141.cisco.com [10.86.240.141])
	by mira-kan-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AAX32784;
	Mon, 24 Nov 2003 17:35:34 -0800 (PST)
Message-ID: <3FC2B1E6.1080307@cisco.com>
Date: Mon, 24 Nov 2003 20:35:34 -0500
From: Reshad Rahman <rrahman@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Loa Andersson <loa@pi.se>
CC: MPLS wg <mpls@UU.NET>, George Swallow <swallow@cisco.com>,
        Alex Zinin <zinin@psg.com>
Subject: Re: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document
References: <3FC13EA6.6030305@pi.se>
In-Reply-To: <3FC13EA6.6030305@pi.se>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

In favour.

Regards,
Reshad.

Loa Andersson wrote:

> All,
>
> we been asked to make
>
> draft-farrel-mpls-rsvpte-attributes-00.txt
>
> an mpls working document. The document were discussed in
> Minneapolis, the room was undecided if we should go
> forward with the document. No opposition, but also no
> strongly voiced support.
>
> Therefore we would like both those in favor and those
> opposed to making this a working group document to
> speak up.
>
> /Loa
>



From owner-mpls@UU.NET  Tue Nov 25 09:44: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 JAA19371
	for <mpls-archive@lists.ietf.org>; Tue, 25 Nov 2003 09:44: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 QQpqis11853
	for <mpls-archive@lists.ietf.org>; Tue, 25 Nov 2003 14:44:28 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 QQpqis11587;
	Tue, 25 Nov 2003 14:44:18 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqir12149
	for mpls-outgoing; Tue, 25 Nov 2003 14:26: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 QQpqir12144
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Nov 2003 14:26: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 QQpqir28799
	for <mpls@UU.NET>; Tue, 25 Nov 2003 14:23: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 QQpqir10660
	for <mpls@UU.NET>; Tue, 25 Nov 2003 14:23:46 GMT
Received: from smtp.theia.ocn.ne.jp by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: theia.ocn.ne.jp [211.129.13.169])
	id QQpqir10633
	for <mpls@UU.NET>; Tue, 25 Nov 2003 14:23:45 GMT
Received: from [127.0.0.1] (unknown [203.139.162.154])
	by smtp.theia.ocn.ne.jp (Postfix) with ESMTP
	id 65FC01973; Tue, 25 Nov 2003 23:23:43 +0900 (JST)
Date: Tue, 25 Nov 2003 23:21:34 +0900
From: Hitoshi Fukuda <hitoshi.fukuda@ntt.com>
To: "Loa Andersson" <loa@pi.se>, "MPLS wg" <mpls@UU.NET>
Subject: Re: draft-yasukawa-mpls-p2mp-requirement-01.txt for working document?
Cc: "George Swallow" <swallow@cisco.com>, "Alex Zinin" <zinin@psg.com>
In-Reply-To: <3FC13CF1.2060802@pi.se>
References: <3FC13CF1.2060802@pi.se>
Message-Id: <20031125221725.2869.HITOSHI.FUKUDA@ntt.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.07.02
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

I support it.

Hitoshi Fukuda
NTT Communications

At Mon, 24 Nov 2003 00:04:17 +0100 , Loa Andersson wrote:
> All,
> 
> we've been asked to make the
> 
> draft-yasukawa-mpls-p2mp-requirement-01.txt
> 
> an mpls working group documument. The draft were discussed
> in Minneapolis and there were support for making it a working
> group document.
> 
> Comments?
> 
> /Loa
> 
> 
> -- 
> 
> Loa Andersson
> 
> mobile +46 739 81 21 64
> 






From owner-mpls@UU.NET  Tue Nov 25 09:56: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 JAA19915
	for <mpls-archive@lists.ietf.org>; Tue, 25 Nov 2003 09:56: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 QQpqit00754
	for <mpls-archive@lists.ietf.org>; Tue, 25 Nov 2003 14:57: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 QQpqit00404;
	Tue, 25 Nov 2003 14:56:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqis13006
	for mpls-outgoing; Tue, 25 Nov 2003 14:39:59 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 QQpqis12997
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Nov 2003 14: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 QQpqis25460
	for <mpls@UU.NET>; Tue, 25 Nov 2003 14:38: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 QQpqis28331
	for <mpls@UU.NET>; Tue, 25 Nov 2003 14:38:00 GMT
Received: from p-mail2.rd.francetelecom.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: p-mail2.rd.francetelecom.com [195.101.245.16])
	id QQpqis28301
	for <mpls@UU.NET>; Tue, 25 Nov 2003 14:38:00 GMT
Received: from lanmhs30.rd.francetelecom.fr ([10.193.21.61]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Tue, 25 Nov 2003 15:37:51 +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"
Content-Transfer-Encoding: quoted-printable
Subject: RE : draft-farrel-mpls-rsvpte-attributes-00.txt for wg document
Date: Tue, 25 Nov 2003 15:37:51 +0100
Message-ID: <B7D1592DFC5137478D0385A9595C455353AA5A@lanmhs30.rd.francetelecom.fr>
Thread-Topic: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document
Thread-Index: AcOyGImZVwH2TvChQC+4mDhLaHNoUABSRkNA
From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <jeanlouis.leroux@rd.francetelecom.com>
To: "Loa Andersson" <loa@pi.se>, "MPLS wg" <mpls@UU.NET>
Cc: "George Swallow" <swallow@cisco.com>, "Alex Zinin" <zinin@psg.com>
X-OriginalArrivalTime: 25 Nov 2003 14:37:51.0960 (UTC) FILETIME=[B4988580:01C3B361]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

In favor,

JL

-----Message d'origine-----
De : Loa Andersson [mailto:loa@pi.se]=20
Envoy=E9 : lundi 24 novembre 2003 00:12
=C0 : MPLS wg
Cc : George Swallow; Alex Zinin
Objet : draft-farrel-mpls-rsvpte-attributes-00.txt for wg document


All,

we been asked to make

draft-farrel-mpls-rsvpte-attributes-00.txt

an mpls working document. The document were discussed in Minneapolis, =
the room was undecided if we should go forward with the document. No =
opposition, but also no strongly voiced support.

Therefore we would like both those in favor and those
opposed to making this a working group document to
speak up.

/Loa

--=20

Loa Andersson

mobile +46 739 81 21 64




From owner-mpls@UU.NET  Tue Nov 25 10:08: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 KAA20873
	for <mpls-archive@lists.ietf.org>; Tue, 25 Nov 2003 10:08: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 QQpqiu14757
	for <mpls-archive@lists.ietf.org>; Tue, 25 Nov 2003 15:08: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 QQpqiu14094;
	Tue, 25 Nov 2003 15:08:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqit14230
	for mpls-outgoing; Tue, 25 Nov 2003 14:49:38 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 QQpqit14220
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Nov 2003 14:49:36 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 QQpqis01010
	for <mpls@UU.NET>; Tue, 25 Nov 2003 14:41: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 QQpqis03453
	for <mpls@UU.NET>; Tue, 25 Nov 2003 14:41:16 GMT
Received: from p-mail2.rd.francetelecom.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: p-mail2.rd.francetelecom.com [195.101.245.16])
	id QQpqis03407
	for <mpls@UU.NET>; Tue, 25 Nov 2003 14:41:15 GMT
Received: from lanmhs30.rd.francetelecom.fr ([10.193.21.61]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Tue, 25 Nov 2003 15:41:08 +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"
Content-Transfer-Encoding: quoted-printable
Subject: RE : draft-yasukawa-mpls-p2mp-requirement-01.txt for working document?
Date: Tue, 25 Nov 2003 15:41:07 +0100
Message-ID: <B7D1592DFC5137478D0385A9595C455353AA64@lanmhs30.rd.francetelecom.fr>
Thread-Topic: draft-yasukawa-mpls-p2mp-requirement-01.txt for working document?
Thread-Index: AcOyF7eyUHhLYLAkRqCMWhaKZbxWfQBSgIcQ
From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <jeanlouis.leroux@rd.francetelecom.com>
To: "Loa Andersson" <loa@pi.se>, "MPLS wg" <mpls@UU.NET>
Cc: "George Swallow" <swallow@cisco.com>, "Alex Zinin" <zinin@psg.com>
X-OriginalArrivalTime: 25 Nov 2003 14:41:08.0481 (UTC) FILETIME=[29BB3F10:01C3B362]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Hi Loa and all,

I support making this draft a WG doc

JL

-----Message d'origine-----
De : Loa Andersson [mailto:loa@pi.se]=20
Envoy=E9 : lundi 24 novembre 2003 00:04
=C0 : MPLS wg
Cc : George Swallow; Alex Zinin
Objet : draft-yasukawa-mpls-p2mp-requirement-01.txt for working =
document?


All,

we've been asked to make the

draft-yasukawa-mpls-p2mp-requirement-01.txt

an mpls working group documument. The draft were discussed
in Minneapolis and there were support for making it a working group =
document.

Comments?

/Loa


--=20

Loa Andersson

mobile +46 739 81 21 64




From owner-mpls@UU.NET  Tue Nov 25 10:57: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 KAA24468
	for <mpls-archive@lists.ietf.org>; Tue, 25 Nov 2003 10:57: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 QQpqix13482
	for <mpls-archive@lists.ietf.org>; Tue, 25 Nov 2003 15:58: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 QQpqix13311;
	Tue, 25 Nov 2003 15:57:59 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqiw07557
	for mpls-outgoing; Tue, 25 Nov 2003 15:36: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 QQpqiw07549
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Nov 2003 15:36:54 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 QQpqiw26045
	for <mpls@uu.net>; Tue, 25 Nov 2003 15:36: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 QQpqiw14080
	for <mpls@uu.net>; Tue, 25 Nov 2003 15:36:15 GMT
Received: from sj-iport-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-2-in.cisco.com [171.71.176.71])
	id QQpqiw14057
	for <mpls@uu.net>; Tue, 25 Nov 2003 15:36:15 GMT
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-2.cisco.com with ESMTP; 25 Nov 2003 07:37:19 +0000
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAPFZtjq023047
	for <mpls@uu.net>; Tue, 25 Nov 2003 07:35:55 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEF99582;
	Tue, 25 Nov 2003 10:35:54 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAPFZsA00829 for mpls@uu.net; Tue, 25 Nov 2003 10:35: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 QQpqgl12190
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Nov 2003 23:50:54 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 QQpqgk29749
	for <mpls@uu.net>; Mon, 24 Nov 2003 23:44: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 QQpqgk00419
	for <mpls@uu.net>; Mon, 24 Nov 2003 23:44:17 GMT
Received: from linda-1.paradise.net.nz by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: bm-1a.paradise.net.nz [202.0.58.20])
	id QQpqgk29817
	for <mpls@uu.net>; Mon, 24 Nov 2003 23:44:00 GMT
Received: from smtp-2.paradise.net.nz (smtp-2a.paradise.net.nz [202.0.32.195])
 by linda-1.paradise.net.nz (Paradise.net.nz)
 with ESMTP id <0HOV00MJJR9BEO@linda-1.paradise.net.nz> for mpls@uu.net; Tue,
 25 Nov 2003 12:43:59 +1300 (NZDT)
Received: from advancepts.co.nz
 (203-79-119-214.cable.paradise.net.nz [203.79.119.214])
	by smtp-2.paradise.net.nz (Postfix) with ESMTP id 76F899E203	for
 <mpls@uu.net>; Tue, 25 Nov 2003 12:43:59 +1300 (NZDT)
Date: Tue, 25 Nov 2003 11:47:21 +1300 (NZDT)
From: Francois Prowse <fp@prowse.co.nz>
Subject: LDP-MIB
X-X-Sender: fprowse@linux-wlg.prowse.co.nz
To: mpls@UU.NET
Message-id: <Pine.LNX.4.44.0311251145370.14577-100000@linux-wlg.prowse.co.nz>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hell, looking at the design of draft-ietf-mpls-ldp-mib-14.txt it refers to 
mplsLdpSesState. I'm trying to find the MIB that this is actually 
described in, anyone able to point me in the right direction?

re

Francois


-- 




From owner-mpls@UU.NET  Tue Nov 25 13:29: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 NAA00720
	for <mpls-archive@lists.ietf.org>; Tue, 25 Nov 2003 13:29: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 QQpqjh28215
	for <mpls-archive@lists.ietf.org>; Tue, 25 Nov 2003 18: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 QQpqjh27526;
	Tue, 25 Nov 2003 18:29:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqjg17418
	for mpls-outgoing; Tue, 25 Nov 2003 18:08:40 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 QQpqjg17413
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Nov 2003 18:08: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 QQpqjg25727
	for <mpls@uu.net>; Tue, 25 Nov 2003 18:03: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 QQpqjg21413
	for <mpls@uu.net>; Tue, 25 Nov 2003 18:03:45 GMT
Received: from sj-iport-5.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-5.cisco.com [171.68.10.87])
	id QQpqjg21401
	for <mpls@uu.net>; Tue, 25 Nov 2003 18:03:45 GMT
Received: from cisco.com (64.102.124.12)
  by sj-iport-5.cisco.com with ESMTP; 25 Nov 2003 10:03:31 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAPI3dxi023947
	for <mpls@uu.net>; Tue, 25 Nov 2003 13:03:41 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEG13923;
	Tue, 25 Nov 2003 13:03:38 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAPI3c204882 for mpls@uu.net; Tue, 25 Nov 2003 13:03: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 QQpqjg05011
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Nov 2003 18:01:04 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 QQpqjf12091
	for <mpls@uu.net>; Tue, 25 Nov 2003 17:51:53 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 QQpqjf08119
	for <mpls@uu.net>; Tue, 25 Nov 2003 17:51:53 GMT
Received: from sj-iport-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72])
	id QQpqjf08094
	for <mpls@uu.net>; Tue, 25 Nov 2003 17:51:53 GMT
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 25 Nov 2003 09:53:26 +0000
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAPHpojq027659;
	Tue, 25 Nov 2003 09:51:50 -0800 (PST)
Received: from jvasseur-w2k01.cisco.com (sjc-vpn2-356.cisco.com [10.21.113.100]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA03969; Tue, 25 Nov 2003 09:51:49 -0800 (PST)
Message-Id: <4.3.2.7.2.20031125125141.0203ef58@wells.cisco.com>
X-Sender: jvasseur@wells.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 25 Nov 2003 12:51:48 -0500
To: Loa Andersson <loa@pi.se>
From: Jean Philippe Vasseur <jvasseur@cisco.com>
Subject: Re: draft-yasukawa-mpls-p2mp-requirement-01.txt for working
  document?
Cc: MPLS wg <mpls@UU.NET>, George Swallow <swallow@cisco.com>,
        Alex Zinin <zinin@psg.com>
In-Reply-To: <3FC13CF1.2060802@pi.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

in favor.

JP.

At 12:04 AM 11/24/2003 +0100, Loa Andersson wrote:
>All,
>
>we've been asked to make the
>
>draft-yasukawa-mpls-p2mp-requirement-01.txt
>
>an mpls working group documument. The draft were discussed
>in Minneapolis and there were support for making it a working
>group document.
>
>Comments?
>
>/Loa
>
>
>--
>
>Loa Andersson
>
>mobile +46 739 81 21 64
>
>



From owner-mpls@UU.NET  Tue Nov 25 13:29: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 NAA00765
	for <mpls-archive@lists.ietf.org>; Tue, 25 Nov 2003 13:29:45 -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 QQpqjh00149
	for <mpls-archive@lists.ietf.org>; Tue, 25 Nov 2003 18:29: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 QQpqjh29590;
	Tue, 25 Nov 2003 18:29:47 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqjg17445
	for mpls-outgoing; Tue, 25 Nov 2003 18:09:19 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 QQpqjg17440
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Nov 2003 18:09: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 QQpqjg08752
	for <mpls@UU.NET>; Tue, 25 Nov 2003 18:08: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 QQpqjg01665
	for <mpls@UU.NET>; Tue, 25 Nov 2003 18:08:29 GMT
Received: from smail.alcatel.fr by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gc-na165.alcatel.fr [64.208.49.165])
	id QQpqjg01647
	for <mpls@UU.NET>; Tue, 25 Nov 2003 18:08:28 GMT
Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11])
	by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id hAPI7nJF013937;
	Tue, 25 Nov 2003 19:07:49 +0100
Received: from alcatel.be ([138.203.64.92])
          by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11)
          with ESMTP id 2003112519074828:4483 ;
          Tue, 25 Nov 2003 19:07:48 +0100 
Message-ID: <3FC39AA5.1040500@alcatel.be>
Date: Tue, 25 Nov 2003 19:08:37 +0100
From: Dimitri.Papadimitriou@alcatel.be
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Loa Andersson <loa@pi.se>
Cc: MPLS wg <mpls@UU.NET>, George Swallow <swallow@cisco.com>,
        Alex Zinin <zinin@psg.com>
Subject: Re: draft-yasukawa-mpls-p2mp-requirement-01.txt for working document?
References: <3FC13CF1.2060802@pi.se>
In-Reply-To: <3FC13CF1.2060802@pi.se>
X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 11/25/2003 19:07:48,
	Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 11/25/2003 19:07:49,
	Serialize complete at 11/25/2003 19:07:49
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Virus-Scanned: by amavisd-new
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

hi loa, all,

i support making this document a wg i-d

thanks,
- dimitri.

Loa Andersson wrote:

> All,
> 
> we've been asked to make the
> 
> draft-yasukawa-mpls-p2mp-requirement-01.txt
> 
> an mpls working group documument. The draft were discussed
> in Minneapolis and there were support for making it a working
> group document.
> 
> Comments?
> 
> /Loa
> 
> 

-- 
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 Nov 25 15:58: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 PAA09667
	for <mpls-archive@lists.ietf.org>; Tue, 25 Nov 2003 15:58: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 QQpqjr03681
	for <mpls-archive@lists.ietf.org>; Tue, 25 Nov 2003 20: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 QQpqjr03427;
	Tue, 25 Nov 2003 20:58:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqjq09313
	for mpls-outgoing; Tue, 25 Nov 2003 20:36:08 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 QQpqjq09140
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Nov 2003 20:35: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 QQpqjp25935
	for <mpls@UU.NET>; Tue, 25 Nov 2003 20:28: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 QQpqjp01319
	for <mpls@UU.NET>; Tue, 25 Nov 2003 20:28:46 GMT
Received: from admin1.usa1ma.alcatel.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: apmail2.astralpoint.com [65.114.186.140])
	id QQpqjp01305
	for <mpls@UU.NET>; Tue, 25 Nov 2003 20:28:45 GMT
Received: by admin1.usa1ma.alcatel.com with Internet Mail Service (5.5.2653.19)
	id <VT9NNGQX>; Tue, 25 Nov 2003 15:28:43 -0500
Message-ID: <FACEE3CF5B27D711BBDF00105A9CA42101263E5B@admin1.usa1ma.alcatel.com>
From: "Xu, Yangguang" <Yangguang.Xu@Alcatel.com>
To: Loa Andersson <loa@pi.se>
Cc: MPLS wg <mpls@UU.NET>, George Swallow <swallow@cisco.com>,
        Alex Zinin
	 <zinin@psg.com>
Subject: RE: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document
Date: Tue, 25 Nov 2003 15:28:36 -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


in favor...


>All,
>
>we been asked to make
>
>draft-farrel-mpls-rsvpte-attributes-00.txt
>
>an mpls working document. The document were discussed in
>Minneapolis, the room was undecided if we should go
>forward with the document. No opposition, but also no
>strongly voiced support.
>
>Therefore we would like both those in favor and those
>opposed to making this a working group document to
>speak up.
>
>/Loa
>


From owner-mpls@UU.NET  Tue Nov 25 19:11:03 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 TAA19074
	for <mpls-archive@lists.ietf.org>; Tue, 25 Nov 2003 19:11:03 -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 QQpqke28629
	for <mpls-archive@lists.ietf.org>; Wed, 26 Nov 2003 00:11: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 QQpqke28065;
	Wed, 26 Nov 2003 00:10:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqkd23218
	for mpls-outgoing; Tue, 25 Nov 2003 23:50: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 QQpqkd23208
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Nov 2003 23:50:49 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 QQpqkd01953
	for <mpls@UU.NET>; Tue, 25 Nov 2003 23:48: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 QQpqkd29350
	for <mpls@UU.NET>; Tue, 25 Nov 2003 23:48:03 GMT
Received: from smtp004.mail.ukl.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: smtp004.mail.ukl.yahoo.com [217.12.11.35])
	id QQpqkd29337
	for <mpls@UU.NET>; Tue, 25 Nov 2003 23:48:02 GMT
Received: from adsl-67-117-149-168.dsl.snfc21.pacbell.net (HELO RAKHILAPTOP) (vsharma87@67.117.149.168 with login)
  by smtp1.mail.vip.ukl.yahoo.com with SMTP; 25 Nov 2003 23:47:53 -0000
From: "Vishal Sharma" <v.sharma@ieee.org>
To: "Loa Andersson" <loa@pi.se>, "MPLS wg" <mpls@UU.NET>
Cc: "George Swallow" <swallow@cisco.com>, "Alex Zinin" <zinin@psg.com>
Subject: RE: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document
Date: Tue, 25 Nov 2003 15:47:09 -0800
Message-ID: <MMECLKMDFPCEJFECIBCMAEEADPAA.v.sharma@ieee.org>
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.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3FC13EA6.6030305@pi.se>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Loa,

I support. There was one question raised by Adrian though that
was not answered at the WG meeting, so it might be useful
for us to consider on the list. It was "do we need a way to support
arbitrary TLVs?"

I believe this is one of the two solutions proposed in the
draft, and it would be good to get WG opinion on that.

-Vishal

> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Loa
> Andersson
> Sent: Sunday, November 23, 2003 3:12 PM
> To: MPLS wg
> Cc: George Swallow; Alex Zinin
> Subject: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document
> 
> 
> All,
> 
> we been asked to make
> 
> draft-farrel-mpls-rsvpte-attributes-00.txt
> 
> an mpls working document. The document were discussed in
> Minneapolis, the room was undecided if we should go
> forward with the document. No opposition, but also no
> strongly voiced support.
> 
> Therefore we would like both those in favor and those
> opposed to making this a working group document to
> speak up.
> 
> /Loa
> 
> -- 
> 
> Loa Andersson
> 
> mobile +46 739 81 21 64
> 


From owner-mpls@UU.NET  Tue Nov 25 19:11: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 TAA19092
	for <mpls-archive@lists.ietf.org>; Tue, 25 Nov 2003 19:11: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 QQpqke28844
	for <mpls-archive@lists.ietf.org>; Wed, 26 Nov 2003 00:11: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 QQpqke28210;
	Wed, 26 Nov 2003 00:11:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqkd23213
	for mpls-outgoing; Tue, 25 Nov 2003 23:50: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 QQpqkd23206
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Nov 2003 23:50: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 QQpqkd01797
	for <mpls@UU.NET>; Tue, 25 Nov 2003 23:47: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 QQpqkd28029
	for <mpls@UU.NET>; Tue, 25 Nov 2003 23:47:58 GMT
Received: from smtp004.mail.ukl.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: smtp004.mail.ukl.yahoo.com [217.12.11.35])
	id QQpqkd27997
	for <mpls@UU.NET>; Tue, 25 Nov 2003 23:47:57 GMT
Received: from adsl-67-117-149-168.dsl.snfc21.pacbell.net (HELO RAKHILAPTOP) (vsharma87@67.117.149.168 with login)
  by smtp1.mail.vip.ukl.yahoo.com with SMTP; 25 Nov 2003 23:47:56 -0000
From: "Vishal Sharma" <v.sharma@ieee.org>
To: "Loa Andersson" <loa@pi.se>, "MPLS wg" <mpls@UU.NET>
Cc: "George Swallow" <swallow@cisco.com>, "Alex Zinin" <zinin@psg.com>
Subject: RE: draft-yasukawa-mpls-p2mp-requirement-01.txt for working document?
Date: Tue, 25 Nov 2003 15:47:12 -0800
Message-ID: <MMECLKMDFPCEJFECIBCMCEEADPAA.v.sharma@ieee.org>
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.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3FC13CF1.2060802@pi.se>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Loa,

I support.

-Vishal

> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Loa
> Andersson
> Sent: Sunday, November 23, 2003 3:04 PM
> To: MPLS wg
> Cc: George Swallow; Alex Zinin
> Subject: draft-yasukawa-mpls-p2mp-requirement-01.txt for working
> document?
> 
> 
> All,
> 
> we've been asked to make the
> 
> draft-yasukawa-mpls-p2mp-requirement-01.txt
> 
> an mpls working group documument. The draft were discussed
> in Minneapolis and there were support for making it a working
> group document.
> 
> Comments?
> 
> /Loa
> 
> 
> -- 
> 
> Loa Andersson
> 
> mobile +46 739 81 21 64
> 


From owner-mpls@UU.NET  Tue Nov 25 20:18: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 UAA20659
	for <mpls-archive@lists.ietf.org>; Tue, 25 Nov 2003 20:18:21 -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 QQpqkj28279
	for <mpls-archive@lists.ietf.org>; Wed, 26 Nov 2003 01:18: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 QQpqkj28029;
	Wed, 26 Nov 2003 01:18:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqkh16353
	for mpls-outgoing; Wed, 26 Nov 2003 00:56: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 QQpqkh16348
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Nov 2003 00:56:44 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 QQpqkh09410
	for <mpls@UU.NET>; Wed, 26 Nov 2003 00:55: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 QQpqkh00732
	for <mpls@UU.NET>; Wed, 26 Nov 2003 00:55:33 GMT
Received: from tama5.ecl.ntt.co.jp by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: tama5.ecl.ntt.co.jp [129.60.39.102])
	id QQpqkh00713
	for <mpls@UU.NET>; Wed, 26 Nov 2003 00:55:32 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.8p1/8.12.8) with ESMTP id hAQ0tEUC020428;
	Wed, 26 Nov 2003 09:55:14 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1])
	by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hAQ0tEpo021845;
	Wed, 26 Nov 2003 09:55:14 +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.8p1/8.12.8) with ESMTP id hAQ0tD8H012127;
	Wed, 26 Nov 2003 09:55:13 +0900 (JST)
Received: from imc.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id JAA28809;
	Wed, 26 Nov 2003 09:55:13 +0900 (JST)
Received: from win-yasukawa.lab.ntt.co.jp
	by imc.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id JAA04434;
	Wed, 26 Nov 2003 09:55:12 +0900 (JST)
Message-Id: <5.0.2.5.2.20031126095945.05a9bf18@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: Wed, 26 Nov 2003 10:02:51 +0900
To: Loa Andersson <loa@pi.se>, MPLS wg <mpls@UU.NET>
From: Seisho Yasukawa <yasukawa.seisho@lab.ntt.co.jp>
Subject: Re: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document
Cc: George Swallow <swallow@cisco.com>, Alex Zinin <zinin@psg.com>
In-Reply-To: <3FC13EA6.6030305@pi.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Loa, all

I am in favor of making this a WG document.

Regards,
Seisho

At 00:11 03/11/24 +0100, Loa Andersson wrote:
>All,
>
>we been asked to make
>
>draft-farrel-mpls-rsvpte-attributes-00.txt
>
>an mpls working document. The document were discussed in
>Minneapolis, the room was undecided if we should go
>forward with the document. No opposition, but also no
>strongly voiced support.
>
>Therefore we would like both those in favor and those
>opposed to making this a working group document to
>speak up.
>
>/Loa
>
>--
>
>Loa Andersson
>
>mobile +46 739 81 21 64
>




From owner-mpls@UU.NET  Tue Nov 25 22:13: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 WAA23391
	for <mpls-archive@lists.ietf.org>; Tue, 25 Nov 2003 22:13: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 QQpqkq11770
	for <mpls-archive@lists.ietf.org>; Wed, 26 Nov 2003 03:13: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 QQpqkq11595;
	Wed, 26 Nov 2003 03:13:47 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqkp02305
	for mpls-outgoing; Wed, 26 Nov 2003 02: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 QQpqkp02300
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Nov 2003 02:51: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 QQpqkp16172
	for <mpls@uu.net>; Wed, 26 Nov 2003 02:47:11 GMT
From: jcucchiara@mindspring.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 QQpqkp00729
	for <mpls@uu.net>; Wed, 26 Nov 2003 02:47:10 GMT
Received: from hall.mail.mindspring.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hall.mail.mindspring.net [207.69.200.60])
	id QQpqkp00720
	for <mpls@uu.net>; Wed, 26 Nov 2003 02:47:10 GMT
Received: from h-68-166-236-249.cmbrmaor.dynamic.covad.net ([68.166.236.249] helo=jluciani-laptop)
	by hall.mail.mindspring.net with smtp (Exim 3.33 #1)
	id 1AOphc-0007H4-00; Tue, 25 Nov 2003 21:46:52 -0500
Message-Id: <3.0.1.32.20031125214842.01269d34@pop.mindspring.com>
X-Sender: jcucchiara@pop.mindspring.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 25 Nov 2003 21:48:42 -0500
To: Francois Prowse <fp@prowse.co.nz>, mpls@UU.NET
Subject: Re: LDP-MIB
In-Reply-To: <Pine.LNX.4.44.0311251145370.14577-100000@linux-wlg.prowse.
 co.nz>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk


Hello Francois, 

mplsLdpSesState has been renamed to mplsLdpSessionState.

mplsLdpSessionState OBJECT-TYPE
         SYNTAX      INTEGER {
                        nonexistent(1),
                        initialized(2),
                        openrec(3),
                        opensent(4),
                        operational(5)
                     }
         MAX-ACCESS  read-only
         STATUS      current
         DESCRIPTION
             "The current state of the session, all of the
             states 1 to 5 are based on the state machine
             for session negotiation behavior."
         REFERENCE
             "RFC3036, LDP Specification, Section 2.5.4,
             Initialization State Machine."
         ::= { mplsLdpSessionEntry 2 }



The references to "mplsLdpSesState" are in the area which
describes changes to the MIB from revision to revision.
This section is going away when the draft becomes an RFC.

   -Joan



At 11:47 AM 11/25/03 +1300, Francois Prowse wrote:
>Hell, looking at the design of draft-ietf-mpls-ldp-mib-14.txt it refers to 
>mplsLdpSesState. I'm trying to find the MIB that this is actually 
>described in, anyone able to point me in the right direction?
>
>re
>
>Francois
>
>
>-- 
>
>
>



From owner-mpls@UU.NET  Tue Nov 25 23:19:07 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 XAA24199
	for <mpls-archive@lists.ietf.org>; Tue, 25 Nov 2003 23:19: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 QQpqkt13995
	for <mpls-archive@lists.ietf.org>; Wed, 26 Nov 2003 03:56: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 QQpqkt13649;
	Wed, 26 Nov 2003 03:56:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqks23954
	for mpls-outgoing; Wed, 26 Nov 2003 03:36:47 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 QQpqks23949
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Nov 2003 03:36:46 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 QQpqks24170
	for <mpls@uu.net>; Wed, 26 Nov 2003 03:34: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 QQpqks09365
	for <mpls@uu.net>; Wed, 26 Nov 2003 03:34:13 GMT
Received: from sj-iport-5.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-5.cisco.com [171.68.10.87])
	id QQpqks09336
	for <mpls@uu.net>; Wed, 26 Nov 2003 03:34:12 GMT
Received: from cisco.com (64.102.124.12)
  by sj-iport-5.cisco.com with ESMTP; 25 Nov 2003 19:33:53 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAQ3Y8xg027658
	for <mpls@uu.net>; Tue, 25 Nov 2003 22:34:08 -0500 (EST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEG56452;
	Tue, 25 Nov 2003 22:34:07 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAQ3Y7J15174 for mpls@uu.net; Tue, 25 Nov 2003 22:34: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 QQpqks23773
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Nov 2003 03:33:14 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 QQpqks21570
	for <mpls@uu.net>; Wed, 26 Nov 2003 03:30: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 QQpqks05583
	for <mpls@uu.net>; Wed, 26 Nov 2003 03:30:43 GMT
Received: from sj-iport-4.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-4.cisco.com [171.68.10.86])
	id QQpqks05571
	for <mpls@uu.net>; Wed, 26 Nov 2003 03:30:43 GMT
Received: from dchengw2k (sjc-vpn3-54.cisco.com [10.21.64.54])
	by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hAQ3UdrX017065;
	Tue, 25 Nov 2003 19:30:40 -0800 (PST)
Reply-To: <dcheng@cisco.com>
From: "Dean Cheng \(dcheng\)" <dcheng@cisco.com>
To: "'Loa Andersson'" <loa@pi.se>
Cc: "'George Swallow'" <swallow@cisco.com>, "'Alex Zinin'" <zinin@psg.com>,
        "'MPLS wg'" <mpls@UU.NET>
Subject: RE: draft-yasukawa-mpls-p2mp-requirement-01.txt for working document?
Date: Tue, 25 Nov 2003 19:30:40 -0800
Message-ID: <000001c3b3cd$ab2804a0$6901a8c0@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
Importance: Normal
In-Reply-To: <3FC13CF1.2060802@pi.se>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

I support it.

Dean

>-----Original Message-----
>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf 
>Of Loa Andersson
>Sent: Sunday, November 23, 2003 3:04 PM
>To: MPLS wg
>Cc: George Swallow; Alex Zinin
>Subject: draft-yasukawa-mpls-p2mp-requirement-01.txt for 
>working document?
>
>
>All,
>
>we've been asked to make the
>
>draft-yasukawa-mpls-p2mp-requirement-01.txt
>
>an mpls working group documument. The draft were discussed
>in Minneapolis and there were support for making it a working 
>group document.
>
>Comments?
>
>/Loa
>
>
>-- 
>
>Loa Andersson
>
>mobile +46 739 81 21 64
>
>



From owner-mpls@UU.NET  Wed Nov 26 02:12: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 CAA10576
	for <mpls-archive@lists.ietf.org>; Wed, 26 Nov 2003 02:12: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 QQpqlg04565
	for <mpls-archive@lists.ietf.org>; Wed, 26 Nov 2003 07:12: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 QQpqlg04370;
	Wed, 26 Nov 2003 07:12:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqlf02915
	for mpls-outgoing; Wed, 26 Nov 2003 06:54: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 QQpqlf02910
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Nov 2003 06:54:20 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 QQpqlf19865
	for <mpls@UU.NET>; Wed, 26 Nov 2003 06:47: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 QQpqlf23184
	for <mpls@UU.NET>; Wed, 26 Nov 2003 06:47:06 GMT
Received: from web8001.mail.in.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web8001.mail.in.yahoo.com [203.199.70.95])
	id QQpqlf23151
	for <mpls@UU.NET>; Wed, 26 Nov 2003 06:47:05 GMT
Message-ID: <20031126064703.59875.qmail@web8001.mail.in.yahoo.com>
Received: from [203.200.20.226] by web8001.mail.in.yahoo.com via HTTP; Wed, 26 Nov 2003 06:47:03 GMT
Date: Wed, 26 Nov 2003 06:47:03 +0000 (GMT)
From: =?iso-8859-1?q?Harish=20Kumtakar?= <harishk16@yahoo.co.in>
Subject: explicit route configuration
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1098867151-1069829223=:57858"
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk

--0-1098867151-1069829223=:57858
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hello all,
 
I didn't find any configuration command in Cisco IOS to specify whether an explicit route is 'strict' or 'loose'. Other vendors like Riverstone Networks has such configuration commands, 
 
mpls create path <pathname>
mpls set path <pathname> [type loose | strict] ip-addr <ipaddr/netmask> [hop <index>]
 
Is it that Cisco doesn't have any command to specify an explicit route as 'strict/loose' or am I missing something?
 
Your help will highly be appreciated.
 
-Harish



 
Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more.Download now.
--0-1098867151-1069829223=:57858
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<LABEL id=HbSession SessionId="3238805497"></LABEL>
<DIV>Hello all,</DIV>
<DIV>&nbsp;</DIV>
<DIV>I didn't find any configuration command in Cisco IOS to specify whether an explicit route is 'strict' or 'loose'. Other vendors like Riverstone Networks has such configuration commands, </DIV>
<DIV>&nbsp;</DIV>
<DIV><EM>mpls create path &lt;pathname&gt;</EM></DIV>
<DIV><EM>mpls set path &lt;pathname&gt; [type loose | strict] ip-addr &lt;ipaddr/netmask&gt; [hop &lt;index&gt;]</EM></DIV>
<DIV><EM></EM>&nbsp;</DIV>
<DIV>Is it that Cisco doesn't have any command to specify an explicit route as 'strict/loose' or am I missing something?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Your help will highly be appreciated.</DIV>
<DIV>&nbsp;</DIV>
<DIV>-Harish</DIV><BR><BR><br> <p><font face=arial size=-1>
<a href="http://in.mobile.yahoo.com" target="_blank"><b>Yahoo! India Mobile</a>:</b> Ringtones, Wallpapers, Picture Messages and more.
<font face=arial size=-1>Download <a href="http://in.mobile.yahoo.com" target="_blank"><b>now</a></b>.</font>
--0-1098867151-1069829223=:57858--


From owner-mpls@UU.NET  Wed Nov 26 08:28: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 IAA06156
	for <mpls-archive@lists.ietf.org>; Wed, 26 Nov 2003 08:28: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 QQpqmf26624
	for <mpls-archive@lists.ietf.org>; Wed, 26 Nov 2003 13:28: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 QQpqmf26467;
	Wed, 26 Nov 2003 13:28:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqme08218
	for mpls-outgoing; Wed, 26 Nov 2003 13:13: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 QQpqme08198
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Nov 2003 13:13: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 QQpqme21638
	for <mpls@UU.NET>; Wed, 26 Nov 2003 13:08: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 QQpqme01919
	for <mpls@UU.NET>; Wed, 26 Nov 2003 13:08:37 GMT
Received: from cerberus.uk.clara.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cerberus.uk.clara.net [195.8.69.103])
	id QQpqme01909
	for <mpls@UU.NET>; Wed, 26 Nov 2003 13:08:36 GMT
Received: from du-069-0093.access.clara.net ([217.158.132.93] helo=Puppy)
	by cerberus.uk.clara.net with smtp (Exim 4.22)
	id 1AOzPH-000On2-Ab; Wed, 26 Nov 2003 13:08:35 +0000
Message-ID: <009a01c3b41e$6d8f9210$03849ed9@Puppy>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Vishal Sharma" <v.sharma@ieee.org>
Cc: "MPLS wg" <mpls@UU.NET>
References: <MMECLKMDFPCEJFECIBCMAEEADPAA.v.sharma@ieee.org>
Subject: Arbitrary TLVs in draft-farrel-mpls-rsvpte-attributes-00.txt 
Date: Wed, 26 Nov 2003 12:50:22 -0000
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.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Vishal,

> I support. There was one question raised by Adrian though that
> was not answered at the WG meeting, so it might be useful
> for us to consider on the list. It was "do we need a way to support
> arbitrary TLVs?"
>
> I believe this is one of the two solutions proposed in the
> draft, and it would be good to get WG opinion on that.

Actually, it is the only solution proposed in the draft. The 'need' for TLVs is a minor
corroborative reasons used to discard an alternative solution.

In the currently proposed solution, additional TLVs come for free.
We *could* simplify the current solution (by the order of a type and length field) and
dispense with arbitrary TLVs.

The authors felt that not taking the opportunity to add TLVs would be seen as a mistake in
future years.
The similar OSPF solution has TLVs I believe.

Would welcome more opinions.

Cheers,
Adrian



From owner-mpls@UU.NET  Wed Nov 26 08:57: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 IAA06857
	for <mpls-archive@lists.ietf.org>; Wed, 26 Nov 2003 08:57: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 QQpqmh01617
	for <mpls-archive@lists.ietf.org>; Wed, 26 Nov 2003 13:57: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 QQpqmh01509;
	Wed, 26 Nov 2003 13:57:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqmg09930
	for mpls-outgoing; Wed, 26 Nov 2003 13:43:54 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 QQpqmg09925
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Nov 2003 13:43:53 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 QQpqmg09458
	for <mpls@uu.net>; Wed, 26 Nov 2003 13:37:50 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 QQpqmg11728
	for <mpls@uu.net>; Wed, 26 Nov 2003 13:37:49 GMT
Received: from sj-iport-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-1-in.cisco.com [171.71.176.70])
	id QQpqmg11702
	for <mpls@uu.net>; Wed, 26 Nov 2003 13:37:49 GMT
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAQDbjAt014393
	for <mpls@uu.net>; Wed, 26 Nov 2003 05:37:45 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEG70986;
	Wed, 26 Nov 2003 08:37:43 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAQDbh320390 for mpls@uu.net; Wed, 26 Nov 2003 08:37:43 -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 QQpqmg09548
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Nov 2003 13: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 QQpqmg06186
	for <mpls@uu.net>; Wed, 26 Nov 2003 13:34: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 QQpqmg02902
	for <mpls@uu.net>; Wed, 26 Nov 2003 13:34:11 GMT
Received: from sj-iport-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72])
	id QQpqmg02892
	for <mpls@uu.net>; Wed, 26 Nov 2003 13:34:11 GMT
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-3.cisco.com with ESMTP; 26 Nov 2003 05:35:54 +0000
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAQDY8At012274;
	Wed, 26 Nov 2003 05:34:09 -0800 (PST)
Received: from jvasseur-w2k01.cisco.com (sjc-vpn4-419.cisco.com [10.21.81.163]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA21249; Wed, 26 Nov 2003 05:34:07 -0800 (PST)
Message-Id: <4.3.2.7.2.20031126083323.04b096c8@wells.cisco.com>
X-Sender: jvasseur@wells.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 26 Nov 2003 08:34:07 -0500
To: "Adrian Farrel" <adrian@olddog.co.uk>
From: Jean Philippe Vasseur <jvasseur@cisco.com>
Subject: Re: Arbitrary TLVs in
  draft-farrel-mpls-rsvpte-attributes-00.txt 
Cc: "Vishal Sharma" <v.sharma@ieee.org>, "MPLS wg" <mpls@UU.NET>
In-Reply-To: <009a01c3b41e$6d8f9210$03849ed9@Puppy>
References: <MMECLKMDFPCEJFECIBCMAEEADPAA.v.sharma@ieee.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Adrian,

At 12:50 PM 11/26/2003 +0000, Adrian Farrel wrote:
>Hi Vishal,
>
> > I support. There was one question raised by Adrian though that
> > was not answered at the WG meeting, so it might be useful
> > for us to consider on the list. It was "do we need a way to support
> > arbitrary TLVs?"
> >
> > I believe this is one of the two solutions proposed in the
> > draft, and it would be good to get WG opinion on that.
>
>Actually, it is the only solution proposed in the draft. The 'need' for 
>TLVs is a minor
>corroborative reasons used to discard an alternative solution.
>
>In the currently proposed solution, additional TLVs come for free.
>We *could* simplify the current solution (by the order of a type and 
>length field) and
>dispense with arbitrary TLVs.
>
>The authors felt that not taking the opportunity to add TLVs would be seen 
>as a mistake in
>future years.
>The similar OSPF solution has TLVs I believe.

absolutely right; by the way, we already found a few interesting uses of 
them for the IGP.

Cheers

JP.

>Would welcome more opinions.
>
>Cheers,
>Adrian



From owner-mpls@UU.NET  Wed Nov 26 16:02:55 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 QAA28214
	for <mpls-archive@lists.ietf.org>; Wed, 26 Nov 2003 16:02:54 -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 QQpqnk27136
	for <mpls-archive@lists.ietf.org>; Wed, 26 Nov 2003 21:03: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 QQpqnk26803;
	Wed, 26 Nov 2003 21:02:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqni26141
	for mpls-outgoing; Wed, 26 Nov 2003 20:35: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 QQpqni26132
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Nov 2003 20:35:48 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 QQpqni20708
	for <mpls@UU.NET>; Wed, 26 Nov 2003 20:34: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 QQpqni12020
	for <mpls@UU.NET>; Wed, 26 Nov 2003 20:34:17 GMT
Received: from smtp106.mail.sc5.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: smtp106.mail.sc5.yahoo.com [66.163.169.226])
	id QQpqni12001
	for <mpls@UU.NET>; Wed, 26 Nov 2003 20:34:16 GMT
Received: from adsl-63-206-94-144.dsl.snfc21.pacbell.net (HELO RAKHILAPTOP) (vsharma87@63.206.94.144 with login)
  by smtp-v1.mail.vip.sc5.yahoo.com with SMTP; 26 Nov 2003 20:34:15 -0000
From: "Vishal Sharma" <v.sharma@ieee.org>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: "MPLS wg" <mpls@UU.NET>
Subject: RE: Arbitrary TLVs in draft-farrel-mpls-rsvpte-attributes-00.txt 
Date: Wed, 26 Nov 2003 12:34:13 -0800
Message-ID: <MMECLKMDFPCEJFECIBCMIEENDPAA.v.sharma@ieee.org>
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)
In-Reply-To: <009a01c3b41e$6d8f9210$03849ed9@Puppy>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Adrian,

Thanks for the clarification. I think I misunderstood your
question during the MPLS WG meeting then.

(I think what you mentioned was that with TLVs it is possible
to either (a) define new 32-bit flags, as needed, or (b) define arbitrary
options and parameters that would be carried as TLVs, and you asked,
referring to the entire scheme, whether the WG thought we need
a way to support arbitrary TVLs. 

I misunderstood it to refer to just the second option for encoding 
attributes within the TLVs defined for carrying new attributes.)

I get your point now, and support the overall TLV approach proposed
in the document.

-Vishal

> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Adrian
> Farrel
> Sent: Wednesday, November 26, 2003 4:50 AM
> To: Vishal Sharma
> Cc: MPLS wg
> Subject: Arbitrary TLVs in draft-farrel-mpls-rsvpte-attributes-00.txt 
> 
> 
> Hi Vishal,
> 
> > I support. There was one question raised by Adrian though that
> > was not answered at the WG meeting, so it might be useful
> > for us to consider on the list. It was "do we need a way to support
> > arbitrary TLVs?"
> >
> > I believe this is one of the two solutions proposed in the
> > draft, and it would be good to get WG opinion on that.
> 
> Actually, it is the only solution proposed in the draft. The 
> 'need' for TLVs is a minor
> corroborative reasons used to discard an alternative solution.
> 
> In the currently proposed solution, additional TLVs come for free.
> We *could* simplify the current solution (by the order of a type 
> and length field) and
> dispense with arbitrary TLVs.
> 
> The authors felt that not taking the opportunity to add TLVs 
> would be seen as a mistake in
> future years.
> The similar OSPF solution has TLVs I believe.
> 
> Would welcome more opinions.
> 
> Cheers,
> Adrian


From owner-mpls@UU.NET  Thu Nov 27 02:07: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 CAA22569
	for <mpls-archive@lists.ietf.org>; Thu, 27 Nov 2003 02:07: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 QQpqoy12322
	for <mpls-archive@lists.ietf.org>; Thu, 27 Nov 2003 07:07: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 QQpqoy12012;
	Thu, 27 Nov 2003 07:07:39 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqow28543
	for mpls-outgoing; Thu, 27 Nov 2003 06:44: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 QQpqow28538
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Nov 2003 06:44: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 QQpqow17846
	for <mpls@UU.NET>; Thu, 27 Nov 2003 06:41: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 QQpqow12244
	for <mpls@UU.NET>; Thu, 27 Nov 2003 06:41:26 GMT
Received: from adelphia.gblx.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: adelphia.gblx.net [64.213.46.66])
	id QQpqow12226
	for <mpls@UU.NET>; Thu, 27 Nov 2003 06:41:25 GMT
Received: from adelphia.gblx.net (localhost [127.0.0.1])
	by adelphia.gblx.net (8.12.9p2/8.12.9) with ESMTP id hAR7aZUA039982;
	Wed, 26 Nov 2003 23:36:36 -0800 (PST)
	(envelope-from cooper@nitrous.net)
Received: (from cooper@localhost)
	by adelphia.gblx.net (8.12.9p2/8.12.9/Submit) id hAR7aY5Y039981;
	Wed, 26 Nov 2003 23:36:34 -0800 (PST)
	(envelope-from cooper@nitrous.net)
X-Authentication-Warning: adelphia.gblx.net: cooper set sender to cooper@nitrous.net using -f
Date: Wed, 26 Nov 2003 23:36:34 -0800
From: Dave Cooper <cooper@nitrous.net>
To: Loa Andersson <loa@pi.se>
Cc: MPLS wg <mpls@UU.NET>, George Swallow <swallow@cisco.com>,
        Alex Zinin <zinin@psg.com>
Subject: Re: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document
Message-ID: <20031127073634.GA39900@nitrous.net>
References: <3FC13EA6.6030305@pi.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3FC13EA6.6030305@pi.se>
User-Agent: Mutt/1.4.1i
Sender: owner-mpls@UU.NET
Precedence: bulk

in favor

-dave

On Mon, Nov 24, 2003 at 12:11:34AM +0100, Loa Andersson wrote:
> All,
> 
> we been asked to make
> 
> draft-farrel-mpls-rsvpte-attributes-00.txt
> 
> an mpls working document. The document were discussed in
> Minneapolis, the room was undecided if we should go
> forward with the document. No opposition, but also no
> strongly voiced support.
> 
> Therefore we would like both those in favor and those
> opposed to making this a working group document to
> speak up.
> 
> /Loa
> 
> -- 
> 
> Loa Andersson
> 
> mobile +46 739 81 21 64
> 


From owner-mpls@UU.NET  Fri Nov 28 05:12: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 FAA21632
	for <mpls-archive@lists.ietf.org>; Fri, 28 Nov 2003 05:12:24 -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 QQpqtc04677
	for <mpls-archive@lists.ietf.org>; Fri, 28 Nov 2003 10:12: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 QQpqtc04501;
	Fri, 28 Nov 2003 10:12:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqtb20432
	for mpls-outgoing; Fri, 28 Nov 2003 09:52:03 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 QQpqtb20405
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Nov 2003 09:51: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 QQpqtb18837
	for <mpls@UU.NET>; Fri, 28 Nov 2003 09:51: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 QQpqtb05293
	for <mpls@UU.NET>; Fri, 28 Nov 2003 09:51:00 GMT
Received: from relhubc02-ukbr.tcrelay.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [217.32.166.20])
	id QQpqtb05272
	for <mpls@UU.NET>; Fri, 28 Nov 2003 09:51:00 GMT
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC;
	 Fri, 28 Nov 2003 09:45:10 +0000
Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713);
	 Wed, 26 Nov 2003 20:55:19 +0000
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQpqnk24236
	for <pjw@ip-engineering.bt.com>; Wed, 26 Nov 2003 21:01: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 QQpqnk23928;
	Wed, 26 Nov 2003 21:00:59 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqni26141
	for mpls-outgoing; Wed, 26 Nov 2003 20:35: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 QQpqni26132
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Nov 2003 20:35:48 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 QQpqni20708
	for <mpls@UU.NET>; Wed, 26 Nov 2003 20:34: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 QQpqni12020
	for <mpls@UU.NET>; Wed, 26 Nov 2003 20:34:17 GMT
Received: from smtp106.mail.sc5.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: smtp106.mail.sc5.yahoo.com [66.163.169.226])
	id QQpqni12001
	for <mpls@UU.NET>; Wed, 26 Nov 2003 20:34:16 GMT
Received: from adsl-63-206-94-144.dsl.snfc21.pacbell.net (HELO RAKHILAPTOP) (vsharma87@63.206.94.144 with login)
  by smtp-v1.mail.vip.sc5.yahoo.com with SMTP; 26 Nov 2003 20:34:15 -0000
From: "Vishal Sharma" <v.sharma@ieee.org>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: "MPLS wg" <mpls@UU.NET>
Subject: RE: Arbitrary TLVs in draft-farrel-mpls-rsvpte-attributes-00.txt 
Date: Wed, 26 Nov 2003 12:34:13 -0800
Message-ID: <MMECLKMDFPCEJFECIBCMIEENDPAA.v.sharma@ieee.org>
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)
In-Reply-To: <009a01c3b41e$6d8f9210$03849ed9@Puppy>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 26 Nov 2003 20:55:19.0234 (UTC) FILETIME=[99D60A20:01C3B45F]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Adrian,

Thanks for the clarification. I think I misunderstood your
question during the MPLS WG meeting then.

(I think what you mentioned was that with TLVs it is possible
to either (a) define new 32-bit flags, as needed, or (b) define arbitrary
options and parameters that would be carried as TLVs, and you asked,
referring to the entire scheme, whether the WG thought we need
a way to support arbitrary TVLs. 

I misunderstood it to refer to just the second option for encoding 
attributes within the TLVs defined for carrying new attributes.)

I get your point now, and support the overall TLV approach proposed
in the document.

-Vishal

> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Adrian
> Farrel
> Sent: Wednesday, November 26, 2003 4:50 AM
> To: Vishal Sharma
> Cc: MPLS wg
> Subject: Arbitrary TLVs in draft-farrel-mpls-rsvpte-attributes-00.txt 
> 
> 
> Hi Vishal,
> 
> > I support. There was one question raised by Adrian though that
> > was not answered at the WG meeting, so it might be useful
> > for us to consider on the list. It was "do we need a way to support
> > arbitrary TLVs?"
> >
> > I believe this is one of the two solutions proposed in the
> > draft, and it would be good to get WG opinion on that.
> 
> Actually, it is the only solution proposed in the draft. The 
> 'need' for TLVs is a minor
> corroborative reasons used to discard an alternative solution.
> 
> In the currently proposed solution, additional TLVs come for free.
> We *could* simplify the current solution (by the order of a type 
> and length field) and
> dispense with arbitrary TLVs.
> 
> The authors felt that not taking the opportunity to add TLVs 
> would be seen as a mistake in
> future years.
> The similar OSPF solution has TLVs I believe.
> 
> Would welcome more opinions.
> 
> Cheers,
> Adrian


From owner-mpls@UU.NET  Fri Nov 28 05:12: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 FAA21648
	for <mpls-archive@lists.ietf.org>; Fri, 28 Nov 2003 05:12: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 QQpqtc05308
	for <mpls-archive@lists.ietf.org>; Fri, 28 Nov 2003 10:13: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 QQpqtc05115;
	Fri, 28 Nov 2003 10:13:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqtb20393
	for mpls-outgoing; Fri, 28 Nov 2003 09:51: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 QQpqtb20383
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Nov 2003 09:51: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 QQpqtb19885
	for <mpls@UU.NET>; Fri, 28 Nov 2003 09:51: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 QQpqtb14258
	for <mpls@UU.NET>; Fri, 28 Nov 2003 09:51:10 GMT
Received: from relhubc02-ukbr.tcrelay.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [217.32.166.20])
	id QQpqtb14237
	for <mpls@UU.NET>; Fri, 28 Nov 2003 09:51:09 GMT
Received: from mail pickup service by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC;
	 Fri, 28 Nov 2003 09:45:19 +0000
Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713);
	 Wed, 26 Nov 2003 17:49:21 +0000
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQpqmf27941
	for <adrian@msn.bt.co.uk>; Wed, 26 Nov 2003 13:29:32 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 QQpqmf27922;
	Wed, 26 Nov 2003 13:29:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqme08218
	for mpls-outgoing; Wed, 26 Nov 2003 13:13: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 QQpqme08198
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Nov 2003 13:13: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 QQpqme21638
	for <mpls@UU.NET>; Wed, 26 Nov 2003 13:08: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 QQpqme01919
	for <mpls@UU.NET>; Wed, 26 Nov 2003 13:08:37 GMT
Received: from cerberus.uk.clara.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cerberus.uk.clara.net [195.8.69.103])
	id QQpqme01909
	for <mpls@UU.NET>; Wed, 26 Nov 2003 13:08:36 GMT
Received: from du-069-0093.access.clara.net ([217.158.132.93] helo=Puppy)
	by cerberus.uk.clara.net with smtp (Exim 4.22)
	id 1AOzPH-000On2-Ab; Wed, 26 Nov 2003 13:08:35 +0000
Message-ID: <009a01c3b41e$6d8f9210$03849ed9@Puppy>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Vishal Sharma" <v.sharma@ieee.org>
Cc: "MPLS wg" <mpls@UU.NET>
References: <MMECLKMDFPCEJFECIBCMAEEADPAA.v.sharma@ieee.org>
Subject: Arbitrary TLVs in draft-farrel-mpls-rsvpte-attributes-00.txt 
Date: Wed, 26 Nov 2003 12:50:22 -0000
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.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-OriginalArrivalTime: 26 Nov 2003 17:49:21.0238 (UTC) FILETIME=[9F26F760:01C3B445]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Vishal,

> I support. There was one question raised by Adrian though that
> was not answered at the WG meeting, so it might be useful
> for us to consider on the list. It was "do we need a way to support
> arbitrary TLVs?"
>
> I believe this is one of the two solutions proposed in the
> draft, and it would be good to get WG opinion on that.

Actually, it is the only solution proposed in the draft. The 'need' for TLVs is a minor
corroborative reasons used to discard an alternative solution.

In the currently proposed solution, additional TLVs come for free.
We *could* simplify the current solution (by the order of a type and length field) and
dispense with arbitrary TLVs.

The authors felt that not taking the opportunity to add TLVs would be seen as a mistake in
future years.
The similar OSPF solution has TLVs I believe.

Would welcome more opinions.

Cheers,
Adrian



From owner-mpls@UU.NET  Fri Nov 28 10:09: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 KAA00681
	for <mpls-archive@lists.ietf.org>; Fri, 28 Nov 2003 10:09: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 QQpqtw05269
	for <mpls-archive@lists.ietf.org>; Fri, 28 Nov 2003 15: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 QQpqtw05115;
	Fri, 28 Nov 2003 15:09:46 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqtv21134
	for mpls-outgoing; Fri, 28 Nov 2003 14:48:54 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 QQpqtv21129
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Nov 2003 14:48: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 QQpqtv04428
	for <mpls@uu.net>; Fri, 28 Nov 2003 14:48: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 QQpqtv08788
	for <mpls@uu.net>; Fri, 28 Nov 2003 14:48:21 GMT
Received: from mail2.hyperchip.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail2.hyperchip.com [216.94.112.4])
	id QQpqtv08777
	for <mpls@uu.net>; Fri, 28 Nov 2003 14:48:20 GMT
Received: from hermes.hyperchip.com ([10.0.0.12] helo=hermes.hypernet.com)
	by mail2.hyperchip.com with esmtp (Exim 3.22 #1)
	id 1APjum-0005XE-00; Fri, 28 Nov 2003 09:48:12 -0500
Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2653.19)
	id <XXHC5JZ2>; Fri, 28 Nov 2003 09:44:34 -0500
Message-ID: <8812A03F65CDD511AE98006008F5E8710677E27D@hermes.hyperchip.com>
From: Philip Matthews <pmatthews@hyperchip.com>
To: Loa Andersson <loa@pi.se>
Cc: MPLS wg <mpls@UU.NET>
Subject: RE: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document
Date: Fri, 28 Nov 2003 09:44:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B5BE.23487270"
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_01C3B5BE.23487270
Content-Type: text/plain;
	charset="iso-8859-1"

I am in favor.

- Philip

-----Original Message-----
From: Loa Andersson [mailto:loa@pi.se]
Sent: November 23, 2003 18:12
To: MPLS wg
Cc: George Swallow; Alex Zinin
Subject: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document


All,

we been asked to make

draft-farrel-mpls-rsvpte-attributes-00.txt

an mpls working document. The document were discussed in
Minneapolis, the room was undecided if we should go
forward with the document. No opposition, but also no
strongly voiced support.

Therefore we would like both those in favor and those
opposed to making this a working group document to
speak up.

/Loa

-- 

Loa Andersson

mobile +46 739 81 21 64



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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I am in favor.</FONT>
</P>

<P><FONT SIZE=2>- Philip</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Loa Andersson [<A HREF="mailto:loa@pi.se">mailto:loa@pi.se</A>]</FONT>
<BR><FONT SIZE=2>Sent: November 23, 2003 18:12</FONT>
<BR><FONT SIZE=2>To: MPLS wg</FONT>
<BR><FONT SIZE=2>Cc: George Swallow; Alex Zinin</FONT>
<BR><FONT SIZE=2>Subject: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document</FONT>
</P>
<BR>

<P><FONT SIZE=2>All,</FONT>
</P>

<P><FONT SIZE=2>we been asked to make</FONT>
</P>

<P><FONT SIZE=2>draft-farrel-mpls-rsvpte-attributes-00.txt</FONT>
</P>

<P><FONT SIZE=2>an mpls working document. The document were discussed in</FONT>
<BR><FONT SIZE=2>Minneapolis, the room was undecided if we should go</FONT>
<BR><FONT SIZE=2>forward with the document. No opposition, but also no</FONT>
<BR><FONT SIZE=2>strongly voiced support.</FONT>
</P>

<P><FONT SIZE=2>Therefore we would like both those in favor and those</FONT>
<BR><FONT SIZE=2>opposed to making this a working group document to</FONT>
<BR><FONT SIZE=2>speak up.</FONT>
</P>

<P><FONT SIZE=2>/Loa</FONT>
</P>

<P><FONT SIZE=2>-- </FONT>
</P>

<P><FONT SIZE=2>Loa Andersson</FONT>
</P>

<P><FONT SIZE=2>mobile +46 739 81 21 64</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C3B5BE.23487270--


From owner-mpls@UU.NET  Sun Nov 30 01:09: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 BAA09589
	for <mpls-archive@lists.ietf.org>; Sun, 30 Nov 2003 01:09: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 QQpqzw15389
	for <mpls-archive@lists.ietf.org>; Sun, 30 Nov 2003 06:09: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 QQpqzw15009;
	Sun, 30 Nov 2003 06:09:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqzv29591
	for mpls-outgoing; Sun, 30 Nov 2003 05:48:59 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 QQpqzv29586
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 30 Nov 2003 05:48:58 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 QQpqzv27566
	for <mpls@uu.net>; Sun, 30 Nov 2003 05:47: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 QQpqzv06625
	for <mpls@uu.net>; Sun, 30 Nov 2003 05:47:48 GMT
Received: from sj-iport-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72])
	id QQpqzv06605
	for <mpls@uu.net>; Sun, 30 Nov 2003 05:47:47 GMT
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-3.cisco.com with ESMTP; 29 Nov 2003 21:50:14 +0000
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAU5lhw5012974
	for <mpls@uu.net>; Sat, 29 Nov 2003 21:47:44 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEH74501;
	Sun, 30 Nov 2003 00:47:42 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAU5lgQ13243 for mpls@uu.net; Sun, 30 Nov 2003 00:47:42 -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 QQpqob26497
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Nov 2003 01:26:19 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 QQpqob07159
	for <mpls@uu.net>; Thu, 27 Nov 2003 01:20:39 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 QQpqob20502
	for <mpls@uu.net>; Thu, 27 Nov 2003 01:20:39 GMT
Received: from mail2.microsoft.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail2.microsoft.com [131.107.3.124])
	id QQpqob20479
	for <mpls@uu.net>; Thu, 27 Nov 2003 01:20:38 GMT
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041);
	 Wed, 26 Nov 2003 17:20:34 -0800
Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 26 Nov 2003 17:20:19 -0800
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0);
	 Wed, 26 Nov 2003 17:20:36 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0);
	 Wed, 26 Nov 2003 17:20:37 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069);
	 Wed, 26 Nov 2003 17:20:39 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: DT's review of draft-ietf-mpls-telink-mib-04.txt
Date: Wed, 26 Nov 2003 17:20:25 -0800
Message-ID: <C9588551DE135A41AA2626CB6453093704759F78@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: DT's review of draft-ietf-mpls-telink-mib-04.txt
Thread-Index: AcOZCm7MTWL3ZrgeSnCx0ysiDVDnmAbc800w
From: "Dave Thaler" <dthaler@windows.microsoft.com>
To: "Mpls \(E-mail\)" <mpls@UU.NET>
Cc: "Bert Wijnen" <bwijnen@lucent.com>
X-OriginalArrivalTime: 27 Nov 2003 01:20:39.0354 (UTC) FILETIME=[AAF791A0:01C3B484]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Bert asked me to post the current status of the telink-mib discussion.
Since a new version hasn't been submitted since my initial review, I'll=20
briefly summarize where I think we are on draft-04.

1) Relationship between teLinkLocalIpAddr and ipAddrTable needs to be
   clarified, and authors agreed.

   On Oct. 22, 2003, Martin Dubuc wrote:
   > I will add text in the DESCIRPTION clause to emphasize the=20
   > relationship between teLinkLocalIpAddr and ipAddrTable.

2) teLinkIncomingIfId should have=20
        SYNTAX Integer32 (0..2147483647)
   instead of
        SYNTAX InterfaceIndexOrZero

    On Oct. 6, 2003, Martin wrote:
    > I can make this change.

3) teLink{Outgoing,Incoming}IfId descriptions should be more clear:
           "If the link is unnumbered, the outgoing interface identifier
is
            set to the outgoing interface identifier chosen for the TE
link
            by the advertising LSR. For numbered links, the address is
            stored in the teLinkLocalIpAddr instead."
    It is unclear what is meant by "instead".  If the value here should=20
    be 0, say that explicitly, as in:
           "If the link is unnumbered, the outgoing interface identifier
is
            set to the outgoing interface identifier chosen for the TE
link
            by the advertising LSR. If the link is numbered, the value
is
            0."

    On Oct. 6, 2003, Martin wrote:
    > I can be explicit as you suggest.

4) Requirements from section 4 of RFC 2863 not met yet in section 8 are:

   ifRcvAddressTable
      The media-specific MIB designer MUST specify the applicability of
      the ifRcvAddressTable.

   ifXxxOctets
      The definitions of ifInOctets and ifOutOctets (and similarly,
      ifHCInOctets and ifHCOutOctets) specify that their values include
      framing characters.  The media-specific MIB designer MUST specify
      any special conditions of the media concerning the inclusion of
      framing characters, especially with respect to frames with errors.

   I have seen no response from the authors yet on this point.

5) On the topic of extending the tunnel MIB, I believe everyone agreed=20
   on the following points:

    a) Some objects are redundant with the IP Tunnel MIB (RFC 2667) in=20
       the case where the MPLS TE link is a tunnel over IPv4.  These=20
       redundant objects are useful when the agent does not support the=20
       IP tunnel MIB, or when the tunnel is over IPv6, which is not yet=20
       handled by 2667.

    b) Regardless of what happens with this MIB, RFC 2667 should be
updated
       to handle IPv6.  (This was done,
draft-thaler-inet-tunnel-mib-00.txt
       was posted to the ifmib and ipv6 lists, presented in the IPv6 WG
       in Minneapolis and was accepted as an IPv6 WG item since the
IFMIB
       WG is closed.)

    c) It would be good to be done with the MPLS TE link MIB now and
       not be blocked on any other document.

   To briefly change the subject to an analogous issue, Kireeti, Bert,=20
   and I met at IETF to talk about a similar issue in the TEWG MIB.
   We concluded that the best answer was to allow the MIB to be used
   both for tunnels (where it can logically extend the tunnel MIB)
   as well as for non-tunnel objects, where it does not extend the
   tunnel MIB.  This can be done in such a way as to not change anything
   in the MIB definition itself, just the intro text in the document.
  =20
   I think this same solution can be used in the MPLS TElink MIB, and=20
   hence solve the problems of not being able extend the tunnel MIB=20
   when an agent supports it.

   Hence we could add a small subsection to section 8 along the lines
of:

    8.1 Application of the IP Tunnel MIB to TE Links
=20
    The IP Tunnel MIB [RFC2667] defines managed objects for managing=20
    tunnels over IP. For TE Link interfaces which correspond to tunnels=20
    over IP, an agent supporting the IP Tunnel MIB would have entries in

    that MIB for TE tunnels. Interfaces in the IP Tunnel MIB use ifType
=3D=20
    tunnel (131), and have a subtype identifying the actual
encapsulation=20
    method.  Hence, in the case where MPLS is using a single TE tunnel=20
    link, the interface stack might appear as (for example):
=20
        +-----------------------------------+
        | MPLS interface ifType =3D mpls(166) |
        +-----------------------------------+
        | Tunnel link ifType =3D tunnel(131)  |
        +-----------------------------------+
        | Underlying Layer...               |
        | ifType =3D ethernetCsmacd(6)        |
        +-----------------------------------+

   [Note: I'm not sure whether the above stack is correct, since I'm
   not sure what data encapsulation is used on the wire.  The above
   stack would be correct if an actual data packet on the wire looked
like:

      Ethernet - Outer IPv4 - MPLS - Inner IPv4 - payload=20

   If the packet looks different, the stack would be different.]

   Also update the DESCRIPTION clauses of teLinkEntry,=20
   teLinkDescriptorEntry, teLinkSrlgEntry, teLinkBandwidthEntry
   which all say ifType must be 200, to say 200 or 131.

   This would allow the TE link mib to be used both ways, and hence
   allow the benefits of the tunnel MIB, without requiring it or any
   other changes to an existing implementation.

   The alternative would be to publish without this now and rev the=20
   TE Link MIB at the same time as the Inet Tunnel MIB would go to RFC.

-Dave



From owner-mpls@UU.NET  Sun Nov 30 01:11: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 BAA09638
	for <mpls-archive@lists.ietf.org>; Sun, 30 Nov 2003 01:11: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 QQpqzw05349
	for <mpls-archive@lists.ietf.org>; Sun, 30 Nov 2003 06:11: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 QQpqzw04307;
	Sun, 30 Nov 2003 06:10:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqzv29644
	for mpls-outgoing; Sun, 30 Nov 2003 05:50: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 QQpqzv29639
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 30 Nov 2003 05:50: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 QQpqzv26560
	for <mpls@uu.net>; Sun, 30 Nov 2003 05:48:39 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 QQpqzv27858
	for <mpls@uu.net>; Sun, 30 Nov 2003 05:48:38 GMT
Received: from sj-iport-3.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72])
	id QQpqzv26354
	for <mpls@uu.net>; Sun, 30 Nov 2003 05:48:25 GMT
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 29 Nov 2003 21:50:09 +0000
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAU5ldjq026315
	for <mpls@uu.net>; Sat, 29 Nov 2003 21:47:40 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEH74499;
	Sun, 30 Nov 2003 00:47:38 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAU5lcO13235 for mpls@uu.net; Sun, 30 Nov 2003 00:47:38 -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 QQpqlm16731
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Nov 2003 08:38: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 QQpqlm14346
	for <mpls@UU.NET>; Wed, 26 Nov 2003 08:36:15 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 QQpqlm11735
	for <mpls@UU.NET>; Wed, 26 Nov 2003 08:36:14 GMT
Received: from linda-1.paradise.net.nz by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: bm-1a.paradise.net.nz [202.0.58.20])
	id QQpqlm11575
	for <mpls@UU.NET>; Wed, 26 Nov 2003 08:36:08 GMT
Received: from smtp-3.paradise.net.nz (smtp-3a.paradise.net.nz [202.0.32.196])
 by linda-1.paradise.net.nz (Paradise.net.nz)
 with ESMTP id <0HOY00IZMAK6UP@linda-1.paradise.net.nz> for mpls@UU.NET; Wed,
 26 Nov 2003 21:36:06 +1300 (NZDT)
Received: from advancepts.co.nz
 (203-79-119-214.cable.paradise.net.nz [203.79.119.214])
	by smtp-3.paradise.net.nz (Postfix) with ESMTP	id 9EFDBADF3B; Wed,
 26 Nov 2003 21:36:06 +1300 (NZDT)
Date: Wed, 26 Nov 2003 20:39:27 +1300 (NZDT)
From: Francois Prowse <fp@prowse.co.nz>
Subject: Re: LDP-MIB
In-reply-to: <3.0.1.32.20031125214842.01269d34@pop.mindspring.com>
X-X-Sender: fprowse@linux-wlg.prowse.co.nz
To: jcucchiara@mindspring.com
Cc: Francois Prowse <fp@prowse.co.nz>, mpls@UU.NET
Message-id: <Pine.LNX.4.44.0311262038590.22556-100000@linux-wlg.prowse.co.nz>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Thanks - much appreciated.....I had a feeling that this may have been 
renamed! 

Thanks for you help...

regards

Francois

On Tue, 25 Nov 2003 jcucchiara@mindspring.com wrote:

> 
> Hello Francois, 
> 
> mplsLdpSesState has been renamed to mplsLdpSessionState.
> 
> mplsLdpSessionState OBJECT-TYPE
>          SYNTAX      INTEGER {
>                         nonexistent(1),
>                         initialized(2),
>                         openrec(3),
>                         opensent(4),
>                         operational(5)
>                      }
>          MAX-ACCESS  read-only
>          STATUS      current
>          DESCRIPTION
>              "The current state of the session, all of the
>              states 1 to 5 are based on the state machine
>              for session negotiation behavior."
>          REFERENCE
>              "RFC3036, LDP Specification, Section 2.5.4,
>              Initialization State Machine."
>          ::= { mplsLdpSessionEntry 2 }
> 
> 
> 
> The references to "mplsLdpSesState" are in the area which
> describes changes to the MIB from revision to revision.
> This section is going away when the draft becomes an RFC.
> 
>    -Joan
> 
> 
> 
> At 11:47 AM 11/25/03 +1300, Francois Prowse wrote:
> >Hell, looking at the design of draft-ietf-mpls-ldp-mib-14.txt it refers to 
> >mplsLdpSesState. I'm trying to find the MIB that this is actually 
> >described in, anyone able to point me in the right direction?
> >
> >re
> >
> >Francois
> >
> >
> >-- 
> >
> >
> >
> 

-- 




From owner-mpls@UU.NET  Sun Nov 30 01:11: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 BAA09654
	for <mpls-archive@lists.ietf.org>; Sun, 30 Nov 2003 01:11: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 QQpqzw27757
	for <mpls-archive@lists.ietf.org>; Sun, 30 Nov 2003 06:11: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 QQpqzw27260;
	Sun, 30 Nov 2003 06:11:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqzv29681
	for mpls-outgoing; Sun, 30 Nov 2003 05:50: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 QQpqzv29673
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 30 Nov 2003 05:50:27 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 QQpqzv13723
	for <mpls@uu.net>; Sun, 30 Nov 2003 05:47: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 QQpqzv06573
	for <mpls@uu.net>; Sun, 30 Nov 2003 05:47:45 GMT
Received: from sj-iport-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72])
	id QQpqzv06562
	for <mpls@uu.net>; Sun, 30 Nov 2003 05:47:45 GMT
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-3.cisco.com with ESMTP; 29 Nov 2003 21:50:11 +0000
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAU5lfAt007992
	for <mpls@uu.net>; Sat, 29 Nov 2003 21:47:42 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEH74500;
	Sun, 30 Nov 2003 00:47:40 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAU5leV13239 for mpls@uu.net; Sun, 30 Nov 2003 00:47:40 -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 QQpqml04162
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Nov 2003 14:56: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 QQpqmk15265
	for <mpls@UU.NET>; Wed, 26 Nov 2003 14:41:45 GMT
From: ting_wo.chung@bell.ca
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQpqmk24833
	for <mpls@UU.NET>; Wed, 26 Nov 2003 14:41:44 GMT
Received: from dm3cnd.bell.ca by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dm3cnd.bell.ca [206.47.0.146])
	id QQpqmk24817
	for <mpls@UU.NET>; Wed, 26 Nov 2003 14:41:44 GMT
Received: from 142.182.89.88dm3cnd.bell.ca with ESMTP (Tumbleweed MMS
 SMTP Relay (MMS v5.0)); Wed, 26 Nov 2003 09:38:41 -0500
X-Server-Uuid: F7F6AAF0-A437-4F8E-BDFA-B18CACF73C6B
Received: from TOROONDC913.bell.corp.bce.ca ([142.182.89.16]) by
 TOROONDC908.bell.corp.bce.ca with Microsoft SMTPSVC(5.0.2195.6713);
 Wed, 26 Nov 2003 09:38:41 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: explicit route configuration
Date: Wed, 26 Nov 2003 09:38:41 -0500
Message-ID: <C4499BC97DB92847814A144A3AED0E26A8AAF2@toroondc913.bell.corp.bce.ca>
Thread-Topic: explicit route configuration
Thread-Index: AcOz7K521bqxei98S8SyiNPlyvjECQAPhoMQ
To: harishk16@yahoo.co.in, mpls@UU.NET
X-OriginalArrivalTime: 26 Nov 2003 14:38:41.0434 (UTC)
 FILETIME=[FC7F67A0:01C3B42A]
X-WSS-ID: 13DA657B562030-01-01
Content-Type: multipart/alternative;
 boundary="----_=_NextPart_001_01C3B42A.FC625D6C"
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01C3B42A.FC625D6C
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: quoted-printable

it is specified as "next-address loose" under the "ip explicit-path"
section.....

	-----Original Message-----
	From: Harish Kumtakar [mailto:harishk16@yahoo.co.in]=20
	Sent: November 26, 2003 1:47 AM
	To: mpls@UU.NET
	Subject: explicit route configuration
=09
=09
	=20
	Hello all,
	=20
	I didn't find any configuration command in Cisco IOS to specify
whether an explicit route is 'strict' or 'loose'. Other vendors like
Riverstone Networks has such configuration commands,=20
	=20
	mpls create path <pathname>
	mpls set path <pathname> [type loose | strict] ip-addr
<ipaddr/netmask> [hop <index>]
	=20
	Is it that Cisco doesn't have any command to specify an explicit
route as 'strict/loose' or am I missing something?
	=20
	Your help will highly be appreciated.
	=20
	-Harish




	Yahoo! India Mobile <http://in.mobile.yahoo.com> : Ringtones,
Wallpapers, Picture Messages and more. Download now
<http://in.mobile.yahoo.com> .


------_=_NextPart_001_01C3B42A.FC625D6C
Content-Type: text/html;
 charset=us-ascii
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2722.900" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D231143714-26112003><FONT face=3D"Georgia Ref" =
color=3D#0000ff=20
size=3D2>it is specified as "next-address loose" under the "ip =
explicit-path"=20
section.....</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Harish Kumtakar=20
  [mailto:harishk16@yahoo.co.in] <BR><B>Sent:</B> November 26, 2003 1:47 =

  AM<BR><B>To:</B> mpls@UU.NET<BR><B>Subject:</B> explicit route=20
  configuration<BR><BR></FONT></DIV><LABEL id=3DHbSession=20
  SessionId=3D"3238805497"></LABEL>
  <DIV>Hello all,</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>I didn't find any configuration command in Cisco IOS to specify =
whether=20
  an explicit route is 'strict' or 'loose'. Other vendors like =
Riverstone=20
  Networks has such configuration commands, </DIV>
  <DIV>&nbsp;</DIV>
  <DIV><EM>mpls create path &lt;pathname&gt;</EM></DIV>
  <DIV><EM>mpls set path &lt;pathname&gt; [type loose | strict] ip-addr=20
  &lt;ipaddr/netmask&gt; [hop &lt;index&gt;]</EM></DIV>
  <DIV><EM></EM>&nbsp;</DIV>
  <DIV>Is it that Cisco doesn't have any command to specify an explicit =
route as=20
  'strict/loose' or am I missing something?</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Your help will highly be appreciated.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>-Harish</DIV><BR><BR><BR>
  <P><FONT face=3Darial size=3D-1><A href=3D"http://in.mobile.yahoo.com" =

  target=3D_blank><B>Yahoo! India Mobile</A>:</B> Ringtones, Wallpapers, =
Picture=20
  Messages and more. <FONT face=3Darial size=3D-1>Download <A=20
  href=3D"http://in.mobile.yahoo.com"=20
  =
target=3D_blank><B>now</A></B>.</FONT></FONT></P></BLOCKQUOTE></BODY></HT=
ML>
=00
------_=_NextPart_001_01C3B42A.FC625D6C--



From owner-mpls@UU.NET  Sun Nov 30 01:11: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 BAA09679
	for <mpls-archive@lists.ietf.org>; Sun, 30 Nov 2003 01:11: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 QQpqzw06405
	for <mpls-archive@lists.ietf.org>; Sun, 30 Nov 2003 06:11: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 QQpqzw06077;
	Sun, 30 Nov 2003 06:11:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQpqzv29678
	for mpls-outgoing; Sun, 30 Nov 2003 05:50: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 QQpqzv29663
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 30 Nov 2003 05:50: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 QQpqzv13620
	for <mpls@uu.net>; Sun, 30 Nov 2003 05:47: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 QQpqzv06481
	for <mpls@uu.net>; Sun, 30 Nov 2003 05:47:41 GMT
Received: from sj-iport-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-iport-3-in.cisco.com [171.71.176.72])
	id QQpqzv06473
	for <mpls@uu.net>; Sun, 30 Nov 2003 05:47:40 GMT
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-3.cisco.com with ESMTP; 29 Nov 2003 21:50:06 +0000
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAU5law5012944
	for <mpls@uu.net>; Sat, 29 Nov 2003 21:47:37 -0800 (PST)
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.70.36])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEH74497;
	Sun, 30 Nov 2003 00:47:35 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id hAU5lZI13231 for mpls@uu.net; Sun, 30 Nov 2003 00:47:35 -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 QQpqji20925
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Nov 2003 18:40: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 QQpqji08230
	for <mpls@UU.NET>; Tue, 25 Nov 2003 18: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 QQpqji13701
	for <mpls@UU.NET>; Tue, 25 Nov 2003 18:40:14 GMT
Received: from smtp.apricot.ocn.ne.jp by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: apricot.ocn.ne.jp [211.6.83.52])
	id QQpqji13686
	for <mpls@UU.NET>; Tue, 25 Nov 2003 18:40:13 GMT
Received: from qRs (r216117.ap.plala.or.jp [220.108.216.117])
	by smtp.apricot.ocn.ne.jp (Postfix) with SMTP
	id F23172EB7; Wed, 26 Nov 2003 03:40:11 +0900 (JST)
Message-ID: <019d01c3b383$8e4bdd10$0201a8c0@qRs>
From: "Seisho Yasukawa" <seisho-yasukawa@apricot.ocn.ne.jp>
To: "Loa Andersson" <loa@pi.se>, "MPLS wg" <mpls@UU.NET>
Cc: "George Swallow" <swallow@cisco.com>, "Alex Zinin" <zinin@psg.com>
References: <3FC13EA6.6030305@pi.se>
Subject: Re: draft-farrel-mpls-rsvpte-attributes-00.txt for wg document
Date: Wed, 26 Nov 2003 03:40:10 +0900
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.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Loa and all,

I support making this draft a WG doc.

Seisho Yasukawa



> All,
> 
> we been asked to make
> 
> draft-farrel-mpls-rsvpte-attributes-00.txt
> 
> an mpls working document. The document were discussed in
> Minneapolis, the room was undecided if we should go
> forward with the document. No opposition, but also no
> strongly voiced support.
> 
> Therefore we would like both those in favor and those
> opposed to making this a working group document to
> speak up.
> 
> /Loa
> 
> -- 
> 
> Loa Andersson
> 
> mobile +46 739 81 21 64
> 
>